FIELD · Handbook · 4 min read
Bound agent autonomy with explicit control
Assess protocols, harnesses, approvals, memory, tools and external effects as part of the engagement.
Arunank Sharan · Kuzushi Labs ·
In this article
An agent engagement must specify what the application may decide, which tools it may use and what it may change. A capable model is only one component. The harness owns execution state, resource limits, authority, evaluation and recovery around model calls.
Choose the simplest useful execution shape
Start with deterministic routing and a fixed workflow when the steps are known. Add a bounded model loop for genuine uncertainty in retrieval, interpretation or planning. Use multiple agents only when independent investigation, specialized context or organizational separation justifies the extra coordination, latency and cost.
Define the task’s input, allowed scope, success state, deadline, maximum spend, maximum attempts and escalation path. A useful initial operations-agent contract might allow six tool calls and three model calls per task, with a 30-second completion target for routine work. These are workload assumptions for evaluation; a task requiring human approval has a separate durable waiting state.
Distinguish protocols from products
| Layer | Role in the engagement | What still belongs to the application |
|---|---|---|
| MCP | Common interface for exposing model-facing tools and context | Business authorization, tool semantics, data rights and recovery |
| A2A | Interoperability between participating agents and their tasks/artifacts | Trust policy, delegated authority, acceptable results and reconciliation |
| Google ADK | Toolkit for constructing and running agents | Production stores, infrastructure, access rules and operational ownership |
| OpenAI Agents SDK | Toolkit for agent applications, tools and execution workflows | Business controls, deployed configuration, evidence and service obligations |
| Agent Client Protocol | Editor/client interaction with coding agents | Repository isolation, execution permissions and merge policy |
| Durable workflow runtime | Persist waiting and resume work after interruption | Correct external-effect contracts and workflow migration |
| Trace/telemetry conventions | Correlate activity for diagnosis | Data minimization, evidence retention and business outcome measurement |
MCP and A2A are protocols; ADK and an agent SDK are development frameworks. None is a substitute for a customer-specific authority model. Version behavior changes. Pin the protocol revision, SDK/runtime version, binding and tested capabilities in an integration manifest, then run conformance checks before upgrading. Do not assume interoperability from names alone.
The control contract
A durable run record includes tenant, actor, intent revision, policy version, budget, deadline, pending approvals, tool operations and terminal state. Credentials are scoped to the actual user/service delegation. The model proposes an action; an enforcing component checks permission, resource preconditions and any required approval before the external call.
An approval is bound to the specific action, target, amount or other material arguments, intent revision and expiry. Any material change requires renewed approval. Recheck current permission at execution. Do not store approval solely as a sentence in conversation history that can be lost during summarization.
Track operation states such as prepared, sent, confirmed, failed and unknown. On an ambiguous timeout, query the authoritative system or reconcile using a stable operation key. Never convert unknown into failed just to make a retry convenient. Record cancellation separately from reversal of a business action.
Memory and information boundaries
Separate user preferences, business facts, inferred hypotheses, retrieved documents, conversation history and durable obligations. Give each provenance, scope, lifetime and correction/deletion behavior. Context compression may reduce text; it must not erase pending commitments or change authority.
Treat retrieved documents, tool outputs and remote-agent messages as data. Embedded instructions cannot grant permission or override the application’s rules. Bound tool output size and network destinations. A remote agent does not inherit the user’s entire credential set merely because it receives a task.
Capacity and consequence
At five tasks/s with six tool and three model calls per task, provision for 30 tool calls/s and 15 model requests/s before retries. At 2,000 input and 300 output tokens per model call, demand is 30,000 input and 4,500 output tokens/s. Provider quota and model latency may bind before gateway CPU. Put retries inside a shared budget so one degraded dependency cannot multiply work across every layer.
A one-day approval wait consumes durable storage and scheduling state; it should not reserve a GPU or hold a database transaction open. Separate interactive, background and sandbox work. Apply per-tenant quotas, bounded queues and visible overload behavior.
Evaluate the harness as well as the model
Test revoked access, stale approval, duplicate tool events, timeout after commit, worker crash, partial output, budget exhaustion, malicious retrieved text, remote-agent cancellation and code-version migration. Check the final business state and receipts, not only the generated explanation.
Compare verified task completion and full cost with a simpler workflow baseline. For coding agents, isolate repositories, restrict network/secrets, run tests in a sandbox and make publishing or merging a separate authorized action. The operations-agent application and remote-specialist application show these controls in a concrete engagement.