Tool Execution Runtime Architecture

The runtime that turns a model's tool call into an executed result and back into context. Where Tool-Calling Design covers how to design a tool, this covers the machinery that registers, dispatches, executes, and marshals tools at run time.

When the model emits a tool call, the runtime must validate it, run the right handler safely, and return a result the model can read — every loop iteration of ReAct. The runtime is the trust boundary between a non-deterministic model and deterministic, often side-effecting, code. Source: compiled from function-calling runtime patterns

Components

• Tool registry — names → schemas + handlers. The schemas are also serialized into the model's context as the callable surface.
• Schema serializer — renders the registry as the provider's function-calling format (JSON Schema) so the model knows what it can call.
• Argument validator — parses and validates the model's call against the schema before execution; a structured-output gate. Invalid args become an error Observation, not a crash.
• Dispatcher — routes the validated call to its handler (local function, HTTP API, or an MCP server).
• Sandbox — executes untrusted/effectful handlers in isolation (see MicroVM and Sandbox Isolation Architecture); the runtime should assume tool code can fail or be hostile.
• Result marshaler — shapes the handler output into a token-bounded Observation (truncate/paginate per Tool-Calling Design).

Parallel tool calls

Modern models emit several tool calls at once. The runtime should execute independent calls concurrently under a bounded concurrency limit, with per-call timeouts, then return all results together. Dependent calls still serialize through successive loop turns.

Design implications

• Validate before execute, always. The model will emit malformed or hallucinated calls; the validator turns those into recoverable error Observations.
• Isolate side effects. Effectful tools (write, pay, deploy) need sandboxing, idempotency keys, and often human approval — the runtime is the right enforcement point.
• Timeouts and errors are normal. A hung tool must not hang the agent; wrap handlers in timeouts + circuit breakers and surface failures as Observations.
• Token-bound every result. A tool that dumps 50k tokens poisons the window; marshal aggressively.

In Kevin's Dedalus stack this runtime spans the model's function-calling layer, MCP dispatch, and microVM workspaces where tool/agent code actually executes.

Architecture Position

---

Timeline

• 2026-07-01 | Architecture category refresh added this page to the Agent runtime and control plane family, linked it to Architecture System Map, and kept it standalone because it owns this boundary: Runtime boundary from model tool call to validated execution and bounded observation. Source: User request, 2026-07-01

• 2026-06-02 | Page created. Captured the registry/serializer/validator/dispatcher/sandbox/marshaler components, the validate→dispatch→execute→marshal loop, parallel tool-call execution, and implications (validate-first, isolate side effects, timeouts, token-bounding). Source: compiled from function-calling runtime patterns