An LLM does not become a digital brain simply by gaining a larger context window or a longer list of tools. A useful digital brain needs continuity beyond any single prompt. It must work with structured knowledge, act on the world, inspect the consequences, recover from failure, preserve useful procedures, respond to future events, and collaborate with people and other agents over long horizons.
That is the purpose of our harness. The model supplies reasoning; the harness turns it into durable, inspectable, resumable, and reusable work.
The architecture rests on four foundations: code as the primary interface for action, a structured record of observable execution, a persistent runtime, and a local-first conflict-free replicated data type (CRDT) layer. Together, they turn an LLM from a disposable task runner into a long-lived computational collaborator whose knowledge and capabilities can grow without forcing its prompt to grow at the same rate.
Most of this architecture is already running in the product; what follows describes the system rather than a speculative end state.
The core requirement: continuity without an ever-growing prompt
Most agent systems are designed around short, isolated tasks. A user opens a chat, loads some context, asks the agent to do one thing, and then starts again. When a session grows too long, the model loses precision or the system compresses its history. Users learn to divide work into disconnected tasks and accept the loss of continuity as normal.
A digital brain requires the opposite design. It should maintain an effectively continuous relationship with a person, team, or company. Decisions made months ago, earlier conversations, changes to data, and the consequences of previous actions should remain available. But an organization’s entire growing history cannot fit into every prompt.
The solution is to stop treating the context window as the memory system. The prompt should contain only what the model needs for its current reasoning step. Execution state, long-term knowledge, historical evidence, and reusable procedures live in a durable external environment and are retrieved selectively.
This also makes context programmable. A large objective can be divided into explicit subtasks, and the harness can compile the context for each one from the relevant objects, prior decisions, dependencies, execution traces, and completed work. The surrounding knowledge may grow rapidly while the model’s working context remains deliberate and bounded.
If someone asks when a topic was discussed, the same agent can find the original message, connect it to later decisions and events, and reconstruct the relevant history. It does not need to carry every conversation in active context or make the user search manually.
Code as the universal interface for action and data
The model interacts with the system through one primary tool: run code. We invoke it through the model’s native tool-calling format because models generate code reliably there, but the format does not represent a choice among dozens of separately declared tools. Tool calling is the envelope; the work is expressed through code.
Code is a more general interface for data than a fixed catalog of commands. Purpose-built tools cover scenarios anticipated in advance. Shell utilities compose well for command-line tasks, but text streams are a limited substrate for rich, structured transformations. Code can query, transform, and combine records, schemas, relationships, and ordinary files in one medium.
The historical weakness of code-first agents was not expressiveness but feedback and control. Ordinary program code does not automatically provide the validation and diagnostics accumulated by mature command-line tools. It can also produce a semantically wrong result without raising an exception.
Our runtime changes that tradeoff because we control the environment in which the code executes. It can instrument execution, expose structured feedback, and enforce capabilities at runtime. A program can be granted access to particular data spaces, files, URLs, methods, or classes of effects without receiving unrestricted shell or root access. This is a much finer policy boundary than allowing a general-purpose agent to run arbitrary Bash and then attempting to classify command strings as safe or unsafe.
The result is the expressiveness of code inside an observable and governed execution environment.
A structured, reproducible record of observable execution
Traditional debugging becomes detective work when the information needed to reconstruct a failure was never recorded. Developers add logs, but as a system gains layers, it becomes difficult to recover the exact inputs, environment state, and external effects of a particular run.
Our runtime records the inputs, outputs, and effects of each execution. A content hash identifies the exact program version. Because we control the runtime itself, we can also observe the state that ordinary application logs omit: runtime and dependency versions, environment values, time and randomness, filesystem and database reads, network requests and responses, and, when useful, the program’s in-memory state.
This is what makes deterministic reconstruction practical. The runtime retains the program together with the data and observations that shaped its behavior. A failed execution can be examined under the same conditions; after correcting the code, the agent can validate the new version against the recorded state instead of rebuilding the past from scattered logs.
This does not make the external world deterministic. If an API returns an empty string, the record may not explain why the remote service behaved that way. It does establish that this API returned that value to this exact program during this execution. Debugging becomes an examination of what was observed rather than speculation about what might have happened.
The record is structured data, not an undifferentiated log stream. The LLM can query and filter it, retrieve only the evidence relevant to a failure, and construct the context needed for the next action at relatively low token cost.
The same record exposes partial success and enables controlled continuation. Suppose a program must create one hundred tasks in Linear. The harness can divide the objective into subtasks and record every attempted and completed effect. If processing stops at task thirty-one, the agent can programmatically assemble a recovery context containing the completed effects, the failing input, the observed response, and the relevant code and state. It can preserve successful work, reconcile any uncertain result, fix the underlying problem, and resume without repeating the first thirty tasks.
Explicit effects also provide the enforcement point for security. The runtime can decide which spaces a program may change, which network destinations it may contact, which files it may read or modify, and which effects require approval. Observation, recovery, and governance operate over the same execution model.
A persistent runtime instead of disposable scripts
The next foundation is a persistent logical runtime. Its working environment remains available across model calls. The LLM can collect data, add code, execute it, inspect the result, modify a function, and continue from the same state.
This makes divide-and-conquer workflows practical. The agent can develop and debug helper functions on a small sample and then apply them across hundreds of documents. If one document exposes a problem halfway through, the agent can stop, adjust the program, and continue. It does not need to reload everything or independently solve the same problem for every document.
A conventional agent can save scripts and intermediate files, but a directory of artifacts is not a living runtime. It is hard to know which state will matter later, and recovery scripts quickly accumulate. Code, state, progress, and evidence drift apart, forcing the model to reconstruct their relationships inside its prompt.
In our runtime, those elements remain connected. The prompt carries the current reasoning problem; the runtime carries the computation’s live state and execution evidence. The harness can compile the right context for each step instead of repeatedly reconstructing the agent’s world.
Solved work becomes reusable capability
When the agent solves a problem by creating a program, that solution can become a durable capability instead of disappearing with the conversation. Programs are stored in the CRDT database and synchronized across devices, accounts, and agent instances.
A saved capability is more than a loose code snippet. It remains connected to its documentation, argument signatures, versions, traces, observed effects, and the executions in which it succeeded or failed. From inside the runtime, an agent can discover existing capabilities, understand how they behave, compose them into larger programs, adapt them, or create a new one when the library is insufficient.
This is the practical meaning of self-extension. The agent is not modifying its model weights. It is accumulating inspectable procedural memory. Because the code and its operational history remain available together, one solved problem can become a tested building block for later work. Capabilities compose, and the system compounds.
Programs can also be scheduled or triggered through the same environment. An agent can run a program tomorrow, respond to a new message, or react when an object changes. Proactive behavior follows from the runtime and data model rather than requiring a bespoke integration for every automation.
A local-first, structured memory substrate
A long-lived agent is also a distributed-state problem. Ephemeral runtimes must be stopped, serialized, and reconstructed elsewhere. Files must move out of short-lived machines, state must be restored correctly, and accidentally concurrent instances can race. Once several people or agents share knowledge, persistence, locks, and synchronization become core infrastructure.
Our system treats persistence and coordination as database problems from the beginning. Local and connected agents work in the same shared space. The platform retains history, synchronizes changes, exposes structured data through a database interface, and provides subscriptions to changes.
Changes are written to local disk first and synchronized asynchronously. Local work does not wait for a central transaction on every edit, and a central API and its rate limits are removed from the critical path. Synchronization still has capacity and coordination limits, but individual agents do not need to reconstruct the machinery themselves.
This database is the digital brain’s durable knowledge substrate: structured objects with explicit relationships, queryable history, and rules for how schemas evolve. The same substrate holds knowledge, programs, execution records, and the events that can trigger future action.
Collaboration without merge-conflict collapse
The CRDT layer lets people and agents work on that knowledge concurrently. Consider a simple race: Agent A reads an object and works for a minute; Agent B reads the same object and writes a concurrent change; Agent A then saves a result derived from the earlier state.
A central system can serialize the operations, accept last-write-wins, surface a version conflict, or ask a person or model to merge the results. These strategies are valid, but their coordination cost grows when many long-running agents produce conflicts faster than they can be reviewed.
A CRDT does not solve semantic disagreement, permissions, or every distributed-systems concern. It guarantees convergence for supported structural operations; it cannot decide whether a result based on stale input remains correct.
What it can do is preserve concurrent variants, their provenance, and the history that produced them instead of silently discarding one result. Structural operations converge under predefined rules, while meaningful ambiguity remains visible. A person or agent can then inspect who changed what, which input each result used, and which variant remains valid. Human judgment is reserved for semantic decisions rather than routine structural merging.
Collaboration rules can also be explicit. The type of an existing field, for example, cannot change silently. If a different type is needed, a new field must be created, making schema evolution visible. These rules are part of the shared substrate rather than reimplemented by every agent.
Because subscriptions operate on the same synchronized objects, reactive programs observe the state used by people and other agents. Memory and action live together: the digital brain does not merely remember changes in its world; it can respond to them.
Why this is a digital-brain harness
Each layer supplies a capability the model alone does not have:
- Code is its general language for action.
- The persistent runtime is its working state.
- The execution record is its evidence and audit trail.
- Saved programs are its procedural memory.
- Selective retrieval connects long-term knowledge to current reasoning.
- The CRDT database is its durable, structured, shared memory.
- Timers and subscriptions form its event system.
- Runtime capabilities govern what its programs may do.
The power lies in their interaction. Code makes action expressive. The runtime makes it observable and governable. Persistence makes work incremental. Structured retrieval bounds the prompt. Saved programs let capabilities compound. CRDT-backed data gives people and agents one evolving world without converting every concurrent change into an expensive arbitrary merge.
The result is not merely an agent with more tools. It is infrastructure for a system that can remember what matters, act on structured knowledge, inspect the consequences, recover from interruption, reuse what it has learned operationally, and collaborate across an open-ended history.
The unit of continuity is no longer the chat session but the environment itself. The agent does not begin every task as a disposable process with an empty world. Its state, evidence, procedures, and shared knowledge endure—and every successfully solved problem can leave the whole system more capable.