Inspiration

I built Enterprise Brain because I kept losing working context while building OpenShut with coding agents. An agent would know the current files but forget an earlier constraint, a failed experiment, or why I had rejected an approach. When I changed sessions or switched from Claude Code to Codex, I had to explain that history again.

That was frustrating because the information had already been written down in the conversation. The problem was getting the right part of that history back into the next agent's context when it needed it.

The keynote described this as the last mile of AI memory: storing information is possible, but deciding what information to use and when to use it is still difficult. I focused on that problem for coding work.

Enterprise Brain keeps the supported original work, searches it for the current task, and separates what happened from what someone officially decided. The agent continues writing code and reasoning. The brain supplies the history and evidence it would otherwise be missing.

What it does

Enterprise Brain gives Claude Code and Codex access to the same project memory through MCP, the interface both clients use to call external tools.

The main workflow is simple:

I work on a task in Claude Code.
The brain captures the supported conversation and tool results while Claude is still open.
I open Codex and ask it to continue the same task.
Codex finds the task and requests its history, current decisions, and relevant evidence.
It can inspect the earlier failure before choosing its next approach.

The demo uses a checkout bug. A fake payment provider records a charge, then returns a timeout. Retrying the payment blindly records another charge. Claude's unchanged safety test produces Expected 1 charge, observed 2 charges.

That actual tool output is captured and retrieved by Codex. The result includes the messages around the failure and a citation that opens the original text. Nobody manually tags the conversation as a failed attempt.

The UI lets a person view projects, continue a task, open a source, check sync progress, record decisions, and review proposed replacements between decisions.

How we built it

Layer 1: a small map of the project's memory

The first layer is a generated project index. It lists the project, owners, active tasks, current decisions, locations of deeper material, and tools available to retrieve it. It is limited to 200 lines or approximately 1,000 tokens.

This map helps an agent know what exists without loading every document and conversation. For checkout work, it can point to the Checkout retries task, the current retry decision, and the tools for finding earlier tests.

Both clients receive the same short operating instructions. AGENTS.md is the shared instructions file, CLAUDE.md imports it, and the same skill is installed for Claude and Codex. These instructions tell the agent when and how to call the brain. The generated index is available through the service; automatic injection of that index at startup is future work.

The important separation is between knowing where information lives and loading the information itself. The agent starts with a small entry point, retrieves the relevant task, and opens a larger source only when it needs the details.

Layer 2: project documents and explicit records

The second layer holds project files, notes, link references, Git records, and approved decisions outside any one agent's conversation.

SQLite stores the captured text after credential redaction, source versions, task records, and decision history. HydraDB stores searchable copies. Link imports retain their references and report unavailable content when the page has not been fetched.

A decision has a stored identity, scope, author, supporting evidence, and replacement history. The current decision is read directly from SQLite. It is not reconstructed by asking a model to summarize whichever old passages were returned by search.

Changing a source creates a new revision. The older revision remains available for inspection. This matters when a document changes, evidence is corrected, or someone needs to understand what an earlier session actually saw.

Layer 3: the actual conversations and tool results

The third layer searches supported native session history. Claude Code and Codex write JSONL files containing messages and tool activity. I built separate adapters for their formats.

The adapters preserve human messages, assistant responses, tool calls, tool outputs, errors, test results, and supported session metadata. They keep the order and identity of the records.

Speaker attribution requires more than reading the message role. A Claude user-role record can contain a tool result or a generated compaction summary. The adapter checks content blocks and explicit native flags so these are not automatically treated as words written by a person. The person who owns a session is not treated as the author of every assistant response inside it.

Readable thinking exported by a client is labeled as assistant content and flagged against automatic injection. Encrypted reasoning is not decoded. Unsupported complete records are retained locally with a visible normalization gap rather than assigned an invented speaker.

This layer preserves the parts that a repository usually leaves out: what was tried, the command that ran, its output, and the discussion explaining why an approach was abandoned.

Layer 4: capture, delivery, and maintenance

The fourth layer is the background work that keeps the memory available.

A local daemon watches the native files in registered projects. It reads complete lines and waits when the final line is unfinished. Credentials are redacted before an event is saved to the local queue or uploaded.

The queue uses SQLite WAL. Saving an event and advancing its file checkpoint happen in one transaction. Checkpoints track the file and byte offset. File rotation or truncation starts a new generation, while stable native event identities prevent delivery retries from becoming duplicate memories.

Uploads are scheduled every five seconds. A sixty-second filesystem sweep backs up the watcher. Failed deliveries retry with increasing delays. Session and compaction hooks request a local checkpoint without waiting for a cloud request.

