One request. Two repair vans.

A plain model call maps an input to an output. An agent wraps that model in a feedback loop: observe state, choose an action, execute it through a tool, observe the result, and repeat until a stopping condition fires. The model proposes transitions; the runtime supplies memory, tools, scheduling, credentials, budgets, and termination. Most of the dangerous autonomy lives in that wrapper, not in the word `agent`.

The clean systems decomposition is planner, policy decision point, effect broker, and verifier. The planner converts evidence into an intended action. The policy layer decides whether this principal may perform that operation on that resource now. The effect broker turns an approved structured intent into a deterministic API call. The verifier re-reads authoritative state and determines whether the postcondition holds. Keeping these roles separate means a model can be creative about diagnosis without becoming creative about authorization semantics.

A goal is not a permission. `Restore checkout availability` describes a desired state; it does not authorize deleting databases, disabling WAF rules, messaging customers, or spending an unlimited cloud budget. Likewise, tool visibility is not tool authority. A model may know a `delete_deployment` schema exists while the runtime refuses to issue that capability for this tenant, environment, incident, or approval state.

Model reasoning is probabilistic, but effects should have deterministic envelopes. The model should emit a typed intent such as `{resource, operation, proposed_value, evidence_refs}`. Code then validates schema, resolves the current resource identity, checks policy and freshness, calculates blast radius, assigns an idempotency key, and executes only the permitted mutation. This is the same reason control planes do not grant root because a ticket was eloquent.

Agent reliability is therefore a property of the whole loop: observation quality, policy correctness, tool contracts, state freshness, retry behavior, stopping rules, and verification. Model capability helps the planner. It does not repeal distributed-systems failure modes; it merely gives them initiative.

Tool-capable APIs commonly expose a `tool_choice` control with modes equivalent to `auto`, `required`, `none`, or a named tool. `auto` lets the model answer directly or request a tool. `required` forces at least one tool call. `none` disables tool selection for that inference. A named choice constrains the model to one declared tool. Exact names and behavior vary by provider.

Use `none` for synthesis phases that must not create new external effects. Use `required` when a response would be invalid without authoritative evidence—for example, an incident summary that must first read the current deployment. Use a named tool when the workflow has already selected a narrow operation and you want structured arguments rather than another planning branch. Use `auto` only when both direct answers and tool-backed answers are legitimate outcomes.

The critical boundary: `tool_choice=none` can reduce the model's available action vocabulary, but `tool_choice=some_tool` must never grant permission to run that tool. It is an inference constraint, not an IAM decision. The gateway still authenticates the caller, authorizes resource and operation, validates arguments, applies budgets, and may require approval.

Forced tool use can also create junk activity. If `required` is set while no tool can improve the answer, the model may manufacture an unnecessary call merely to satisfy the protocol. Measure invalid-call rate, no-op calls, policy denials, tool retries, and the fraction of calls that materially changed the answer or state.

Version `tool_choice` with the prompt and tool schema. Moving from `auto` to `required`, or exposing a new named tool, changes behavior even when model weights stay fixed. Treat that as a canary-worthy release.

An agent trajectory is a dependency graph. Total latency is the sum of work on the critical path, not the sum of every tool duration. Independent reads—metrics, logs, traces, configuration, and recent deploys—can run concurrently, reducing one diagnostic phase from the sum of latencies toward their maximum. That is useful parallelism.

Mutations are different. Two calls that touch the same resource, budget, or invariant are not independent merely because the model emitted them together. Parallel restarts can violate availability budgets; simultaneous edits can pass policy against the same stale pre-state; a successful branch may make another branch unsafe. Build a conflict key from resource identity and protected invariant, then serialize or reject colliding effects.

Bound fan-out at the root trajectory. If a planner launches 8 subagents, each launches 6 tools, and each tool has 3 attempts, one user request can produce 144 downstream operations. Use a shared concurrency semaphore, tool-call budget, token budget, cost ceiling, wall-clock deadline, and retry ledger. Child work consumes the parent's budget rather than minting its own adorable little denial-of-wallet allowance.

Cache immutable reads only when keys include tenant, authorization revision, source generation, query arguments, and freshness horizon. Never cache an authorization decision longer than its revocation semantics. Before a mutation, re-resolve authoritative state and preconditions even if planning used cached evidence.

Measure useful progress per tool call, critical-path latency, fan-out width, cancellation propagation, duplicate-suppression rate, and work completed after the root deadline. An agent that finishes quickly after launching fifty abandoned calls is not fast; it has outsourced latency to your dependency graph.

The planner should never receive ambient cloud credentials. It submits an immutable action proposal to an effect broker: principal, target, operation, desired postcondition, evidence references, model and prompt revisions, and requested deadline. The proposal is data, not executable shell text.

The broker resolves the target from an authoritative API, checks policy against current identity and incident state, validates a typed schema, evaluates preconditions, estimates blast radius, and classifies the action. Read-only operations may execute immediately. Reversible low-risk changes may require a policy token. High-impact or irreversible actions require a human approval bound cryptographically to the exact proposal digest.

Use prepare/commit semantics for mutations. Prepare returns a short-lived capability naming the exact resource version, operation, arguments, approval, and expiry. Commit accepts that capability plus an idempotency key. If state changed after preparation, fail closed and re-plan; do not silently apply the old intent to the new object. The capability is single-purpose and useless outside the broker.

After execution, a verifier independently reads authoritative state and checks the promised postcondition and safety invariants. Success means the state is correct, not that the tool returned HTTP 200. If verification fails, the runtime enters a defined recovery path—rollback, compensate, escalate, or halt—without asking the same model to improvise an infinite apology loop.

Persist an append-only trajectory ledger containing observations, proposals, policy decisions, approvals, tool request and response hashes, idempotency keys, state versions, verification results, budget consumption, and termination cause. Secrets remain outside the ledger. This creates an incident timeline that does not depend on reconstructing intent from a conversational transcript.

A confused deputy uses its own authority on behalf of input that was never entitled to that authority. Agents make the classic problem nastier because untrusted instructions arrive through email, web pages, tickets, repositories, logs, retrieved documents, and tool output. A prompt injection does not need to convince the model it is evil. It only needs to redirect a legitimate workflow toward an operation the runtime will honor.

Do not let tool results add permissions. Content returned by a browser or repository may suggest another URL, command, credential, or tool call, but it remains untrusted data. The next action must pass the same policy boundary as the first. Authorization is non-transitive: permission to read a ticket does not imply permission to follow its link, execute its script, or use credentials mentioned inside it.

Capability tokens should be attenuated, audience-bound, short-lived, operation-specific, resource-specific, non-exportable where possible, and unavailable to model-visible context. Network egress should follow the same rule: allow declared destinations for a declared phase instead of granting a general internet socket and asking the model to be sensible.

Kill switches belong outside the agent's control plane. Revoking credentials, disabling the broker, blocking egress, and terminating workers must not require cooperation from the same planner being stopped. Test the stop path while tools are slow, retries are queued, subagents are running, and the model is generating; otherwise the kill switch is decorative architecture for a very tense slide deck.

The invariant is simple: every effect is authorized from authenticated runtime state, never from model prose. Alignment may reduce how often a bad action is proposed. Deterministic enforcement decides whether the proposal can become reality.