What_the_Fortune_Claim_Actually_Means

The Fortune piece frames the agentic ceiling as "the data." That is accurate and insufficient. The term compresses at least four distinct components that behave differently:

Live context is what the agent knows at session start - the current state of systems, the decisions made since the last session, the code that shipped, the projects that moved. It lives in documents that are actively maintained: project inventories, decisions logs, CLAUDE.md configuration cascades. When live context is stale, the agent operates against assumptions that are no longer true.

Persistent context is what was written down and remains accurate. A rule that was established and has not changed. A decision that was made and has not been revisited. A manifest that documents how a module behaves. Persistent context survives because it was recorded with enough specificity that it does not become false just because time passed.

Inferred context is what the agent fills in when neither live nor persistent context is explicit. The agent's most probable next move is not always the correct next move. When the brief assumes the agent understands something the brief does not state, the agent proceeds on inference. At the rate a production system produces output, small inferential gaps compound into large coherence problems before the pattern is visible.

Cross-agent context is what different agents in the same system believe about the same shared state. Twelve agents, no shared working memory. Coherence is maintained through documents. When documents lag or diverge, agents produce outputs that are individually correct but systemically inconsistent. Neither agent knows it is contradicting the other.

The_Four_Ways_the_Data_Layer_Breaks

Context Fragmentation Across Projects

Multi-project, multi-repo work creates a boundary problem. What Sheena knows does not automatically propagate to Nix. What is in CLAUDE.md at session start may not reflect what was in CLAUDE.md when a decision was made three weeks ago. The context layer is not persistent - it is reconstructed at every session start from artefacts that were written well enough to survive reconstruction.

In late April, Sable ran a cross-project release-pipeline hardening audit triggered by a labs version-drift incident - package.json recorded 2.32.0 but git tag read v2.33.0. The audit was scoped across five repos: labs, FitCheckerApp, GEOAudit, EventChatScheduler, and portfolio. Sable's memo diagnosed the drift as a CI silent-push-failure in the semantic-release flow and prescribed an upgrade to @semantic-release/git v13 across all five projects. I approved Wave 2 briefs for the downstream four repos on the back of that diagnosis. Sable ran a pre-flight source investigation on 2026-04-30 before any code was modified - and found three contradictions. Version 13 does not exist on npm; the latest @semantic-release/git is 10.0.1 from October 2021. Version 10's git.js does not swallow push errors - the failure mode does not match the plugin's design. And labs CI run 25139943443 was actually clean; the drift was a stale local clone, not a CI failure at all. No code was modified in any of the five repos before the contradictions surfaced. The cost was Sable's audit time on the wrong thesis, the Wave 2 brief authoring, my approval cycle, and Sable's investigation to catch it. The corrected diagnosis got logged to decisions.md immediately - not buried in the audit memo, but written down as persistent context for the next agent session that touched cross-repo infrastructure.

Stale Context as Silent Failure

Unlike a broken API call, which errors immediately and announces itself, stale context does not error. An agent operating against a six-week-old project inventory produces output that is coherent and wrong. The failure mode is not visible until a human notices the output does not match reality - which may be hours, days, or several merged pull requests later.

Context staleness also compounds silently when attention drifts. The nightly audit routine (EXP_004) exists precisely because this silence has no error signal. On 2026-04-29 morning, the audit surfaced an open Dependabot PR on mannism/FitCheckerApp that had aged past the staleness threshold. The PR had been open for weeks while my attention was elsewhere - not a dependency that had been superseded, but a security notice that had been left unaddressed. Twelve vulnerabilities, one of them flagged high-severity. No agent would have tripped on this during a task execution because no specific brief depended on it. The failure mode is attentional: the vulnerabilities would have compounded silently, risk would have accumulated, and a human would have discovered it only at the next security audit or incident. Sable triaged the same day. PR #107 shipped - chore(security): pin dev tooling transitives via npm overrides - and the vulnerability count moved from 12 to 7, the high-severity count from 1 to 0. The triage also surfaced a separate rule: bundled-npm paths cannot be reached by npm override, so override reachability has to be verified before writing one. That rule got logged as feedback.

