Comparison with Frameworks

This page is for someone deciding whether to build on this runtime or on a general agent framework. It describes differences in design, not in quality.

What frameworks optimize for

Most agent frameworks make it fast to compose prompts, chain calls, orchestrate several agents, add memory and retrieval, and switch providers. Their loop is flexible and the controls are typically options: a callback that can veto a call, a maximum iteration count, a human-in-the-loop node that suspends a graph.

What this runtime optimizes for

The controls are the product and the loop is minimal.

Concern	Typical framework	agent-runtime
Who decides whether a tool runs	the model, sometimes a callback	the policy, always, after schema validation, with the model having no handle to it
Pausing for a human	in-process suspension, sometimes serialized	a durable row with a hash over the exact request; any later process can decide and resume
Re-execution after approval	the model may be asked again	only the recorded request executes, and only if policy still agrees
Limits	iteration counts, sometimes token budgets	steps, failures, loops, calls, tokens, cost, active time, elapsed time, approval expiry, enforced before the action
Audit	logging and tracing hooks	an append-only event log committed with the state
Crash recovery	checkpointing of the graph state	interrupted steps with consumer reconciliation; side effects never re-run by the runtime
Testing	mocks of the provider	a scripted agent and scripted, recording, and replaying models; the whole loop runs without a provider
Tools from an MCP server	registered as the server describes them, annotations included	an operator classifies each one, the tool set is pinned by schema and description, and the same policy, limits, and log apply
Scope	orchestration, prompts, memory, providers, UI	the loop and its controls, plus the plumbing two consumers proved they had to write anyway

When to use a framework instead

When the task is mostly prompt engineering and composition, when the tools are harmless, when a human is in the chat loop anyway, or when several agents must coordinate. This runtime has no orchestration, no prompt machinery, and no memory, and adds them only when a consumer demonstrates the need.

What it does now have is the plumbing around the loop that every consumer wrote for itself: adapters for Ollama, OpenAI-compatible endpoints, and the Claude API, each a separate module; a renderer from recorded steps to messages; an MCP adapter; an operator command; trace and read models. That is not a provider abstraction and not a framework — there is no layer that translates between providers, no prompt template, and nothing that composes agents — but it does mean the comparison is no longer "a framework gives you the adapters and this does not". See Provider Adapters and MCP Tools.

When to use this

When the agent reads untrusted input and takes actions with consequences, when a human must approve specific actions out of band and possibly days later, when the record of what happened has to be complete and trustworthy, and when the behaviour has to be testable without a model.

Using both

Nothing prevents a framework from being the agent: implement Decide by calling into it and returning its chosen tool call. The runtime's controls then apply regardless of what produced the decision. Since v0.4.0 there is a second way, for a loop you would rather not hand over: keep the loop, and have it propose each action to a Gate, which validates, applies policy, pauses on a hash-bound approval, executes the tool, and records it. The gate runs the tool itself, so a tool is registered with it and not left in the loop's own code. For an MCP host in any language, MCP Proxy does the same in front of the host's MCP tools, with the limits on what it can govern stated first.