Agentsmith: A Symbolically-Grounded Agent Architecture
Interstitial/Breakout Cycles from Platform Runtime to Client SDK
Abstract
Agent frameworks share an architecture: a language-model loop that reasons, calls tools, reads results, and reasons again, with every intermediate step transiting the context window at full token price. The loop is simultaneously the agent’s brain, its working memory, and its cost center, and because each framework bakes its own copy client-side, every improvement to planning, grounding, or economics is rebuilt once per client.
Agentsmith is organized around a different unit: the interstitial/breakout cycle. Interstitials are focused sub-loops that do the work between conversational turns (checking memory, acquiring data, transforming it deterministically, verifying inputs) outside the context window, at the lowest execution tier that suffices, which is frequently no language model at all. The breakout is the single terminal step whose output enters the window: one presentation pass over engineered context. The window becomes a surface rather than a workspace; the work happens in governed infrastructure where it can be routed symbolically, grounded against facts, priced, and audited.
The architecture has two expressions sharing one vocabulary: a platform turn engine that routes goals through cheapest-first tiers, gates data-bearing answers on tool evidence, and fails closed; and a thin client SDK that runs the same plan and interstitial vocabulary locally while the symbolic substrate stays server-side. The two meet in multi-agent workspaces, where both bid in the same auction for the same tasks.
The cycle was first prototyped in synapsOS, the author’s earlier agent system. This paper describes its production form.
Problem Landscape
The Loop Is the Cost Center
In a conventional ReAct-style agent, every observation (every tool result, intermediate table, and retry) is appended to the context window, because the window is the only working memory the architecture has. Token cost therefore scales with the process of the work rather than the size of the answer, attention degrades over the transcript, and the most expensive component in the system is used as a scratchpad.
Every Client Rebakes the Loop
Because frameworks implement the loop client-side, capabilities live and die with the client. A planning improvement in one framework does not benefit another; grounding, cost control, and audit are re-implemented per integration; and thin clients (a chat surface, an automation node, a CLI) either embed a full agent runtime or forgo agentic behavior. The loop is treated as application logic when it behaves like infrastructure.
Fluent but Ungrounded
Language models misread structured facts at rates that corrupt downstream reasoning, most damagingly by silently inverting relations: reading supplies(a, b) and proceeding as though b supplies a. The error is invisible to the loop that made it, because nothing in the architecture disagrees.
Confidence Without Evidence
The complementary failure is the answer that arrives without support: a report whose headline numbers were composed rather than computed. Architectures that treat the model’s final message as the deliverable have no seam at which to ask what evidence backs this?, and no defined behavior when the answer is “none.”
The Interstitial/Breakout Cycle
A turn is a cycle with two phases of different character.
Interstitials (ICs) are typed units of pre-window work: checking symbolic memory before any external call; acquiring data through governed discovery and execution; transforming results with deterministic tools; executing operations against logic namespaces; verifying untrusted content; scheduling future work; synthesizing accumulated results into a structured draft. Each runs at the cheapest tier that suffices (memory checks and deterministic transforms are zero-inference by construction) and reports structured results and costs rather than prose.
The breakout is the terminal window-crossing step: one presentation pass over the context the interstitials assembled. It is confined to presentation because by the time it runs, the facts have been fetched, transformed, and verified elsewhere.
flowchart TB
goal["user goal"]
subgraph infra["outside the context window"]
direction TB
router["symbolic router<br/>and planner"]
mem["memory check<br/>no model"]
acq["data acquire<br/>cheapest tier that suffices"]
xf["transform<br/>no model"]
ver["verify"]
ctx["engineered context<br/>digests and facts"]
end
subgraph window["the context window"]
bo["breakout<br/>one presentation pass"]
end
goal --> router
router --> mem
mem -- "memory first, then any external call" --> acq
acq --> xf
xf --> ver
ver --> ctx
ctx --> bo
bo --> out["response"]
Interstitials do the turn’s work outside the window at the cheapest tier that suffices, and only the breakout’s presentation pass crosses into it.
Model invocations per turn are therefore bounded by the plan’s shape, not by the meandering of a reasoning transcript, and those that do occur operate on digests, not dumps.
Design Principles
1. Route Cheapest-First, Symbolically
A goal is classified by a symbolic router before any model-driven reasoning is authorized. The tiers, in order: direct dispatch (the goal names one tool: zero inference), symbolic planning (the goal decomposes over the typed tool graph), a compiled-workflow lane (below), and only then the iterative loop. Resolving to no model is a policy tier, not an optimization.
2. The Window Is a Surface, Not a Workspace
Tool results do not enter the window raw. Substantial payloads are reduced to strict digests (schemas, counts, distributions, never verbatim rows) or reshaped server-side before a model sees them; long analytical requests are compressed to short fetch phrases for discovery. The agent’s working memory is the platform: caches referenced by handle, facts in the Logic Cell, results flowing IC-to-IC.
3. Ground Before Propagating
Claims are checked at the boundaries where they can still be cheaply corrected, and the two expressions check different things: the SDK grounds individual claims against facts; the platform gates whole answers on tool evidence. In the SDK, structured claims a model emits are verified against the Logic Cell and diagnosed as grounded, inverted (the reverse relation holds), or unsupported, with bounded re-attempts on failure. On the platform the evidence gate is a heuristic, not a verifier: a keyword classifier marks a goal as data-bearing, an answer counts as evidenced when a non-built-in tool ran or a deliverable was produced, an answer attempted without that triggers a critique-and-replan pass, and the rule that headline figures come only from verified results or are omitted is a prompt instruction.
flowchart TB out["model output"] --> ex["extract relation claims<br/>subject predicate object"] ex --> q["query the Logic Cell<br/>does the relation hold"] q -- "yes" --> g["grounded"] q -- "no" --> inv["query the reverse relation"] inv -- "yes" --> i["inverted<br/>the reverse is the fact"] inv -- "no" --> u["unsupported"] i --> budget["reroll budget left"] u --> budget budget -- "yes" --> re["re-dispatch the interstitial"] re --> out budget -- "no" --> settle["settle with verdicts<br/>recorded in the run report"]
The grounding pass diagnoses each extracted claim as grounded, inverted, or unsupported against the Logic Cell, and re-attempts within a fixed reroll budget before settling.
4. Fail Closed, Visibly
On the platform, an evidence gate not met within budget fails the turn as a first-class outcome: marked, logged with its reason, never replaced by a fluent guess. The SDK is softer: once its reroll budget is exhausted it completes the interstitial with the ungrounded claims recorded as verdicts and a warning, rather than failing the plan. The economic layer takes the same posture: an auction that cannot run produces a blocked task and a terminal event, never a fabricated award.
5. One Architecture, Two Expressions
The platform runtime and the client SDK share one vocabulary of interstitials, plans, breakouts, grounding, and fact surfaces, divided along one line: symbolic state (facts, rules, verification) always lives server-side; execution can live on either side. A client can hand the platform a whole turn through one orchestration tool, or run the same plan shapes locally through the SDK. The intended trajectory is a slider: local sequencing today, compilation of plans into server-executed workflows next.
The Turn Engine
Compiled Workflows with Bounded Repair
Report-shaped, read-only goals qualify for a compile-first lane: the goal is compiled into a small set of declarative workflows (bounded in count and steps), validated by the workflow engine before execution, and repaired up to two times on validation failure with the concrete errors fed back. Survivors execute with cross-step data flow resolved by binding; anything that exhausts its repair budget falls back to the iterative loop with the failure recorded. Compilation is attempted only above a confidence floor. The lane is the platform’s expression of a thesis that runs through the system (see Credit System: Economic Primitives for Autonomous Systems): spend intelligence at compile time, execute deterministically, and make failure a structured, repairable artifact.
Bounded Self-Repair at Three Altitudes
The same repair shape recurs at three scales: compiled workflows repair against validation errors (two attempts); individual tool calls repair their arguments against execution errors (one attempt); and whole turns repair against evidence-gate critiques (bounded replans). In each case the repair input is the concrete failure, not a generic retry, and the budget is fixed. Unbounded self-correction is indistinguishable from a loop; bounded, evidence-fed correction is an architecture.
Observability
Every phase emits typed progress events for the plan, interstitial, and iteration lifecycles over one event vocabulary regardless of entry point (chat surface, API, workspace execution), on per-run topics external clients subscribe to over the platform’s push channel. A turn is reconstructable from its trail: what was routed where, which ICs ran, what they cost, what was repaired, and why the breakout said what it said.
The SDK Expression
The client SDK is thin: typed plan and interstitial definitions, a local sequencer that dispatches ICs in dependency order, typed bindings for the platform’s tool surface, and a client trait with a single required method, so the execution loop is drivable against a mock or a live gateway without code changes; a composite of subordinate agents is the intended extension point behind that trait, not a shipped implementation. There is no embedded logic engine; the SDK’s Prolog is the platform’s Prolog, reached over the wire (see Arbiter Substrate: OS-Level Governance for Autonomous AI Agents for the transport and identity layer it rides).
The SDK runs the cycle described above locally and reports over the shared event vocabulary. Two mechanisms are its own. The grounding pass of Principle 3 works on the structured parts of model output (leverage edges, relation lists, and the evidence attached to findings; prose is not grounded), and its inversion-versus-absence diagnosis is the one that matters, because inverted claims are the confident ones. And plan state lives in the substrate: the runtime writes each node’s execution state into a dedicated rule pack’s predicates as it runs, so a plan’s progress is queryable, resumable, and visible to other agents like any other fact.
The compiled-workflow lane, the evidence gate with its fail-closed turn, and in-process execution of awarded tasks stay platform-side; the SDK completes with warnings where the platform would fail. Its execution state, grounding verdicts, per-node traces, and push events roll up into a run report whose terminal output is a breakout.
Workspaces: Where the Two Expressions Meet
Multi-agent coordination is an economic mechanism, not a protocol. A workspace is an event-sourced space into which tasks arrive; agents join with personas (mission, capabilities, policy envelope, budgets); an arbiter awards each task by auction.
Bidding is symbolic: workspace state is materialized as facts, eligibility is gated first (capacity, budget, policy constraints, tool permissions, integration allowlists), and a Prolog arbiter scores every eligible agent on six axes (fit to the goal, capability coverage, cost, risk, current load, historical confidence) under a pluggable award strategy (best total, cheapest, cheapest above a quality threshold, best value). Award deducts the task’s cost from the winner’s credit allocation at award time (see Virtual Resource Accounting: Decoupled Agent Budgets for Autonomous Systems); insufficient credits is a visible terminal outcome.
The consequential property is who can bid. Platform-resident agents execute awarded tasks in-process through the turn engine. External agents, connected over the platform’s mutual-TLS identity plane, receive awards as push events and complete them through an authenticated API, with heartbeats maintaining their lease. Both compete in the same auction, scored on the same axes, charged from the same budgets, and audited in the same event log. “One architecture, two expressions” is enforced by the market both expressions transact in.
flowchart TB task["task arrives<br/>in the workspace"] --> facts["materialize workspace state<br/>as Prolog facts"] facts --> gate["eligibility gates<br/>capacity budget policy permissions"] gate --> score["score each eligible agent<br/>fit capability cost risk load confidence"] score --> strat["award strategy<br/>best total or cheapest or best value"] gate -- "no eligible agent" --> blocked["blocked task<br/>terminal event"] strat -- "winner" --> award["award and deduct credits<br/>at award time"] award -- "insufficient credits" --> blocked award --> local["platform resident agent<br/>runs the turn engine in process"] award --> remote["external SDK agent<br/>receives the award as a push event<br/>completes over the mTLS API"] local --> log["shared event log<br/>and settlement"] remote --> log
Both expressions enter the same auction: facts are materialized, eligibility is gated, six axes are scored, and the award charges credits whether the winner runs in process or remotely.
The scoring heuristics are at different maturities — load and historical confidence are computed from live data; fit and capability use coarse matching pending semantic scoring; risk is a placeholder — so the mechanism (fact materialization, symbolic scoring, award, execution, settlement) is complete while several scoring functions remain simple, and improving one is a rule change, not a redesign.
Token Economics
The cycle’s economics compound across four mechanisms:
- Routing displaces inference. Goals resolved at the direct or planned tiers spend nothing reasoning about how to proceed; the router and planner are symbolic.
- The zero-model tier is real. Deterministic ICs (memory checks, transforms, symbolically-routed executions) are not “cheap model” calls; they are no call.
- Digests replace dumps. The model passes that do run receive aggregates and schemas, not payloads.
- The breakout is one pass. In the plan lane two passes cross the window, a synthesis interstitial on the planner model (the expensive one) and then the breakout’s re-presentation on the mini model; in the iterative lane a single synthesis pass on the planner model produces the response. Either way the cost is paid over engineered context, not across every intermediate step.
Model selection follows the same discipline: task-typed tiers assign each responsibility the least model that reliably serves it.
Comparison with Agent Frameworks
| Dimension | Conventional framework | Agentsmith |
|---|---|---|
| Unit of work | LLM loop iteration | Interstitial/breakout cycle |
| Working memory | Context window | Platform substrate (caches, facts, IC results) |
| Loop location | Client application | Platform runtime; SDK optional |
| Routing | Model decides | Symbolic router, cheapest-first |
| Grounding | None / self-assessment | Fact-checked claims (SDK); evidence-gated answers, fail-closed (platform) |
| Repair | Open-ended retries | Bounded, failure-fed, at three altitudes |
| Multi-agent | Message-passing protocols | Economic auction over symbolic scoring |
| Cost model | Emergent | Routed, tiered, settled per task |
Limitations and Honest Boundaries
The iterative loop still exists. Goals that defeat routing, planning, and compilation fall back to a conventional reasoning loop: governed, digest-fed, evidence-gated, but iterative. The claim is that the loop is the last resort, not that it is gone.
Several designed mechanisms are ahead of their implementations. Uncertainty profiles that would modulate rerolls and admissible IC types, divergent interstitial types for exploratory work, and orchestration responses carrying execution certificates are specified, not built. Grounding re-attempts re-dispatch rather than feeding the contradiction evidence into the retry. Auction scoring maturity is stated above.
Two expressions cost two test surfaces. The vocabulary is shared; the implementations are not, and parity between the platform lane and the SDK lane is maintained by discipline and tests rather than by construction.
Future Directions
Certified Orchestration
Plans returned by the orchestration surface will carry the signed execution certificates that govern compiled workflows (see Cognitive Trust Certificates: Verifiable Execution Proofs for Autonomous Systems), so a client can verify a plan’s structural properties before executing it locally.
Uncertainty as a Control Surface
A turn’s routing, reroll budgets, and admissible IC types should be functions of how well-defined the goal is and how complete the agent’s world model is. The profile machinery exists as specification; inferring it per turn and letting it modulate the cycle is the next layer.
Semantic Auction Scoring
Fit and capability scoring move from lexical matching to the platform’s semantic type system (see Semio: A Semantic Interface Layer for Tool-Oriented AI Systems): an agent’s capability surface and a task’s requirements are both typed, and coverage becomes a computation rather than a heuristic.
Divergent Interstitials
The convergent IC inventory reduces uncertainty toward a goal. Its complement, interstitial types that widen the conceptual surface before converging, is specified in the SDK vocabulary and pairs with the platform’s latent navigation instruments.
This document describes the conceptual architecture of Agentsmith. Routing rules, scoring weights, prompt construction, repair budgets’ tuning, and protocol details are part of the operational implementation and are not specified here.