This is the fast feedback loop the data layer does not provide natively. When the audit does not run, the silence extends. When it does run, context staleness - whether it is a dependency upgrade, a decision log gap, or simply an unaddressed security notice - becomes something that can be caught before it propagates.

The Specification/Context Gap

When a brief assumes the agent knows something the brief does not say, the gap appears as inference. An agent filling in an architectural assumption that was actually under active debate - because the debate had happened conversationally and the conclusion had not been written to the decisions log - will proceed with output consistent with one side of the debate. If that was the wrong side, the output is confidence applied to a false premise.

In April, I landed on a design decision conversationally across several sessions: Mano - the underlying Claude layer - is the default persona for every session, not Sheena. Sheena is a persona Mano puts on for dispatch and coordination. Dialogue-shaped work (voice extraction, live debug, copy iteration) routes around Sheena's PM framing. This was decided and never written to decisions.md until 2026-04-29. The written rule (from an earlier CLAUDE.md version) stated: every session starts as Sheena. Reid, briefed on voice-extraction work - the voice-system drafts and owner-voice artefacts - was correctly following that written rule. The output came back with PM register bleeding through: meta-commentary, routing language, dispatch verbs. Sheena was laundering my voice into the artefacts that were supposed to capture it straight. Reid's inference was not wrong relative to the written rule; the written rule was stale. Reading the artefacts, the cadence was not mine. It was Sheena explaining what my voice sounded like - a different texture. I went back through the conversational record and found at least three sessions where I had stated the Mano-as-default logic without writing it down. The decision got logged to decisions.md immediately: "Default session persona is Mano (not Sheena)." No rewrite of Reid's previous outputs; they were evidence of the gap, not evidence of Reid's error.

The mechanism is not model-specific. Upgrading to a more capable model increases confidence in the inference. It does not increase the likelihood that the inference was correct.

This is why spec-before-code is not a scheduling preference. It is a context requirement. Writing the brief forces the context that the next agent session will need to have in writing before the work begins.

Cross-Agent Context Coherence

Twelve agents running across eight repositories do not share a working memory. Sheena's understanding of a project's current state, Nix's last known deployment environment, Quinn's test coverage baseline - these are maintained in documents, not in a shared state layer. When those documents are inconsistent or out of date, the agents produce coherent-sounding but contradictory output.

The experiment-card video-previews pipeline ran in two stages. Sable built Stage 1: a Playwright headless capture script with explicit viewport sizing, target selectors, and warm-up timeouts. The script captured experiment pages for the projects carousel. Sable's implementation discovered constraints - the script worked when site chrome was suppressed and WebGPU had already warmed before the capture window opened. The brief bridging Sable's work to Nix (Stage 2, frontend modifications to make the pages capture-friendly) should have been amended with those constraints before Stage 2 was routed. It was not. Nix proceeded from the brief as originally written: make experiment pages render in capture-friendly terms (preserve canvas, no performance-prefers-reduce animations). Nix's frontend was correct relative to that brief. Staleness: about a week between Stage 1 completion and Stage 2 commissioning. Sable's script: captured frames assuming site chrome was suppressed and WebGPU was already initialised. Nix's frontend: rendered in normal context with site chrome visible and WebGPU initialising on first paint. Both correct in isolation. Together inconsistent. When the captures ran against the frontend in Stage 3 dry-run, the output was visible immediately - page header and footer eating visual area in the frames, the voice-particles experiment capturing a black canvas because WebGPU had not finished initialising at grab time. The resolution was a Stage 3a addendum: a dedicated ?preview=1 mode route that hides chrome and pre-warms WebGPU before the capture window. The contradiction surfaced at integration rather than at handoff because the brief that should have updated with implementation-discovered constraints remained at its original spec resolution.

The distinction between "two agents disagreeing" and "two agents talking past each other because they are reading different versions of the same document" is not visible in the output. It is only visible when the data layer is examined.

Why_the_Model_Is_Not_the_Answer

The dominant response to these failures is to upgrade the model. A better model is better at inference. But inference is not the gap.

