{
  "access": "public",
  "type": "reference",
  "format": "markdown",
  "title": "DataGrout: An Operating System for Agents",
  "url": "https://labs.datagrout.ai/papers/datagrout-os",
  "summary": "DataGrout is Intelligence Infrastructure for Autonomous Systems: a hosted substrate that agents, coding tools, game engines, and proxies reach through one gateway, and that gives them what a process gets from an operating system (isolated memory, scheduling, resource accounting, governance, one system-call path) in the forms an agent needs. The operating system is the working analogy, and the mapping holds: processes are agents with budgets and capabilities, memory is a Logic Cell, the system-call layer is one enforcement chain, the file system is a catalog of addressable tools, the shell is a client SDK. Eight labs papers document the subsystems. This one describes the whole.\n\nThe argument has three parts. First, a systems argument: a persistent Prolog fact substrate, certified execution, metered economics, and a set of tool suites only make sense together, because each depends on facts the others produce; the combination, not any part, is the contribution. Second, the tool suites as a context-engineering toolkit for agents: on the order of two hundred first-party tools in a few dozen suites, most of them model-free, and thousands of typed integration tools a user multiplexes onto a server, all behind five discovery tools; what a server sees depends on its account's features and on what it has enabled. Its mechanisms (shapes with handles that chain, long calls promoted before the client times out, discovery that reports what is missing, a planner composed with execution) are ones whose combination the author has not found elsewhere at time of writing. Third, a map from layer to paper. An operating system is never adopted for itself; this paper exists because the things running on this one have started to accumulate.",
  "topics": [
    "systems-architecture",
    "context-engineering",
    "agent-infrastructure",
    "governance",
    "prolog"
  ],
  "content_markdown": "## Abstract\n\nDataGrout is Intelligence Infrastructure for Autonomous Systems: a hosted substrate that agents, coding tools, game engines, and proxies reach through one gateway, and that gives them what a process gets from an operating system (isolated memory, scheduling, resource accounting, governance, one system-call path) in the forms an agent needs. The operating system is the working analogy, and the mapping holds: processes are agents with budgets and capabilities, memory is a Logic Cell, the system-call layer is one enforcement chain, the file system is a catalog of addressable tools, the shell is a client SDK. Eight labs papers document the subsystems. This one describes the whole.\n\nThe argument has three parts. First, a systems argument: a persistent Prolog fact substrate, certified execution, metered economics, and a set of tool suites only make sense together, because each depends on facts the others produce; the combination, not any part, is the contribution. Second, the tool suites as a context-engineering toolkit for agents: on the order of two hundred first-party tools in a few dozen suites, most of them model-free, and thousands of typed integration tools a user multiplexes onto a server, all behind five discovery tools; what a server sees depends on its account's features and on what it has enabled. Its mechanisms (shapes with handles that chain, long calls promoted before the client times out, discovery that reports what is missing, a planner composed with execution) are ones whose combination the author has not found elsewhere at time of writing. Third, a map from layer to paper. An operating system is never adopted for itself; this paper exists because the things running on this one have started to accumulate.\n\n---\n\n## Problem Landscape\n\n### Agents Are Processes Without an Operating System\n\nEvery agent framework ships the same loop: a model that calls tools, with some memory. Processes need isolation, scheduling, memory management, resource accounting, and governance; without a kernel, every application rebuilds them ad hoc and incompatibly. Agents have the same needs: memory that does not leak, budgets that end, policies that hold, evidence that the work was safe. Each agent application rebuilds these, at token cost, every turn.\n\n### Composition Is the Contribution, and It Is Invisible\n\nEach subsystem here has a competitor that does the one thing: vector stores remember, policy proxies filter, metering services bill, tool routers route. Bought separately, they do not share a fact: the memory layer cannot tell the policy layer what it knows, a rule cannot read the meter, the evidence for one step does not chain to the next. A shared substrate removes that cost, and the removal is hard to see, because the absence of glue is not a feature anyone can point at. Nobody adopts an operating system; they adopt a thing that runs on it.\n\n### Payloads Are the Wrong Unit\n\nThe default contract between a tool and an agent is a payload: the tool returns the data and the agent reads it. For a five-thousand-row result that contract spends the context window on rows the agent will aggregate and discard. The agent wanted the shape of the result and a way to refer to it; it received the result. Much of the toolkit answers that one mismatch.\n\n---\n\n## Design Principles\n\n### 1. One Fact Substrate\n\nEverything that persists, persists as typed facts in a Logic Cell namespace (*Logic Cells: A Persistent Prolog Substrate for Governed Agents*). Memory journals, navigation atlases, code indexes, checkpoints, and install state are all facts, so a rule can join any of them and there is no second store to reconcile.\n\n### 2. One Front Door\n\nEvery call, from every transport and every client, and from inside a running proof, traverses the same enforcement chain. A rule mid-inference is exactly as governed as the agent that admitted it.\n\n### 3. Neural for Intent, Symbolic for Search and Proof\n\nThe model parses intent and formats results; planning is exhaustive search over a typed tool graph, policy is rules that exclude invalid plans from the search space rather than filtering them afterward, and a certificate is a proof trace. Neither side does the other's job.\n\n### 4. Shapes Before Payloads\n\nA large result's default representation is its shape plus an addressable handle to the payload held server-side. Operations over the handle mint new handles, so work stays server-side until a final, usually small, answer is needed.\n\n### 5. Every Step Leaves Evidence\n\nCertificates for admitted rules, queries, and executed plans; receipts for deterministic computation and for recall; an execution identifier on every call. The evidence travels in the response envelope, not in a log the agent would have to find.\n\n### 6. Cost Is a Type\n\nCredits are a field in every response, with estimated, charged, and saved as separate numbers, and an estimate is available before execution. Running out is a structured error every spending tool handles.\n\n### 7. Degradation Is Declared\n\nWhen a mechanism cannot do what it usually does, the response says so in a field. A weaker result never wears the shape of a stronger one.\n\n---\n\n## Architecture\n\n```mermaid\n%%{init: {\"flowchart\": {\"wrappingWidth\": 290}}}%%\nflowchart TB\n  subgraph A[\"applications\"]\n    direction TB\n    a1[\"Agentsmith<br/>Manifold\"]\n    a2[\"Reactor apps<br/>Tether\"]\n    a3[\"Lumen, Invariant<br/>Conduit clients\"]\n  end\n  subgraph T[\"toolkit: a few dozen suites\"]\n    direction TB\n    t1[\"discovery and planning<br/>summary, discover, plan, guide, perform\"]\n    t2[\"shaping and addressing<br/>head, cache_ref, prism.*\"]\n    t3[\"model-free suites<br/>data, frame, math, signal, linalg<br/>logic, runs, reactor\"]\n    t4[\"memory, navigation, logic<br/>attention, latent, logic, inference\"]\n    t5[\"safety and observability<br/>warden, invariant, watchtower, lumen\"]\n    t6[\"integrations and mux<br/>typed vendor contracts, quick mux, demux\"]\n    t1 ~~~ t4\n    t2 ~~~ t5\n    t3 ~~~ t6\n  end\n  subgraph K[\"kernel\"]\n    direction TB\n    k1[\"Logic Cell substrate<br/>facts, rules, namespaces\"]\n    k2[\"certificates<br/>CTC, deterministic receipts\"]\n    k3[\"credits<br/>estimate, charge, ledger\"]\n  end\n  g[\"gateway: the system-call boundary<br/>MCP, JSON-RPC and REST, WebSocket<br/>one server, one enforcement chain\"]\n  A -- \"every call\" --> g\n  g -- \"enforcement chain, then dispatch\" --> T\n  T -- \"persists into, is evidenced by\" --> K\n```\n\n*Four layers. Every call from an application crosses the gateway, whose one enforcement chain fronts the toolkit; the toolkit persists into and is evidenced by the kernel; and the kernel's evidence returns to the caller in the envelope the gateway attaches.*\n\n### The Gateway\n\nMCP defines the transport and calling convention between an agent and its tools, not which tool to call or how to plan, verify, enforce, meter, or remember; the gateway is the layer above the protocol, and the protocol is one of three ways in. All three land on one gateway server: MCP over streamable HTTP at `/mcp`; JSON-RPC over HTTP at `/rpc`, with a plain REST form at `/call`; and a WebSocket subprotocol, `datagrout-jsonrpc.v1`, at `/ws` with idle timeout, keepalive, and server-push events. Binary frames on the socket are reserved for a CBOR codec (the core profile, with typed arrays for numeric vectors): a binary frame is CBOR and a text frame JSON, negotiated per frame and priced identically; the codec is decided, not shipped. The JSON-RPC and WebSocket surfaces exist because MCP's request-reply shape fits an assistant's turn but not a game loop's tick or a proxy's stream.\n\nOne enforcement chain applies to every call, in a fixed order: runtime meta (client identity, deadline, run context), then policy (SemanticGuard: PII exposure, side effects, destructive operations, integration allowlists; the model is *Runtime Policy Enforcement for Autonomous AI Systems*, the system-call framing *Arbiter Substrate: OS-Level Governance for Autonomous AI Agents*), then Warden preflight, gated per account (*Warden: Multi-Tier Advisory Detection for Prompt Injection*), then ToolRunner, then redaction. A credits balance gate runs ahead of the chain, and each call receives an `execution_id`, so downstream evidence groups per execution.\n\n**Intelligent-interface mode**, on by default at signup, advertises five tools: `discovery.summary`, `discovery.discover`, `discovery.plan`, `discovery.guide`, and `discovery.perform`. Everything else is reached through `perform`, so the client's tool list stays five entries long regardless of what is enabled, which answers the tool-definition cost that pushed the field toward deferred loading, and the chain gains a choke point: an unadvertised tool is only callable through the one verb that is.\n\n### The Kernel\n\nThe **Logic Cell substrate** is the fact store: persistent, namespaced Prolog environments with certified rule admission and governed re-entry, so `call_tool` from inside a proof traverses the same gateway chain.\n\n**Certificates** are the evidence type. Cognitive Trust Certificates (*Cognitive Trust Certificates: Verifiable Execution Proofs for Autonomous Systems*) are minted for admitted rules, for queries (chained to the rules the proof exercised), and for executed plans; every envelope carries `ctc {valid, url, assurance}`, and a certificate is readable as plain text at `/api/ctcs/:id/txt` and validated as JSON. A certificate is a persisted row, not only a field in the response: per-run certificates (a query, an executed plan) expire after seven days, admission certificates for rules do not, and the viewer URL resolves for as long as the row lives. Deterministic tools attach a smaller artifact, the **deterministic receipt**: the tool, a SHA-256 fingerprint over tool plus canonical arguments plus output, and a timestamp, so a computation can be re-run and compared byte for byte. The canonical form hashes numeric output as packed little-endian float64 bytes rather than decimal text and excludes the `records` projection, which is a deterministic function of the values; the receipt's `canonical` field names the form that produced the fingerprint, since an identifier derived under one form differs from the other.\n\n**Credits** are the meter (*Credit System: Economic Primitives for Autonomous Systems*; *Virtual Resource Accounting: Decoupled Agent Budgets for Autonomous Systems*). Every envelope carries `credits {charged, estimated, premium, llm, saved, remaining}`. Gateway base and tool premium are separate figures; exact LLM spend accumulates per run in a ledger and is billed once; the premium is waived when a result is not delivered (`waived_undelivered`), the gateway base and LLM passthrough never. `estimate_only: true` runs the pricing path, bypasses the balance gate, and is stripped from the arguments before anything executes.\n\n### The Envelope\n\nEvery response carries `_dg`, the account of what just happened, in the response rather than beside it; the block under Shaping and Addressing shows its keys, with `flux` present when a Flux constraint fired and `deterministic_receipt` where one applies.\n\n### Discovery and Planning\n\n`summary` returns a compact overview of the catalog, with per-suite and policy focuses and a count of hidden tools, so an agent knows the catalog is filtered rather than small.\n\n`discover` is semantic search over the catalog. Its distinguishing output is **coverage gaps**: the tools that would serve the goal but are not enabled on this server, so an agent asking for invoices with no accounting integration enabled learns that the tool exists and is off, not that nothing matched.\n\n`plan` takes a goal, or a batch of `goals`, and returns ranked plans over the typed tool graph that Semio types and adapters provide (*Semio: A Semantic Interface Layer for Tool-Oriented AI Systems*); `lean` returns one recommended plan and its `skill_handle`, `verify` has a small model check plan fit, and `execute` runs a ready plan in the same call. The output names `needed` input holes and registers certificate-valid plans as `virtual_skills`. A plan-only call also certifies the recommended plan at plan time, where it is certificate-eligible: a `data-grout/plan@1` certificate is persisted with its evidence at stage `planned`, returned as `ctc` and `plan_ctc_id`, and remembered by the `skill_handle`. When the handle is performed, the executed chain lists the planned certificate as a sub-certificate under a `plan` step and stamps the execution back onto its evidence, outside the signed payload, so the plan's certificate and the run's are one chain.\n\n`guide` is dialog-tree navigation over the catalog (*Guided Navigation: Tool Meshes as Dialog Trees*).\n\n`perform` executes a `tool_name` with `args`, a `skill_handle` from `plan`, or a saved `skill_id`, with `save_as_skill` to persist a sequence that worked; `demux` runs one tool across the user's servers, `strict` or `fuzzy`.\n\n### Integrations and the Mesh\n\nThe first-party suites are a minority of what a server can expose. Behind them sits a catalog of **integration tools**: typed contracts over vendor APIs, authored in Toolsmith by the platform's researchers and subject-matter experts rather than generated from OpenAPI documents. Each carries an intermediate representation of the request it makes, input and output schemas, dependencies, and annotations. The catalog runs to thousands of tools, the largest packs over Oracle Fusion, Salesforce Sales Cloud, and QuickBooks Online, with further packs across ERP, data-warehouse, messaging, and workspace vendors. Not every tool is production-ready at a given time, and which packs an account can enable depends on its features, so the count a server sees is smaller than the catalog.\n\nAn integration is **multiplexed** onto a user's server: enabling it records the selection, invalidates the server's tool cache, and on the next materialization its tools appear in one flat namespace alongside the first-party suites. Arbitrary MCP endpoints join the same way through **quick mux**: a curated list of upstream servers with auth flows pre-configured, or any external MCP server the user registers by URL. Muxing runs a pipeline over each tool as it arrives: it is materialized as a descriptor on the server; an annotation pass (model-backed, hash-keyed so it reruns only when the contract changes) writes the semantics discovery needs, including which Semio types the tool consumes and produces; policy metadata is attached, with PII inferred from the tool's name where no annotation declares it; the annotated tool is embedded so `discover` can find it; and its typed edges join the graph the planner walks. Semio types are a shared vocabulary, so a `billing.invoice` from one vendor's tool is the same type as another's; what is per user is the set of tools carrying those types.\n\nThe consequence is that **discovery and planning operate over the user's mesh**, not a global catalog: `summary`, `discover`, and `plan` read the tools materialized for the calling server, filtered by its policy, and a plan can only route through tools the user has muxed. `demux` is the inverse: one call fanned across the user's servers, `strict` for the same tool name on each, `fuzzy` for any tool whose Semio types match, so \"create an invoice\" reaches every accounting system the user has connected in one governed, metered call.\n\n### Shaping and Addressing\n\n`perform` carries a post-processing pipeline: `analyze` {goal, mode: deductive | causal | comparative | exploratory, depth: shallow | deep}, then `refract` (a reshaping goal), then `chart`, in that order, in one call. The parameter that changes the contract is `head`.\n\n**Head** returns the shape of a large result instead of the result: `record_count`, `schema`, a partial `preview`, a `cache_ref` to the payload held server-side, and `_answer_from: \"cache_ref\"` with an instruction to make one follow-up `perform` over the ref.\n\n```json\n{\n  \"record_count\": 4812,\n  \"schema\": {\n    \"fields\": [\n      { \"name\": \"Id\", \"type\": \"string\" },\n      { \"name\": \"Name\", \"type\": \"string\" },\n      { \"name\": \"Amount\", \"type\": \"number\" },\n      { \"name\": \"StageName\", \"type\": \"string\" },\n      { \"name\": \"CloseDate\", \"type\": \"date\" }\n    ]\n  },\n  \"preview\": [\n    { \"Id\": \"006A1\", \"Name\": \"Atlas renewal\", \"Amount\": 48000, \"StageName\": \"Negotiation\", \"CloseDate\": \"2026-09-30\" },\n    { \"Id\": \"006A2\", \"Name\": \"Meridian expansion\", \"Amount\": 120000, \"StageName\": \"Proposal\", \"CloseDate\": \"2026-10-15\" },\n    { \"Id\": \"006A3\", \"Name\": \"Quartz pilot\", \"Amount\": 9500, \"StageName\": \"Qualification\", \"CloseDate\": \"2026-11-02\" }\n  ],\n  \"preview_note\": \"3 of 4812 records shown; the preview is partial and must not be aggregated\",\n  \"cache_ref\": \"rc_7f3a9c1e2b\",\n  \"next_tools\": [\"frame.group\", \"data.aggregate\", \"math.describe\", \"prism.paginate\"],\n  \"_answer_from\": \"cache_ref\",\n  \"instruction\": \"Make ONE follow-up discovery.perform over cache_ref rc_7f3a9c1e2b to compute the answer server-side.\",\n  \"_dg\": {\n    \"cache_ref\": \"rc_7f3a9c1e2b\",\n    \"tool\": \"salesforce@1/query_opportunities@1\",\n    \"execution_id\": \"exec_01j9r4k6m2\",\n    \"session_handle\": \"sh_2c81\",\n    \"credits\": { \"charged\": 3, \"estimated\": 3, \"premium\": 2, \"llm\": 0, \"saved\": 0, \"remaining\": 9412 },\n    \"ctc\": { \"valid\": true, \"url\": \"/api/ctcs/ctc_5d0e7a/txt\", \"assurance\": \"runtime\" },\n    \"summary\": \"4812 opportunity records; shape returned, payload cached for 10 minutes\"\n  }\n}\n```\n\nA **cache_ref** is an addressable result: an `rc_` handle with a ten-minute TTL extendable to sixty, content-keyed so identical results deduplicate, isolated per user, and accepted anywhere a payload is. The `data.*`, `frame.*`, and `prism.*` suites re-mint refs on output, which is what makes refs chain: a filter over a ref yields a ref, a group over that yields a ref, `math.describe` over that yields numbers.\n\nNot every payload problem is a handle problem. Every series tool returns `values` and a `records` projection of the same numbers, and a caller that charts from the values pays for bytes it never reads: in Bench's three-step signal chain over a 1,024-sample frame (Bench is under What Runs On It) the projection was about two thirds of the result, enough to push every run over the inline budget into a cache fetch. `records: false` empties the projection and says so in `records_omitted`, for the math, signal, and linalg suites, applied in ToolRunner after execution; `flow.into` drops its duplicate per-step list with `step_outputs: false`. For a client that runs the same plan every frame, the next unit of accounting is a lease over the plan rather than a call per frame, decided and not shipped, under Future Directions.\n\nRefs are **ephemeral by default**: `ephemerals.list` shows what is live, and `ephemerals.inspect` returns a ref's schema, sample rows, and source chain while extending its TTL by ten minutes, both without premium. When a result should outlive its TTL, `deliverables.register` promotes it to a **deliverable**, a durable record retrievable by a `del_` ref through `deliverables.get` that holds the payload the caller attaches and the ref as provenance, so a working session ends in handles the agent can hand back later rather than in a payload it must carry.\n\n```mermaid\nflowchart TB\n  r[\"request<br/>discovery.perform, head: true\"] --> b[\"credits balance gate<br/>execution_id minted\"]\n  b --> p[\"policy<br/>PII, side effects, destructive ops, allowlists\"]\n  p --> w[\"Warden preflight<br/>gated per account\"]\n  w --> t[\"ToolRunner<br/>the tool executes\"]\n  t --> x[\"redaction\"]\n  x --> s[\"shape<br/>record_count, schema, preview, next_tools\"]\n  s --> c[\"cache_ref minted<br/>payload held server-side\"]\n  c --> e[\"envelope<br/>credits, ctc, execution_id, receipt\"]\n  e --> f[\"follow-up perform<br/>data.* or frame.* over the ref\"]\n  f --> c2[\"new cache_ref<br/>refs chain\"]\n```\n\n*One call's life under head. The payload never enters the reply; the shape, the handle, and the evidence do, and the follow-up over the handle mints another handle.*\n\n### Asynchronous Promotion\n\nMCP clients time out, so a call that outruns the client's limit fails on the client while succeeding on the server, and the retry becomes a second charge. The gateway resolves a deadline per call from an explicit `timeout` (zero or below means never promote), else a per-tool default (35 s in general, 55 s for `plan` and `guide`, 75 s for `perform`, 95 s for inline `execute`), else a per-client cap (95 s for Claude Code, 85 s for n8n, 50 s otherwise). When the deadline arrives first, the call is **promoted**: the reply carries `status: \"background\"` and `_dg.task_ref`, and a repeat of the same call while the task runs returns the same `task_ref` at zero cost, so a retry on timeout yields the handle, not a second execution.\n\n```mermaid\nflowchart TB\n  d[\"deadline resolution<br/>explicit timeout, else per-tool default, else client cap\"] --> run[\"call runs inline\"]\n  run -- \"finishes first\" --> rep[\"ordinary reply<br/>with envelope\"]\n  run -- \"deadline first\" --> pro[\"promoted to a background task<br/>status: background, _dg.task_ref\"]\n  pro --> wt[\"tasks.wait or tasks.status\"]\n  pro -- \"repeat call while running\" --> same[\"same task_ref<br/>zero cost\"]\n  wt --> res[\"result and envelope<br/>when the task completes\"]\n```\n\n*Promotion is decided by a deadline the server knows before the client does, so the client sees a handle instead of a timeout.*\n\n### Model-Free by Default\n\nMost of the toolkit runs with no model in the loop. The suites sort into three tiers by what executes when they are called; the third is the named minority.\n\n**Pure** tools are functions of their inputs alone: `data.*`, `frame.*`, `math.*`, `signal.*`, and `linalg.*`. Same arguments, same output, each with a deterministic receipt; they carry no premium and charge one gateway base each, `data.map` excepted because it evaluates a caller-supplied expression per record. They are why head is usable: the operations an agent would otherwise perform in context are available over the ref at a cost independent of payload size. Bench, under What Runs On It, is the visual test of the signal and linalg suites.\n\n**Symbolic** tools are model-free but stateful: their output depends on facts, refs, or records the platform holds, so it is reproducible given the same state. This is the largest tier: `logic.*` on its direct paths (assert, query by goal or pattern), `ephemerals.*`, `deliverables.*`, `tasks.*`, `reactor.*`, and the navigation steps of `guide`, among others. A query over a Logic Cell returns what the cell holds today; that is state, not sampling. Reads are often free of premium; writes, rule admission, and publication carry fixed premiums.\n\n**Model-backed** tools run a model inside the call: the `prism.*` transforms, the `latent.*` instruments, `inference.invoke`, `agents.orchestrate`, the four `warden.*` tiers (the canary is dual generation across a weak and a strong model, so even the cheapest tier samples), and the natural-language paths of `logic.remember`, `logic.query`, and `logic.constrain`. These carry the largest premiums and a nonzero `llm` figure in the envelope. Embedding lookups (`attention.nearest`, `discover`) place text in a vector space and generate nothing, and are counted with this tier for honesty of accounting.\n\nThe pricing table says where suites straddle the line: `logic.query` charges one credit for a Prolog goal or a pattern and three for a natural-language question, because only the third path translates through a model. The distinction is not deterministic versus not; it is whether a model samples inside the call. Pure tools are deterministic in the strict sense, symbolic tools are deterministic given the platform's state, and only the third tier samples.\n\n### The Rest of the Toolkit\n\nThe tiers sort the catalog by what executes; `discovery.summary` groups it by use: memory, navigation, and logic (`logic.*`, `attention.*`, `latent.*`); shaping and delivery (`prism.*`, `ephemerals.*`, `deliverables.*`); orchestration and time (`tasks.*`, `scheduler.*`, `flow.*`, `toolsmith.*`); and safety and observability (`warden.*`, `invariant.*`, `watchtower.log`, `lumen.*`). Which suites a server exposes depends on feature flags and account access; `summary` reports what is enabled and what policy hides, so the catalog an agent sees is the one it can call.\n\n### Declared Degradation\n\nThe seventh principle is visible as fields: `seed_mode` in hydration receipts when semantic seeding fell back to recency; `validated: false` and `exercise_basis` on logic certificates; `frontier_dry` from the latent atlas; `insufficient_credits` as a structured error; the hidden-by-policy count in `summary`. Each is a field to branch on, not an exception.\n\n---\n\n## What Runs On It\n\nEach of these adopted a thing it wanted; the substrate is what they turned out to share.\n\n**Agentsmith** (*Agentsmith: A Symbolically-Grounded Agent Architecture*) is the agent loop, reached through `agents.orchestrate`; its interstitial cycle (hydrate, assert and query, checkpoint) is the toolkit's most frequent client.\n\n**Manifold** (*Manifold: A Token-Efficient Coding Agent*) is the coding agent, an ordinary MCP client whose navigation predicates run in the Logic Cell that holds the session journal.\n\n**Reactor apps** are `.api` endpoints and `.sp` smart panels served from Logic Cell rules, the rule head parsed as the request contract; their paper is scheduled.\n\n**Tether** is the family of game-engine clients, maintained outside the platform, for which a Logic Cell is the authoritative rules engine, one batched round trip per tick.\n\n**Lumen** is the usage proxy and fleet surface; the `lumen.*` suite is its gateway face, and its captured turns feed the memory journal.\n\n**Invariant** is a Rust static-analysis toolchain, published as crates and exposed to agents through `invariant.*`.\n\n**Bench** is a DSP workbench (live scope, meter, spectrum, a declarative pass/fail spec), public and in Rust, that doubles as a reference application on the gateway: a round trip per frame is not an oscilloscope, so the trace runs locally at 60 fps and the gateway sees one captured frame at a time, on demand or at a chosen rate with the credit cost per minute shown beside the toggle. A chain built by hand compiles to the same `flow.into` plan an agent would submit and mints as a skill with its certificate; derived features land in a Logic Cell as facts, so the pass/fail spec is derived rather than computed in app code; minted skills are served at a local loopback endpoint, and a picker docks the account's smart panels. It found two limits by running: a `flow.into` run costs about five credits regardless of the zero-premium tools inside, so auto-analysis ships off and capped at 4 Hz, and results over about 48 KB return headed with a `cache_ref`, which it fetches with one `prism.paginate` call. `records: false` exists because of it.\n\n**Conduit SDKs**, in five languages, carry the mTLS identity bootstrap and the stdio adapters the server does not, so a program in any of them is a governed client from its first call.\n\n---\n\n## Relation to Concurrent Work\n\nBy mid-2026 the field has arrived, independently and at scale, at several of the ideas here: first-party tool search and deferred tool loading from model vendors; MCP as the common protocol between assistants and tools; memory tiers and context compaction in assistants; repository indexes in coding agents; and the code-execution-over-tools pattern, in which the model writes a small program that calls tools and returns only its result.\n\nThis paper does not claim priority for tool search or memory tiers; those are the platform's versions of ideas the field reached on its own. What it adds is the composition a product-scoped implementation does not attempt: one fact substrate for every subsystem's state, one governed choke point for every call, shape-first results with handles that chain across tools, a certificate or receipt on every step in the response, and metering as an envelope field with an estimate before the call. Code-execution-over-tools is the nearest relative of head plus refs; here the composition is tool-to-tool over server-held handles, governed and metered per step, not a program the model writes and a harness runs.\n\n---\n\n## Provenance\n\nThe architecture's design notes predate the platform (synapsOS, 2023). The platform has shipped continuously since, in public where it could: crates on crates.io (invariant-core, invariant-cli, tether-cli, datagrout-conduit, logic-batteries, tree-sitter-prolog) and the labs papers from January 2026 onward. This paper describes the system as running in September 2026.\n\n---\n\n## The Series\n\n| Layer | What it is | Paper |\n|---|---|---|\n| Interface types | The typed tool graph the planner walks | *Semio: A Semantic Interface Layer for Tool-Oriented AI Systems* |\n| Evidence | Certificates for rules, queries, and plans | *Cognitive Trust Certificates: Verifiable Execution Proofs for Autonomous Systems* |\n| Policy | The per-call enforcement chain | *Runtime Policy Enforcement for Autonomous AI Systems* |\n| System-call layer | Governance as an operating-system concern | *Arbiter Substrate: OS-Level Governance for Autonomous AI Agents* |\n| Safety | Advisory prompt-injection detection; the preflight stage | *Warden: Multi-Tier Advisory Detection for Prompt Injection* |\n| Fact substrate | Persistent Prolog namespaces, certified admission, governed re-entry | *Logic Cells: A Persistent Prolog Substrate for Governed Agents* |\n| Economics | Credits as the unit of cost | *Credit System: Economic Primitives for Autonomous Systems* |\n| Economics | Budgets decoupled from the meter | *Virtual Resource Accounting: Decoupled Agent Budgets for Autonomous Systems* |\n| Code verification | Semantic checks over generated code; the `invariant.*` suite | *Consequential Analysis: Semantic Verification of AI-Generated Code* |\n| Runtime | Reflexes over stored facts before a model is called | *Governor: Neuro-Symbolic Runtime for Token-Efficient Agent Cognition* |\n| Reasoning pattern | Structured investigation over accumulated facts | *Forensic Inference: Structured Agent Reasoning Over Accumulated Facts* |\n| Application: agent | The interstitial cycle | *Agentsmith: A Symbolically-Grounded Agent Architecture* |\n| Application: coding | Navigation predicates over a codebase | *Manifold: A Token-Efficient Coding Agent* |\n| Navigation | Instruments over concept space; the `latent.*` suite | *Latent: Navigation Instruments for Concept Space* |\n| Discovery | The `guide` tool as a dialog tree | *Guided Navigation: Tool Meshes as Dialog Trees* |\n| Memory | The journal, the detail ladder, hydration receipts | *Attention Cloud: Memory as a Rendering Problem* |\n| Web discovery | Machine-native discovery of sites and services | *AI Link Layer (AIL): A Machine-Native Discovery Protocol for the Web* |\n| Program space | Program space as a navigable map (scheduled, November 2026) | *Cartographic Navigation: Mapping Program Space* |\n| Selection theory | Context assembly as a field computation (scheduled, December 2026) | *The Physics of Context* |\n| The whole | Why the layers are one system | this paper |\n\n---\n\n## Limitations and Trade-Offs\n\n**The composition is the product, and it cannot be benchmarked in parts.** The platform's measurements cover paths, not the substrate, because the substrate's value is the absence of integration work, which no single run isolates. The systems argument here is an argument, not a measurement.\n\n**One front door is one dependency.** Every call pays the chain's latency and the gateway base, and a gateway outage stops every client at once.\n\n**Refs expire, and they do not cross users.** A ten-minute TTL suits a working agent, not one that pauses; `ephemerals.inspect` extends it and `deliverables.register` keeps a durable record, but an agent that does neither recomputes the work. Per-user isolation also means a ref cannot be handed to a colleague.\n\n**Head is a contract the model must honor.** `_answer_from: \"cache_ref\"` and the partial-preview marker are fields; a model that ignores them and totals the preview produces a wrong answer inside a clean envelope. The platform can declare; it cannot compel the reader.\n\n**Promotion changes the reply shape.** A client that does not check for `status: \"background\"` treats a promoted call as malformed. The per-client caps keep promotion rare; they do not make it invisible.\n\n**The adoption problem is not solved by describing it.** The remedy is the list under What Runs On It, and that list is short.\n\n---\n\n## Future Directions\n\n### Durable and Shareable Refs\n\nA deliverable gives a ref a durable record and a durable handle without copying its records; persisting a ref as a fact in the caller's Logic Cell, payload materialized and receipt attached, would let the result itself outlive its ten minutes. Sharing one across users would follow the grant model specified for memory in *Attention Cloud: Memory as a Rendering Problem*: a ref exposed at a ceiling of resolution, the head being the lowest rung.\n\n### Certificates Over Chains\n\nEach step in a ref chain carries its own receipt, and a plan's certificate now chains into the run that performed it. A plan certificate covering the whole ref chain, with the deterministic receipts as its leaves, would let a downstream reader verify a derived figure by re-running the chain.\n\n### Leases and the Frame as the Unit\n\nThe session lease, decided and not shipped, runs one compiled, validated, deterministic, side-effect-free plan many times under one accounting container: per frame one hash on the hot path, per segment one receipt with credits settled asynchronously, per lease one certificate over the hash chain, any frame verifiable by inclusion proof, under an escrowed budget cap. It sits behind a `session_lease` feature flag and refuses explicitly when off; it never falls back to per-call. The order is structural payload fixes (`records: false`, shipped), then the CBOR wire, deterministic CBOR becoming the receipt's canonical form, then the lease.\n\n### Selection as a Field\n\nThe toolkit returns shapes and handles; it does not yet decide, on the agent's behalf, which of many available results deserves the context window. That decision is the subject of *The Physics of Context*, with *Cartographic Navigation: Mapping Program Space* as the program-space counterpart; the envelope fields here (cost, evidence, degradation) are the inputs such a selector would need.\n\n---\n\n*This document describes the conceptual architecture of DataGrout as a substrate for agents. Operational details, including enforcement-chain internals, pricing tables, ref storage, transport framing, and the tool catalog's per-tool schemas, are part of the operational implementation and are not specified here.*\n",
  "last_updated": "2026-09-01T00:00:00Z"
}