Continuity: how we built an agency that never starts from zero

The context that kept running out

The work that broke it for me was the big, complex client jobs. A major H2 report, say, with a mountain of data behind it. I would be deep in a single thread in Claude Chat, the analysis building nicely, and then the thread would fill up. It would slow, then stall, and the only way on was a fresh thread that knew none of what the last one had worked out. So I would rebuild the context by hand and carry on, until that thread filled up too.

It got worse the moment I moved. I would switch to another tool to get a second read on the same data, and the context did not come with me. I would try a different model for a different angle, and start explaining from scratch. Then we moved platform entirely, from Claude Chat to Cowork, and a whole layer of accumulated context simply did not follow. Every new thread, every tool, every move cost me the room before I could get back to the work.

That is the tax nobody talks about. The intelligence is extraordinary and completely amnesiac, and for a small team doing dense, multi-day client work, the rebuilding was not a nuisance, it was eating the job.

We decided to stop paying it. Not by picking a better tool, but by building the context outside the tool, in a place any thread, any model, any platform could read. That one decision pulled a thread that, seven months later, had turned into three layers and quietly rebuilt how the agency runs. A way to see and steer it all is going up on top now. Now we move between threads in a project, between Codex and Cowork, between models, and the context is still there. In April we published the blueprint for the first layer, the memory. This is what happened next: what forced each layer after it, what we got right, and what we are still fixing in the open.

The pattern, and what we call our build of it

Earlier this year Nate Jones named the shape of the answer, and named it well. He calls it the Open Stack: rent the intelligence, own the context underneath it. Three layers.

We did not invent that framing and we will not pretend we did. What we did was take it more seriously, earlier, than almost anyone we have seen, and build all three into a working agency rather than a personal setup.

We call our build Continuity, because that is what it buys: nothing starts from zero.

You could read all of this as one agency implementing someone else's idea, and that would be fair. The idea is the cheap part. What almost none of them have is seven months of a real business leaning on the thing, finding where it breaks, and fixing it in the open. The moat was never the diagram. It is the build history, and you cannot copy ours without living it.

The important word is underneath. They sit below the tools, and every tool reaches the same three. Our memory, our methods, and our task state are read and written by Claude Code, by Codex, by Cowork, and by Hermes, an agent that mostly runs on lower-cost models, interchangeably. When a model gets more expensive, or a better one ships, switching is a swap, not a rebuild. The binding that makes this work is a deliberate split: the skills hold the structure, the memory holds the live values, and a fast recall layer sits on top. Runtime-independence is the whole point. It is also the part that took longest to earn.

Layer two: capability, so the method travels

Memory fixes the cold start, but memory is inert. It remembers that we ran an audit; it doesn't know how we run one. The know-how, the actual method, was still trapped in the worst possible place: one person's chat history, as skills that only worked inside one tool.

That is the second wall. Your best methods are your institutional capital, and if they live as one person's private setup they are one laptop away from gone, and useless to a teammate or to an agent in a different tool. So the second layer makes capability portable.

Here again we built on Nate's work rather than around it. His Open Skills launch is the clearest version of the argument, that your way of working should be owned and movable, not rented back by whichever app wins the quarter. The method we settled on pairs two of his prompts with our own Open Brain corpus, so a new skill is grounded in what we actually know, not generic best practice.

The cross-runtime piece is what makes it real: one source now builds the versions Claude Code, Codex, Cowork, and Hermes each need, so a method is genuinely shared, not copied and left to rot in four places, and since September every release ships each skill as its own package.

The first skill we built to this standard structured content for answer engines. It mattered because it was the first time we captured methodology rather than plumbing: a repeatable way we do skilled work, turned into something an agent can run. To keep that safe as the library grew, we wrote a small standard. Every skill is sorted into a lane and a tier.

A worked example: our proposal skill is classed guarded, because it is client-facing, connector-dependent and commercial, so it carries stricter rules than a skill that just tidies a document.

Capability without a safety gate is just a faster way to make a mistake in more places. But a portable method still needs something to run it, in order, across agents, without a human standing in the middle relaying every step. That was the third wall.

What it took, and what it returns

What it took is less exciting than it sounds, and that is the point. Seven months, three people, and a rule we held to: build in layers, and only build the next one when the last hits a wall. The scarce ingredient was not code, it was the discipline to keep the memory honest and to give the system room to act on its own only once each step had proved itself.

What it returns is better shown than asserted. Recently we produced a report for a 12-year B2B media client. It stood on the record we had stopped letting evaporate: for that one client the memory held on the order of 480 recorded decisions and context notes, roughly 300 technical findings, and around 300 meeting records when we wrote it in the summer. By October the technical findings alone had grown to about 450.

Most of that was captured over the last year and a half, with only a thin trail reaching back across the full relationship, but it was enough that nobody had to hold the history in their head, and nothing quietly contradicted a position we had taken two years earlier. The version of us without this writes a thinner report from whoever remembers what. That is the return: not magic, compounding.

We will be careful with numbers, because our working principle is that these are indicative, not promises. We do not yet have a clean "hours saved" or "cost per run" figure, and we are not going to invent one; capturing that properly is still ahead of us. The usage readings our control layer now takes are a first step towards it, not the answer. What we can say, roughly and from our own experience, is this: a big client deliverable, a major H2 report or a big client presentation, that took a couple of weeks before AI and still took three to four days with the intelligence trapped in a single tool, now takes us somewhere between half a day and a day and a half.

As far as we know, we are among the first UK B2B specialist agencies to run the whole stack, memory, method, and execution, in production rather than as a demo. We can't prove a first, and we are not going to try. If you are doing the same, or something like it, we would genuinely like to hear from you, because this gets better the more of us build it in the open.

Common questions