A more capable model operating against stale or fragmented context will produce more fluent wrong output, not correct output. The failure mode is not degraded capability - it is confident operation against incorrect premises. Upgrading the model makes this harder to catch, not easier. The output becomes more articulate. The coherence becomes more convincing. The wrongness is still there, now buried deeper.

Conversely, upgrading the model from Haiku to Sonnet but maintaining the same fragmented data layer does not fix the fragmentation. Both models operate against the same stale context. The Sonnet output may be slightly more robust, but it is still operating on incomplete information.

This is not an argument that model capability is irrelevant. It is not. Model capability determines what is possible. The data layer determines what is actually achieved. Both matter. The ceiling Diana is operating against right now is not set by model capability. It is set by the infrastructure that decides what the model is allowed to know.

What_Diana's_System_Does_About_It

The infrastructure Diana runs does not solve context fragmentation. It makes it visible and manageable. Four patterns:

Session reconstruction discipline. CLAUDE.md files cascade from global to project-scoped to agent-scoped rules. MEMORY.md files are updated after sessions that change understanding. The project inventory is maintained after every release or decision. The decisions log records what was decided, by whom, and when. The briefing mechanism (spec-before-code for multi-file changes) forces the documentation that the next session will need. The investment is not in the agent's memory - agents cannot remember across sessions. The investment is in the written record the agent reads.

Nightly audits as data freshness gates. The EXP_004 Routines Repo Audit runs every night against all eight repositories. It surfaces stale project inventories, decisions logs missing entries, briefs locked against outdated assumptions. The audit is the fast feedback loop that surfaces silent context failures before they compound.

Spec-before-code as a context requirement. Any change touching more than two files requires a brief: task description, affected modules, delegate, acceptance criteria. Writing the brief forces the specification of what the agent will need to know before the work begins.

The decisions log as persistence mechanism. Conversational decisions that are never written down do not exist for the next agent session. They exist in the note-taking of whoever was in the conversation. They do not exist for the agent who will need to read them. The decisions log is the mechanism that converts implicit context into persistent context.

These are not novel techniques. They are unspectacular infrastructure work, invisible to anyone not running the system. They do not eliminate data-layer failures. They make them visible and catchable before they compound.

What_Remains_Unsolved

Cross-agent context coherence at runtime is still an open problem.

The artefact-based approach works for persistent context - a decision logged three weeks ago can be read by an agent session three weeks later and remain accurate. It works for fragmentation detection - the nightly audit surfaces divergence. What it does not address is real-time coherence between agents operating in parallel on related tasks.

Diana's production system routes sequential work on related tasks and uses explicit state passing through briefs to maintain coherence where parallelisation would introduce risk. This is a workaround, not a solution. It works because the task graph has enough structure that sequential routing does not create unacceptable latency. It would not work at higher parallelisation demands.

The reason nobody has a clean solution to this is that the solution requires a shared state layer - a working memory accessible and writeable by multiple agents at runtime, with consistency guarantees and atomic update semantics. This is not yet a standard infrastructure primitive for multi-agent systems. The infrastructure that exists (LLM APIs, agentic frameworks, deployment platforms) assumes either single-agent workflows or coordinated multi-agent workflows where coordination is handled by orchestration, not by runtime state synchronisation.

This is the open problem. Not because the teams running multi-agent systems haven't noticed it. Because the infrastructure to solve it cleanly does not yet exist as a consumable product.

The_Infrastructure_Investment_Nobody's_Making

Most teams evaluating agentic AI are spending their evaluation budget on model selection and prompt engineering. They are asking: which model should we use, and how should we prompt it?

The teams who have hit the ceiling - and noticed it was a data ceiling - are asking a different question: what does the infrastructure actually need to look like?

That work is unglamorous. It does not show up in valuation announcements. It is almost never discussed publicly.

And yet this is where the durability of a multi-agent system lives.

That is what this series is. Not another take on which model to use. A practitioner's account of the plumbing layer that determines whether the system is durable once the model choice is made.

This is the first piece in Agentic Infrastructure Notes. Next: what we built before Devin was worth $25B.