Agent Architecture and Orchestration
Agent-as-a-Tool — Stack
Agent as a tool › Stack
Technology landscape as of 2026-10-10. Knowledge cutoff May 2026.
Selection criteria
The interface is the product here. What matters is what it can express about duration, failure, cost, and isolation.
- Duration expressiveness. Whether the transport can represent work that takes minutes — by streaming progress, returning a handle, or supporting long-lived connections — or whether everything must fit a request timeout.
- Return enforcement. Whether the declared result shape is validated before the caller sees it, and where that validation runs.
- Failure vocabulary. Whether the interface can distinguish refusal, exhaustion, partial success, and internal error, or collapses them into a string.
- Isolation. Whether the inner run gets its own credentials, data scope, and context, or inherits the caller's by default.
- Ceilings. Whether per-call limits on iterations, time, and spend can be declared at the boundary rather than trusted to the inner agent.
- Nesting control. Whether call depth is visible and capped across the chain.
- Discovery. How the caller learns the tool exists and what its arguments are, and what happens when that description changes.
- Cost attribution. Whether the inner run's consumption is reported back in a form the caller can record against the specific call.
Options
| Option | Best for | Watch out for |
|---|---|---|
| In-process wrapper provided by an agent framework | Same-codebase composition where latency and deployment coupling are acceptable | Shares the caller's process, credentials, and failure domain; isolation is a convention, not a boundary |
| MCP server fronting the agent | Making an agent callable from any protocol-aware client, including ones you do not own | Protocol models tools as short operations; long runs need progress and cancellation handled carefully |
| HTTP or RPC service with a published schema | Cross-team deployment with independent scaling and clear ownership | Request timeouts across proxies and load balancers become the real constraint on inner run length |
| Job submission returning a handle, with polling or callback | Inner work measured in minutes, bulk processing, anything that may outlive a connection | The calling model must be taught a two-step interaction, which many tool-use patterns handle badly |
| Queue-backed request and reply with correlation identifiers | High volume, burst tolerance, and natural backpressure | Latency is unpredictable by design; not suitable where a user is waiting on the outer turn |
| Cross-organisation task protocols (A2A and similar) | Invoking an agent operated by another company | Identity, authorisation, and accountability questions arrive before the interface design does |
| Code-execution surface where the model writes calls | Callers that need to compose several inner agents programmatically in one turn | Sandboxing becomes the dominant concern, and failures surface as code errors rather than tool errors |