Agentic Systems: The Bounded Autonomy Pattern
Agentic systems fail in the boundary, not in the model. The Bounded Autonomy Pattern names the five dimensions where autonomy lives and lets you design the boundary deliberately. Without the pattern, every agent design becomes a debate about ReAct vs Reflexion; with it, the architecture follows from the bounds.
Most agentic-system interviews end up in the same place: the candidate explains ReAct or describes a planner-executor loop, the interviewer asks 'how do you bound it?', and the candidate offers timeouts and retries. The interviewer writes the same note they have written ten times that week — 'understands the architecture, doesn't understand the failure modes.' The failure modes of agentic systems do not live in the model; they live at the boundary between the agent and the world, and 'timeout and retry' is approximately one-tenth of what that boundary requires.
Bounded Autonomy is the five-dimension framework for designing the boundary. Action surface, step budget, reversibility tier, confidence threshold, recovery envelope. Each is a knob you set explicitly; agents that ship safely have all five set deliberately; agents that cause incidents almost always have one or more set implicitly. The framework's main job is to refuse the 'agent that decides' framing and replace it with 'agent that decides within these specific bounds.'
The Bounded Autonomy Pattern
Agentic systems fail at the boundary, not at the model. The Bounded Autonomy Pattern is the five-dimension lens that converts 'how much should an agent decide on its own?' from a vibes question into a structured design decision. Each dimension is a knob the designer turns explicitly. Production agents that work have all five knobs set deliberately; agents that fail almost always have one or more set implicitly.
- 1Dimension 1 — Action surfaceWhat tools can the agent call, with what arguments? The agent's action surface is the design's most consequential boundary. A read-only retrieval surface is fundamentally safer than a read-write database surface; both are safer than a 'execute arbitrary code' surface. Most production agents that caused incidents had an action surface that included one tool the designer thought was safe and wasn't.
- 2Dimension 2 — Step budgetHow many actions can the agent take before the system forces termination? Step budget is the dimension that bounds runaway loops. Production agents with no step budget hit token limits, timeouts, or accidental denial-of-service against their own backends. Step budget should be set per task type, not globally.
- 3Dimension 3 — Reversibility tierFor each action, is the outcome reversible (read a file), recoverable (send an email to internal team), or irreversible (send a payment, post publicly)? Group actions by reversibility tier and require different human-in-the-loop policies per tier. Conflating tiers is how 'autonomous agent makes irreversible mistake' incidents happen.
- 4Dimension 4 — Confidence thresholdWhat confidence signal does the agent emit, and what's the threshold below which it pauses for human input? Most agentic systems lack a meaningful confidence signal at all; they pretend the model's output is calibrated and act on it. The L7 design surfaces explicit uncertainty (low retrieval recall, model abstention, tool error) and routes through a human-in-the-loop policy.
- 5Dimension 5 — Recovery envelopeWhen something goes wrong mid-task — tool error, model timeout, contradictory result — what's the agent's recovery behavior? Retry, escalate, rollback, abandon. The recovery envelope is the dimension that determines whether the agent is helpful when things fail or just generates more chaos. Design the envelope before the agent ships, not after the first incident.
Apply the pattern to any agentic-system design prompt — research agents, coding agents, customer-service agents, data-pipeline agents. The pattern is also the right opening for 'is this use case appropriate for an agent?' questions, because three of the five dimensions sometimes resolve to 'don't build an agent; build a workflow.'
Prompt: 'Design an autonomous coding agent that ships PRs.' Senior answer: 'Use a code LLM with a tool that runs tests; if tests pass, open the PR.' Staff answer: 'Action surface: read repo, write to scratch branch, run tests, open PR — never merge. Step budget: 30 actions per task. Reversibility tier: writing PR (reversible) is autonomous; merging PR (irreversible) is human-gated unconditionally. Confidence: agent must emit a self-confidence score and abstain below 0.8; tests must pass before any PR opens. Recovery: tool errors trigger retry once; contradictory test results escalate to a human. Five knobs, set explicitly. Now we can argue about whether the design is right — but the design is at least a design.'
Design a customer-service agent that handles refunds for an e-commerce platform.
Classic agentic design prompt. The interviewer is testing whether you treat 'refund' as a tool the model can call autonomously or as the boundary the design hinges on.
An LLM with tools for looking up orders, checking refund policy, and issuing the refund. Wrap it in a chat interface.
Two-tool agent — order lookup is read-only, refund issue is write. Use ReAct-style planning. Add guardrails on refund amount (cap below $100 autonomous, route higher to human).
Bounded autonomy. Action surface: order lookup (read), policy lookup (read), draft refund (write to staging), issue refund (write to production). Step budget: 15 actions per conversation. Reversibility: refund issuance is hard to reverse, so it's a different tier — gate it behind explicit human confirmation in the customer's session, not just on the agent side. Confidence: agent emits a policy-match confidence; below threshold, route to human with the agent's draft response as context. Recovery: tool errors retry once; contradictory order data (e.g., refund-already-issued) escalates.
Same bounded-autonomy structure, with three additions. (1) The action surface should be split by reversibility tier explicitly — read tools available to autonomous agent, write-to-staging available with confidence threshold, write-to-production gated by human confirmation always. The 'always' is non-negotiable for the first six months of deployment regardless of confidence; building trust in the confidence calibration comes before relaxing the gate. (2) The confidence signal must be calibrated against observed outcomes — the team has to commit to logging confidence-vs-correctness pairs and re-calibrating monthly. Unreviewed confidence scores drift; the calibration is a continuing system. (3) Most importantly: the entire design is wrong if the use case is well-served by a workflow instead of an agent. For refunds, the rule structure is mostly determinable — eligibility, amount, customer history. A workflow with LLM-assisted classification at the entry point covers 90% of cases at lower cost and higher safety than a planning agent. I'd argue for the workflow-first design and reserve agent autonomy for genuinely open-ended cases (escalations, novel disputes) where planning is needed. The pattern: most 'we need an agent' use cases are actually 'we need a workflow with LLM classification,' and proposing the agent design without that challenge is the canonical Staff-vs-Senior gap.
Named all five dimensions and added the three additions: human-gated production writes for an initial trust-building period, calibration as a continuing system, and the workflow-vs-agent reframing. The reframing is the highest-leverage move; most 'agentic system' interview prompts have a Senior-tier candidate answer (the agent design) and a Staff-tier candidate answer (the workflow plus selective agent autonomy). Recognizing which one the prompt actually wants is the Staff signal.
The interviewer asks 'design an agent that does [X].'
Before designing the agent, name whether the use case is workflow-shaped (deterministic rules with classification at the entry) or agent-shaped (genuinely open-ended planning required). About 70% of 'agentic' prompts are workflow-shaped; proposing the agent design without challenging the framing is the canonical Senior failure.
What interviewers grade on agentic system design prompts.
What they score
- ·Did the candidate name the boundary, or did they describe the planning loop?
- ·Did they distinguish reversibility tiers, or did they treat all tool calls as equivalent?
- ·Did they propose a confidence signal, or did they assume the model's outputs are calibrated?
- ·Did they design the recovery envelope, or did they say 'retry on failure' and move on?
- ·Did they ask whether the use case justifies the agent at all, or did they default to building one?
Why it's not on the rubric
Agentic systems are the area where the gap between 'reading the latest paper' and 'shipping production' is largest right now. The rubric language is generic ('demonstrates depth in agentic architectures'); the actual scoring is whether you've operated this kind of system or only built proofs of concept. Boundary design is the signal that you've operated.
How to signal it
- →Name the action surface in tools-and-arguments form within the first 60 seconds. 'Read order, read policy, write-to-staging refund draft, write-to-production refund issuance' beats 'a refund tool.'
- →Group actions by reversibility tier out loud. 'Tier 1 reversible, Tier 2 internal-only, Tier 3 irreversible' is the signal.
- →Propose a specific confidence signal (retrieval recall, model self-rating, tool consistency check) and a specific threshold.
- →Design recovery as a state machine, not as 'try-catch.' Different errors have different recoveries.
- →Once per prompt, challenge whether the agent design is the right shape. If a workflow does 80% of the cases at 20% of the cost, say so.
Practice this. Time yourself.
You have 12 minutes. Design a research agent that ingests a domain (e.g., 'electric vehicle battery technology'), searches the web, summarizes findings, and produces a 5-page report. Use the Bounded Autonomy Pattern to define all five dimensions explicitly. Then write a sixth section: 'is this use case actually agent-shaped, or would a multi-step workflow do better?' Defend your answer.
Self-assessment rubric
| Dimension | Weak | Passing | Strong | Staff bar |
|---|---|---|---|---|
| All five dimensions named | Named 1-2 dimensions. | Named all 5 but at least one was hand-wavy ('confidence: TBD'). | Named all 5 with specific commitments per dimension. | Named all 5 with specific commitments AND explained how the dimension settings interact (e.g., a tighter confidence threshold forces a larger step budget because the agent will abstain more). |
| Reversibility tier | Did not distinguish tiers. | Identified that web searches are read-only and report writing is write. | Distinguished read (search), write-to-scratch (drafting), write-to-final (publishing the report) tiers with different policies. | Named that 'cite this source as authoritative' is itself a near-irreversible action because misinformation propagates downstream — and added a fact-grounding requirement before any cited claim makes it to the final report. |
| Workflow-vs-agent challenge | Did not address. | Said 'agent is appropriate because the topic varies.' | Argued either side with specifics — when the domain is well-mapped, a workflow with retrieval + multi-pass summarization beats a planning agent. | Argued that the right design is a workflow at the outer level (retrieval → cluster sources → multi-pass summarize → fact-check → assemble) with an inner agent only for the 'fact-check' and 'investigate contradiction' sub-tasks. Hybrid is the Staff answer here. |
Reveal model solution
Common failures
- ✗Designed a planner-executor agent without naming the action surface in specific tools.
- ✗Treated all tool calls as the same reversibility tier. Citing a source as authoritative is not reversible the way querying a search engine is.
- ✗Did not segment the step budget. Single-budget agents commonly run out before reaching the assembly phase.
- ✗Did not propose a confidence signal. 'The model knows when it's uncertain' is the assumption that produces incidents.
- ✗Did not challenge the workflow-vs-agent framing. The hybrid is almost always the right answer for research-like tasks.
The Bounded Autonomy Checklist
Before designing the agent — challenge the framing
- ☐Is the use case well-defined enough that a workflow with LLM classification handles 80%+?
- ☐Are there specific sub-tasks where planning is genuinely needed, or is the whole thing planning?
- ☐If we shipped a workflow today, what would be the gap that justifies the agent?
- ☐If the answer is 'the cases workflow doesn't cover,' is that a 10% or 90% case? Build accordingly.
Dimension 1 — Action surface (write these down)
- ☐Every tool the agent can call, by name and argument signature.
- ☐For each tool: is it a read, a write-to-staging, or a write-to-production?
- ☐What's the worst plausible action sequence given this surface? Is it tolerable?
Dimension 2 — Step budget
- ☐Total step budget per task.
- ☐Segmented sub-budgets if the task has phases.
- ☐What happens when the budget is exhausted — return partial, escalate, terminate?
Dimension 3 — Reversibility tier
- ☐Tier 1 (reversible): autonomous.
- ☐Tier 2 (recoverable / internal-only): autonomous with logging.
- ☐Tier 3 (irreversible / external impact): human-gated for an explicit period regardless of confidence.
Dimension 4 — Confidence threshold
- ☐What signal? (Retrieval recall, model self-rating, tool consistency, ensemble agreement.)
- ☐What's the threshold? Per tier.
- ☐Below threshold: pause, escalate, or insert 'unverified' marker?
- ☐Is the team committed to calibrating this signal monthly?
Dimension 5 — Recovery envelope
- ☐Tool errors: retry once, escalate after.
- ☐Contradictory outputs: investigate, abstain, or note both.
- ☐Zero-result actions: rewrite query, escalate, or terminate.
- ☐Recovery is a state machine; design it before launch.
Mid-stage AI startup, autonomous customer-service agent deployed for refund handling on an e-commerce platform. 80% accurate at launch on test cases, considered production-ready. The team had implemented ReAct-style planning, OpenAI function calling, and 'safety guardrails' (a cap on refund amount).
Week three of production deployment, the agent issued 47 duplicate refunds to a single customer over a 90-minute period. The customer had a flaky network and resubmitted requests; the agent's step budget allowed it to call the issue_refund tool multiple times per conversation, and the duplicate-detection logic lived in the agent's prompt ('check if refund was already issued') rather than in the tool itself. The model's check passed each time because the agent's context window didn't carry across the customer's resubmissions, and the tool returned success each time because it didn't enforce idempotency.
The architecture diagram had a box labeled 'issue_refund' as a single tool. The team had not separated the tool's action surface into reversible (draft a refund decision) and irreversible (execute the refund). They had not enforced idempotency at the tool layer because they were trusting the agent's reasoning. The design had four of the five Bounded Autonomy dimensions implicit. The 'confidence' dimension was implicit (model just acts on what it generates), the recovery envelope was implicit (no contradiction-detection beyond model reasoning), the reversibility tier was implicit (all tool calls equal), and the action surface was implicit (one big tool instead of staged ones). Only the step budget was explicit, and it was set to 20 actions which proved more than enough rope.
At design time: 'The issue_refund tool needs to be split into draft_refund and execute_refund. Draft is reversible — agent can call it autonomously. Execute is irreversible — requires the agent to pass a unique customer-conversation ID, the tool enforces idempotency by that ID, and the agent must obtain explicit customer confirmation in the conversation before execution. The agent's confidence in the policy match must be above 0.85 before execute_refund is even available as a tool; below that, the agent can only draft and route to a human reviewer. Recovery envelope: contradictory results between draft and the customer's claim trigger immediate escalation; the agent does not silently re-draft.' Each of these is a 30-second design decision. Together they prevent the 47-refunds-in-90-minutes incident entirely.
Agentic systems fail at the boundary, and the boundary lives in five specific dimensions. Implicit boundaries become incidents. Explicit boundaries — written into the action surface, the step budget, the reversibility tiers, the confidence threshold, and the recovery envelope — are what make agents safe. None of this is exotic; all of it requires the framework that forces the design questions. Bounded Autonomy is that framework.