Claude, in depth

We use several models and point each at the job it does best. Claude is the one our own systems are built on, which means we have a longer and less flattering record with it than with anything else in the toolkit — including the parts that did not work. That record is what this write-up is for.

The shape of it

Not one product, and not one model

The most common misconception we meet in the room is that Claude is a chat box — one thing, with one price, that you either use or you don't. It is closer to a family of models sold through a range of very different front doors. The model decides how much capability you are paying for; the front door decides what kind of work is even possible.

Getting either choice wrong is expensive in the ordinary way — you either overspend on a task that did not need the depth, or you put a serious piece of work through an interface that cannot reach your files. Most of the value we add for a client on this specific tool is in making those two choices correctly, and then not having to think about them again.

The development track

From chat assistant to agent platform

If you have only seen Claude as a chat window, you are looking at where it started rather than where it is. The through-line across the last few years is capability paired with control, and it arrived in three moves.

Move one — conversation

The model reads and writes well. Useful, but sealed off: it knows nothing about your business beyond what you paste into the box, and it forgets when you close the tab. This is the stage most organisations are still at, and it is why so many AI pilots stall at "impressive demo, no operational change".

Move two — tools and context

The model gains the ability to reach things: read a file, search the web, call another system, query a database. This is the move that makes AI usable as business infrastructure rather than a smarter search box, because the answer can now be grounded in your reality instead of the model's memory of the internet.

Move three — agency

The model plans, executes multiple steps, checks its own work, and carries state across a long task. It stops being something you prompt and becomes something you delegate to. This is also where the governance question becomes real, and where most of the difficulty in our work now sits.

Choosing between them

Which door to walk through

This is the table we end up drawing on a whiteboard in most first meetings.

The connector layer

Why any of this reaches your business at all

The piece that does the actual connecting is an open standard called the Model Context Protocol. Instead of every AI tool building a bespoke integration with every system, a tool exposes itself once and any compatible assistant can use it.

This matters commercially more than it sounds. It means the connection you build to your document store or your forms or your analytics is not a bet on one vendor's roadmap — and it is the main reason our own toolkit can be assembled from many vendors rather than bought from one.

From our own use

What we actually built with it

We did not adopt Claude by evaluating it. We adopted it by building our own operating system on it and then finding out, repeatedly and expensively, where it breaks. What follows is drawn from our own written record — including the parts that did not work.

The system runs on it, in the open

Our internal knowledge base is not a folder of documents someone maintains. It is a working system that Claude reads, extends and checks, held in version control so every change is attributable and reversible. Its operating instructions load automatically at the start of a session — the difference between a tool that has to be re-briefed every morning and one that resumes where it left off.

The heaviest single day we have run put eleven parallel work-streams in flight at once, each in its own isolated copy of the system, coordinated through a shared registry that records who is working on what. That registry exists because the alternative — two streams silently editing the same file — is the failure we hit first.

The thing that actually made it reliable was tests, not prompts

This is the finding we did not expect and the one we now lead with. The biggest improvement in output quality came from writing roughly thirty small automated checks that run against the system's own state: does this rule exist where it should, does this link resolve, has anything sensitive leaked onto a public surface. When a check fails, it fails loudly and the work stops.

Prompting is what everyone tries first, and it has a ceiling. Verification is what raised the floor. It is also the part clients resist most, because it looks like overhead rather than intelligence — right up until the first time a check catches something that would otherwise have shipped.

Written instructions are context, not enforcement

A hard lesson, and one we now tell every client: an instruction file is advice the model reads, not a control that binds it. If a rule genuinely must hold, it has to be enforced by something mechanical — a permission, a hook, a check that can fail — rather than by wording. We also learned not to pile everything into one enormous instruction file; the longer it gets, the less reliably any single line survives.

The related discovery was that capability can vanish silently. A set of our packaged procedures stopped being available to sessions, and the cause turned out to be three separate issues stacked on top of each other — an isolated working copy that could not see the parent configuration, two internal indexes where refreshing one did not refresh the other, and a budget for how many procedures get listed that was being calculated against a much smaller assumed capacity than the model actually had, so the newest additions were the first to be dropped. Nothing errored. It just quietly did less.

Automation that stops without telling you

We had a scheduled, unattended job running. It stopped dispatching for days, and the reason was mundane: the session it depended on was no longer signed in, so the job failed instantly every time it fired. Nothing raised a hand.

The uncomfortable part, written down at the time, is that the automation only stayed stopped by accident — an incidental authentication failure, not a deliberate decision. Around the same time we discovered that a safety switch we had built to halt autonomous work did not reach the mechanism that was actually running: there were two different ways the same work could be triggered, and we had put the brake on only one of them.

Any unattended AI process needs a heartbeat that proves it ran, and a stop control verified against the path that is really firing rather than the one on the architecture diagram.

Connected is not the same as used

We keep a large number of external systems wired into the AI layer, and at one point sat down and tested every one of them rather than trusting the list. Seventeen connected cleanly. Five had never been authenticated at all. One reported a failure on a full sweep and connected fine on an immediate retry, which taught us to distinguish a genuinely broken integration from a flaky one.

More usefully: several connections that worked perfectly had never been used for anything. An integration list is a statement of capability, not of value, and we are careful not to let a client confuse the two.

An honest note on "agents"

On a project that produced automated quotations from a site drawing, the presentation described seven autonomous parallel agents. When we wrote up what the system actually did, the count was three model calls and a set of ordinary deterministic steps. Michael's own note in the record is the clearest statement of it:

The system worked. The description was inflated. We corrected the record rather than the slide, and it is now the example we use when a client asks how many agents they need — because the honest answer is usually "fewer than the diagram, and the diagram is doing marketing".

This website is a worked example

The site you are reading is built this way: hand-written pages, edited by Claude in a real directory, versioned, checked automatically, and deployed only after a person approves the release. Publishing is a deliberate human gate rather than something the system can do by itself — a decision we made early and have not regretted.

Where it stops

What we would not use it for

A write-up that only lists strengths is marketing. These are the boundaries we hold, and we hold them on client work too.

• It does not own an outcome. A named person is accountable for every output that leaves our hands. The tool can do the work; it cannot hold the responsibility, and no amount of capability changes that.
• It can be confidently wrong. Fluency is not accuracy. Anything that matters gets checked against a source, which is precisely why we invested in automated verification rather than trusting the output.
• Sending, publishing, paying, deleting. Irreversible and outward-facing actions stay behind a human gate in our systems. Drafting is delegated; sending is not.
• It does not fix an unclear business. If nobody agrees what the numbers mean or who decides, AI industrialises the confusion. That work is advisory work and it comes first — which is the least popular thing we say in a first meeting, and the most consistently true.

None of that is a reason not to use it. It is the reason the tooling question and the operating question have to be answered together, which is the whole basis of how we work.