Choose an agent integration

An MCP bridge adds admission and receipts to the agent you already run

If a coding assistant already calls an MCP server, put Chio on that connection. The kernel authorizes the server's tools and signs a receipt for each decision, and the assistant keeps its own session, lifecycle, and model persistence. Tools the assistant reaches outside that connection stay outside the bridge.

chio mcp serve --preset code-agent --server-id workspace -- \
  npx -y @modelcontextprotocol/server-filesystem@2026.8.31 /workspace

The command is the server side of an MCP registration, and your client launches it. Set the root to the one project the assistant works on, change only the MCP registration, and keep the agent application as it is. Where the deployment requires verified tool-server execution, add an explicit signed launch policy. Then register the server, run one allowed call and one refusal, and keep the verifier inputs with the receipts.

Read more in Connect a coding agent and Wrap an MCP server.

A native process keeps identity and history across worker restarts

Choose the process host when a restarted worker should come back with the same identity, narrowed authority, call ceiling, checkpoint, and tool history. The host supervises attempts, the kernel admits each call and records its outcome, and the worker holds a private connection instead of the host's signing keys. Background jobs and agent collaborations that outlive one HTTP request belong here.

Your worker replaces direct tool calls with the process client and saves an explicit application checkpoint. Each call carries an operation key, such as refund-order-77 for the one refund of order-77; retain it with the call's input and send the same key after restart, and the kernel resolves the original call instead of refunding USD 58.00 a second time. You still own planning checkpoints, logical keys, and output validation. The process runner runs on Linux, or on Unix under the serve profile.

For a background worker, run the Python and Node starter and then replace its calculation with your own. For a coding service that returns a patch to another person, start from Run a governed coding task: its selected commit, imported scope, bounded repository commands, and recipient verification give a coding agent a firmer start than a shell callback added to a chat loop.

Read more in the native process project and Calls and recovery.

A framework adapter leaves your graph or turn loop in charge

Use an adapter when a framework is already your application's architecture. The process host executes the selected tools and the framework keeps every other decision.

• LangGraph. A ChioProcessToolNode executes selected tools through the native host. The graph checkpointer persists complete assistant messages, and artifacts retain the receipts. Keep the graph, add a durable checkpointer, and replace the selected tool node; you own the graph checkpoint and the saved model tool-call message.
• AI SDK. ChioProcessAgent journals each complete model response before exposing its tool calls, then runs those tools through the process. Wrap generateText or streamText inside agent.run in a Node 22+ worker; the adapter's tool bridge returns the original receipt callbacks. You own the original turn input, the provider configuration, and UI reconciliation.
• Sidecar dispatch authorization. The sidecar evaluates each dispatch and handles approvals while your graph and application keep their lifecycle. Keep the execution callback; its effects stay with your application.

Both adapters need stable turn identity. For a LangGraph research workflow, keep the graph database and the original thread while you replace the tool node. In the AI SDK, choose the process agent for complete response persistence, and the lower-level tools bridge only when your application already journals provider decisions before tool execution.

Read more in LangGraph and Model call recovery.

Four answers fix the boundary before you move a callback

1. Who persists the model's chosen tool-call ID? If nobody does, a regenerated model response can create a different operation, and a receipt for the first one cannot stop it.
2. Who owns each side effect outside Chio? A callback that also writes a local cache or sends email keeps those effects outside the route until you move them or make them recoverable.
3. Can the worker touch files or the network directly? Process authentication identifies the worker; confinement comes from the host. The execution security chapter covers admission and containment at that edge.
4. Who validates the final answer? The tool schema check and the user-facing result stay where they already live.

Moving a callback behind a process route keeps its meaning only when the route matches it. The pricing service must run behind the configured tool route, with a manifest, launch policy, and grant that agree. Save the request before dispatch, and retain the original receipt text with the response.

def refund_order(order):
    return pricing.refund(order)

def refund_order(client, saved_request):
    # saved_request = {"key": "refund-order-77", "arguments": {"order": "order-77"}}
    response = client.invoke(
        saved_request["key"],
        "pricing",
        "refund",
        saved_request["arguments"],
        known_outcome_only=True,
    )
    if (
        response["verdict"] != "allow"
        or response["terminal_state"]["state"] != "completed"
    ):
        raise RuntimeError("refund-order-77 needs reconciliation")
    return response  # Caller validates tool schema and retains original receipt text.

Pick the language last. Python, TypeScript, and Rust workers all authenticate to the process host the same way. Embedding the kernel in a trusted Rust host is a separate route, for an application that must own the kernel and its stores.

Read more in the worker language projects.

Next: run the native process project