How it works
A bounded agent can choose how to complete work, but it cannot redefine the operating envelope. The model supplies judgment inside that envelope. The harness defines and enforces the envelope through deterministic controls outside the model.
A practical boundary usually combines:
- Workflow limits. The agent may select among permitted steps, but it cannot skip required validation, approval, or persistence stages.
- Authority limits. Its delegated objective is explicit. It cannot expand the task merely because adjacent work appears useful.
- Permission limits. Tools, credentials, data, and write scopes are restricted to what the task requires.
- Execution limits. Budgets cap iterations, tool calls, elapsed time, spend, or affected resources.
- Escalation limits. Stop conditions identify decisions or failures that must return to an operator or control plane.
These limits need runtime enforcement. Telling an agent to stay within scope is not equivalent to preventing an out-of-scope action. The harness should validate each consequential tool request, record the decision, and reject calls that violate the current run contract.
Boundaries can change between runs or workflow states. A read-only research agent might later receive permission to write a draft, but that transition should be an explicit state change rather than an inference made by the model.
Why it matters in an agent harness
An agent is useful because it can adapt its path when the exact sequence is not known in advance. That same flexibility makes failure paths difficult to enumerate. A bounded agent preserves local adaptability while limiting the consequences of a wrong interpretation, faulty plan, injected instruction, or repeated action.
The first outcome is control. The operator can delegate a defined result without delegating every permission available to the surrounding application. If the task is to inspect a repository and propose a patch, the agent does not also need deployment credentials or authority to modify unrelated services.
The second outcome is failure containment. A weak answer is a content-quality problem. An unauthorized write is a control failure. A runaway retry loop is an execution failure. Boundaries keep these categories separate and give each one a specific response: reject the output, deny the action, stop the run, restore a checkpoint, or escalate.
Boundaries also improve observability. A trace is more useful when it can show not only what the agent attempted, but which contract permitted or denied each action. Operators can then distinguish model behavior from harness behavior. Without that distinction, a denied call may look like an agent failure, while an overly broad permission may remain invisible until damage occurs.
Reversibility depends on the same design. A bounded agent should operate on resources that can be identified, versioned, checkpointed, or compensated for. Not every effect is reversible, so irreversible actions deserve tighter scopes and stronger approval policies. Sending a message, publishing content, rotating a key, and deleting remote data should not inherit the same authority as reading files.
The boundary must apply below the prompt. Prompt instructions shape behavior, but permission checks, execution budgets, state transitions, and stop conditions decide what the system can actually do.
Bounded agent vs bounded autonomy
The concepts overlap, but they answer different design questions.
| Concept | Primary question | Engineering focus |
|---|---|---|
| Bounded agent | What may this agent do in this run? | Workflow, tools, credentials, state, budgets, and escalation |
| Bounded autonomy | How much independent judgment may the system exercise? | Decision rights, approval thresholds, and operator involvement |
An agent can have broad autonomy inside a narrow boundary. For example, it may independently investigate a test failure and revise files within one worktree, while being unable to access deployment credentials or merge the result. Conversely, an agent can have broad permissions but little autonomy if every consequential action requires approval. That design is still risky because a mistaken approval can expose an unnecessarily large permission surface.
I treat permission scope and autonomy level as separate controls. Reducing one does not automatically correct an unsafe value in the other.
The Rifty take
We optimize for the smallest boundary that still lets the agent finish meaningful work without constant supervision. We accept occasional escalation or denied actions as the cost of keeping authority legible and failure contained. If a limit exists only in the prompt, we do not count it as a control boundary.
Implementation checks
- Define the run objective and explicitly exclude adjacent work the agent must not absorb.
- Issue scoped credentials instead of exposing the operator's full authority.
- Enforce tool, resource, and read/write scopes at invocation time.
- Put limits on iterations, tool calls, elapsed time, spend, and affected resources where relevant.
- Require explicit state transitions before expanding permissions or changing workflow stages.
- Make stop and escalation conditions observable in the execution trace.
- Treat unknown action outcomes as unresolved state, not permission to retry blindly.
- Use idempotency keys, checkpoints, or compensating actions for effects that support recovery.
- Test denial paths, exhausted budgets, malformed tool calls, and attempted scope expansion.
- Review whether every irreversible action has a narrower boundary than ordinary read or draft work.
Frequently asked questions
Is a bounded agent still autonomous?
Yes. A bounded agent can choose plans, tools, and intermediate steps without operator approval, provided those choices remain inside its enforced run contract. Autonomy describes independent decision-making; boundedness describes the limits around that decision-making. A narrow permission surface can still contain substantial adaptive behavior.
Can prompt instructions create a sufficient agent boundary?
No. Prompt instructions influence the model but do not reliably enforce permissions, budgets, or resource scopes. Consequential boundaries belong in the harness, tool gateway, credential layer, or workflow state machine. The prompt should explain the limits, while deterministic controls prevent actions that violate them.
How should a bounded agent handle work outside its scope?
It should stop or escalate with the unresolved need, attempted action, and relevant state recorded. It should not silently omit a required step, broaden its own authority, or substitute an unapproved action. The operator or control plane can then revise the contract, delegate separately, or reject the task.
What should happen when an agent reaches an execution limit?
The harness should stop further execution and preserve enough state to inspect, resume, or safely abandon the run. Reaching a limit is a control event, not evidence that the task succeeded or failed. The trace should identify the exhausted budget and any effects already committed.
How do I test whether an agent is genuinely bounded?
Test adversarial and accidental boundary crossings. Ask the agent to access an unrelated resource, exceed a tool budget, repeat an uncertain write, skip an approval, or use a credential outside its scope. The harness should deny the action, preserve an audit record, and enter the specified recovery or escalation path.