--- title: Controlled delegation is the real engineering problem behind AI agents kind: concept status: draft order: 50 summary: Agent engineering is controlled delegation of authority under uncertainty, with intent, discretion, constraints, and verification kept explicit. audience: Engineers designing agent systems that can affect repositories, services, or other consequential infrastructure outcome: Distinguish model capability from delegated authority and identify where each boundary should be enforced prerequisites: - Familiarity with agent tool use and operational permissions domains: - agent-systems - trust-boundary - evals updated: 2026-09-06 author: tim --- AI agents are often introduced as models with access to tools. That definition is useful in the same way that describing a database as software that stores information is useful: correct, but too shallow to explain the engineering problems that matter once the system becomes consequential. The transition happens when a model is no longer asked merely to produce an answer. It is given responsibility for producing a result. That result may require reading systems, choosing a strategy, writing code, calling APIs, using credentials, spending resources, changing infrastructure, delegating subtasks, evaluating intermediate outcomes, and continuing long after the original request has disappeared from the context window. The question is no longer simply **Can the model figure out what to do?** It is: > What responsibility have we delegated, what authority accompanies that > responsibility, and what evidence is sufficient to let the resulting work > continue? The useful description is **controlled delegation of authority under uncertainty**. ## Intent is larger than the prompt A prompt is a piece of language. Intent is the state the operator actually wants to create. “Fix checkout” may begin a conversation, but it is a poor durable contract for autonomous work. A more operational version could be: > Reduce checkout failures below 0.1%, preserve current payment-provider > behaviour, keep p95 latency below 800 ms, and make no irreversible schema > changes. Now the system has an objective, success conditions, constraints, invariants, and a boundary around acceptable solutions. A request becomes a plan, the plan becomes tasks, tasks are delegated, agents call tools, and tools change systems. At each transformation, intent can drift. Long-horizon autonomy therefore requires intent to become durable state rather than remain implicit in a transcript. ## Delegation includes discretion Giving somebody a task is not giving them unlimited freedom. Consider: > Investigate the production issue. You can read production telemetry and > change staging. Do not touch the production database. Come back when you have > reproduced the failure. This contains responsibility for the investigation, freedom to decide how to investigate, access to specific resources, an explicit restriction, a stopping condition, and a requirement to return evidence. Agent delegation needs the same structure: **objective + authority + discretion + resources + constraints + verification obligations** Autonomy is delegated discretion, not a binary property. An agent may be fully autonomous when searching logs, moderately autonomous when changing staging, and unable to deploy production without approval. The meaningful question is not “Is this agent autonomous?” but “Which decisions has this system been entrusted to make?” ## Capability is not authority A model may technically be capable of deleting a database because it can operate a shell. That does not mean the task authorized it to do so. Capability asks what the system can physically do. Authority asks what it may do in this situation. They should not use the same mechanism. The reasoning model can propose: > Restart the checkout cache. A runtime should independently determine whether checkout is inside the delegation, whether this agent has restart authority, whether the resource is production, whether the operation is reversible, whether a change freeze is active, whether enough evidence supports the action, and whether approval is required. The model proposes. The infrastructure authorizes. ## Strong boundaries exist outside the prompt Prompts are useful behavioural controls but weak security boundaries. If customer records must never be deleted, a sentence saying “never delete customer records” is not enough. Make deletion unavailable through the tool; make the credentials unable to delete; route production requests through a policy enforcement point. The greater the consequence of violating a boundary, the lower in the stack it should be enforced: - prompts describe expected behaviour; - tool schemas constrain actions; - runtimes enforce policy; - credentials constrain actual permissions; - networks constrain reachability; - sandboxes constrain blast radius; - infrastructure rejects invalid transitions; - verification detects undesirable outcomes; - recovery contains failures that still escape. This is defence in depth for autonomous work. ## Verification closes the delegation loop Delegation without verification eventually becomes trust. An agent saying “Done” is making a claim. A deployment API returning success proves that a request was accepted; it does not prove that the application is healthy. A passing test proves that encoded tests passed; it does not automatically prove that the user-visible problem is resolved. Verification asks: **What observation of reality would justify accepting this claim?** The verifier may be a compiler, protected test, metric, another model applying a rubric, or a human. Strong systems combine them. The important property is independence: the mechanism proposing the change should not be the sole authority deciding whether it was good. ## Long-horizon autonomy changes the boundary over time An investigation may begin with read-only access. The agent reproduces the problem; evidence supports a hypothesis; the runtime creates an isolated environment; a fix succeeds there; that evidence unlocks staging authority; a staging soak succeeds; a person approves production deployment; and the runtime grants a ten-minute, single-use production capability. After deployment, that capability disappears and the system returns to observation mode. This is not static RBAC around an LLM. It is evidence-conditioned authority: authority expands when justified and contracts when verification fails, risk rises, or evidence becomes stale. ## Two loops The **work loop** is: ```text observe → reason → propose → act → verify → adapt ``` The **governance loop** observes task state, evaluates policy, evidence, and risk, exposes or revokes capabilities, determines assurance requirements, and authorizes the next transition. The work loop tries to accomplish the objective. The governance loop determines what kind of work is admissible. Evidence generated by the first changes the state of the second. A better model makes better proposals; it does not remove the need to decide which proposals may affect reality. ## The runtime is more than a tool router A serious agent runtime resembles a small operating environment around a probabilistic worker. It contains identity, task state, policy, authorization, capability discovery, credentials, execution isolation, budgets, evidence, verification, observability, recovery, and escalation. The model remains important, but it is no longer the whole system. The runtime determines what agents are allowed to do next, why, and on whose authority. ## Draft boundary This is a publishable architectural draft. It does not describe a released ReactorJet runtime, SDK, capability broker, or completed implementation. ## Related - [Verification is not the last step](/guides/concept/verification-is-state) - [A runtime for agents is an authority system](/guides/concept/runtime-as-authority-system) - [Authority Compiler](/work/authority-compiler) - [Autonomic Software Loops](/work/autonomic-software-loops)