The Architecture That Took Us Out of the Loop

The Problem With AI-Assisted Development

AI coding tools have transformed how software gets built. But here's what most teams discover: the cost curve bends the wrong way exactly when the tool starts being useful.

An agent needs context to be any good — your codebase, your conventions, the decisions you made last month and the reasons behind them. The more context it has, the better it works. But most setups re-send that context with every request, so the better you make the agent, the more each request costs. That tradeoff is what keeps teams running one careful session at a time instead of ten.

Break that tradeoff and everything downstream changes.

Context as Infrastructure, Not Payload

The shift is to stop treating context as something you send and start treating it as something that lives there — written once, read hundreds of times. Anthropic will cache repeated content automatically, but only if the shape of what you send lets it. Three things make that work in practice:

• A stable prefix. A cache hit needs the front of the request to be byte-identical to last time. So the things that rarely change — standards, architecture, domain rules — go first and stay put; only the task at the end varies. Reorder that prefix and you've thrown the cache away without changing a word of meaning.
• Inheritance instead of repetition. Our rules are layered — org, then company, then project — and every agent picks up all three automatically from where it's working. One rule written once is inherited by every session in that tree, rather than pasted into fifty prompts that then drift apart.
• Big contexts, deliberately. Counter-intuitively, a large resident context is the cheap option. A million tokens read from cache costs a fraction of a tenth of that recomputed — so the agent gets the whole picture instead of a keyhole, and we pay less for it.

None of this is exotic. It's the discipline of deciding what's permanent, putting it where it can be reused, and not disturbing it — applied relentlessly for two and a half years.

Real Numbers, at Real Scale

Over the past twelve months we've processed over 51 billion tokens through Claude building real production software — the equivalent of tens of millions of pages of code and documentation. And we're accelerating: last month alone was 16.43 billion tokens, across 3,401 commits and 26 active projects — with dozens of AI agents building in parallel.

That's not a typo. Billions with a B. Code generation, refactoring, debugging, documentation, code review — at a scale that would be economically impossible without the context architecture above. Every figure on this page is pulled live from the GitHub and Anthropic APIs; we publish the working in a monthly report.

The Engine Behind Fabric

Here's the part that matters at scale: cache efficiency isn't just cheaper—it's what makes running many agents at once economically possible. When 94% of every context is served from cache, the marginal cost of one more concurrent session stays low. That's the economics that let us run a matrix of Claude Code agents in parallel—dozens building, testing, and shipping at the same time.

So we productized it. That matrix is now Fabric: Neo runs the agent matrix for dev teams; Jerry uses the same foundation to build and ship production software for businesses that don't have a dev team. Same context architecture, now a product anyone can use.

What That Efficiency Actually Buys

For most of the last two years the answer was “more throughput” — more agents, more commits, more shipped per engineer. True, and not the interesting part.

The interesting part is what happens to the correction loop. When a build, a test run, a review pass and a retry are all nearly free, an agent can afford to be wrong on the first attempt and fix itself before anyone looks. Expensive iteration forces a human checkpoint — you review because each retry costs real money. Drive that cost to almost nothing and the agent absorbs the retries itself, and the checkpoint stops earning its place.

That's not a hypothesis. Here is what it looked like in July 2026:

Autonomy Is a Rails Problem, Not a Model Problem

An agent that ships unattended is only as good as what catches it when it's wrong. The architecture above makes autonomy affordable; it doesn't make it safe. Most of our engineering last month went into the boring half of that sentence:

• A real preview before production. Every change lands on a live environment first. Nothing reaches production that nobody could have looked at.
• Build and tests as a gate, not a report. A red build is the agent's problem to solve, and it doesn't get to hand the work over until it's green.
• Automated review that loops back. Findings return to the agent and get fixed, rather than queuing for a person.
• An append-only transcript. Every prompt, command, response and tool call recorded per user and per project, secrets redacted. When someone asks what the AI did and when, that's a query, not an investigation.
• Escalation that's honest. When something genuinely needs a human, the agent says so plainly instead of failing quietly. A silent failure costs more than a loud one.

None of that is glamorous and all of it is load-bearing. The 97% is a measure of those rails holding, not of a model being clever.

What Compounds on Top

The same “write it once, reuse it everywhere” discipline that applies to context applies to everything else an agent needs. Two examples that carry real weight in production:

Integrations. Eleven vendor systems — origination, pricing, credit, title, HELOC, voice, messaging — sit behind one platform layer. The client keeps their own vendor relationships and hands over an API key once; the key is stored server-side and used on their behalf, so it never lands in a repository, an environment file, or a build log. The agent doesn't re-learn an API per project, and there is no credential in the workspace for it to mishandle.

Interface. The screens that are the same for every business — tables, dashboards, pipelines, forms — come from a shared component registry the agent installs from, then brands. Nobody's paying an agent to reinvent a data table. The build time goes into the part that's actually specific to the customer.

This is what Fabric is built on. Not developers who happen to use AI tools — an architecture where context, credentials and interface are all infrastructure, so the agent's whole budget goes to the problem in front of it.

Build the Same Way

The architecture took two and a half years to get right. Using it takes a conversation. Whether you want Jerry to build and ship your software for you, or Neo's matrix of agents for your own team, we'll show you live against your stack.