The service stores a record before acknowledging receipt and then sends it to HydraDB for indexing. The UI distinguishes captured, received, and searchable. These are different steps. A record safely stored on the laptop may not yet be available to another agent's search.

The people graph connects these four layers. It links human work to sessions, projects, tasks, and records. It does not replace background maintenance as the fourth layer.

How retrieval works

When an agent receives a continuation request, the shared skill tells it to find the existing task before creating another. Tasks have stable IDs. Names and branch hints help resolve them, and ambiguous matches return a choice.

The service reads the task's recorded goal and current decisions, then uses HydraDB to find relevant historical evidence. When there is too little task-specific evidence, it searches the project and labels material from other or unassigned tasks.

The returned resume pack is limited to 4,000 tokens. It includes relevant attempts, surrounding messages, recent activity, freshness, and a list of omitted material. Every passage identifies its source, revision, and character range. The expand tool opens the exact source when the excerpt is insufficient.

Failed attempts are selected from tool outcomes such as an error flag, a nonzero exit status, or failing test output. Up to three messages before and after the result provide context. A tool error shows that an operation failed; the conversation explains what the agent concluded from it.

This is how stored memory enters the work at the right moment. The current task and question guide retrieval, while the original evidence remains available for other questions later.

Why the graph and decision records matter

HydraDB provides hybrid search and graph indexing. I supply graph relationships from known records: a session belongs to a project, work is associated with a task, a person records a decision, a decision replaces another, and a record cites supporting evidence.

The graph therefore connects identifiable records instead of guessing who approved something from the wording of a conversation.

Official decisions use a separate human action. An agent calling decide creates a proposal. A person records or replaces a decision through the UI.

If I record X and later record Y without linking them, Run sleep lists the unlinked decisions in the same scope for review. It does not choose which policy is better. I confirm the replacement, and one database transaction makes Y current, marks X superseded, and preserves both records and their evidence.

The new status is available immediately from SQLite. Search indexing happens separately. A search result describing the old policy does not determine which decision is official.

No approved handoff is invented. When one is missing, the pack says: No approved handoff. Agreed remaining work has not been recorded. The receiving agent can propose a plan, but it cannot claim that the plan was previously agreed.

Challenges we ran into

Native logs contain conversation, generated messages, and bookkeeping. Counting bookkeeping as conversation created false freshness gaps. Treating every user-role record as human also produced incorrect attribution. I separated these cases using the supported native formats and kept unknown formats visible.

The brain's own tool responses appeared inside later conversations. Without special handling, search could repeatedly return the brain quoting its earlier output. I flag those calls and results as echoes and exclude them from ordinary evidence retrieval while retaining them for inspection.

A redaction bug also replaced ordinary numbers in the checkout failure. Because the native logs were untouched, I could correct the redactor and restore the evidence as a new revision rather than guess the missing text.

HydraDB integration required checking individual ingestion results, metadata restrictions, and indexing status. An HTTP success response alone did not establish that every item had become searchable.

Accomplishments that we're proud of

I proved the real memory bridge in both directions between installed Claude Code and Codex clients. A real Codex session retrieved a captured Claude failure while Claude remained open.

The failure was found without a manual tag, and the citation opened the actual tool output. The full suite reached 480 passing tests, alongside separate native-client and live-service checks.

The prototype also supports shared task discovery, exact source expansion, human-approved decisions, atomic replacement history, and on-demand review. It adds memory to existing coding agents rather than requiring someone to use a new agent runtime.

What we learned

Keeping information and choosing what to load are separate problems. If a summary removes an important detail, later retrieval cannot recover that detail from the summary alone. Preserving supported source material allows a new question to bring back evidence that was previously overlooked.

Similarity also cannot establish whether a policy is approved or current. Those facts need explicit records. Likewise, an assistant saying a fix works is different from a tool showing a passing test.

Small indexes, focused resume packs, and exact expansion make a larger archive usable within a limited context window. Clear speakers, source versions, decision history, and visible sync gaps let a person check the result instead of relying on the answer sounding convincing.

The value is practical: fewer repeated explanations, fewer repeated failed experiments, and clearer continuity when work moves between agents.

What's next for Enterprise Brain

Tonight's local prototype includes capture, retrieval, tasks, human decision approval, transactional replacement, and on-demand sleep.

The next features are human-reviewed handoffs, automatic context injection, a bounded optional classifier, nightly scheduling, additional company connectors, and team access controls. These are future work.

The planned handoff lets an agent draft the goal, completed work, failed approaches, remaining work, blockers, and evidence. A person edits and confirms that record while the original session stays searchable.

My goal is to let people choose the agent they want for the next piece of work without losing the project's history or handing control of official decisions to the model.