Reading, UK
Most people demo with AI. I ship with it.
I build agent systems that do real work. Claude Code for the orchestration, MCP to reach the tools that matter, memory that survives the session, and auth that holds up when the software touches someone else's data.
This site is where I write down how it is actually done. Every guide comes out of something running in production, not a weekend prototype. Nothing here is for sale.
anatomy of one agent request
pick a stageStage 01
Route
Work lands somewhere before anything happens to it. The system decides which agent owns this, which skill applies, which repository it touches.
the mistake
Skipping classification entirely. An agent that starts work without deciding what kind of work it is will confidently build the wrong thing well.
task → "the checkout is failing" classify→ bug, not feature ↳ route debugging skill, payments repo
Stage 02
Role
The agent that picks it up has a seat with a boundary. A defined scope, a defined tool list, and no access to things outside it.
the mistake
One agent with every tool. The failure mode is not that it cannot do the job, it is that it picks the wrong tool from too many similar ones.
agent → support tools → 6 of 31 registered ⚠ refund tool not in this role's list
Stage 03
Skill
A procedure written down once, with the judgement included. Which environment to check first, what a failing health check means, where the rollback actually lives.
the mistake
Writing documentation instead of judgement. If the skill contains nothing you could not find in public docs, it is costing context and adding nothing.
load → debug-payments.md ↳ check staging first (shared db) ↳ health fail <60s = wait, >5m = roll back
Stage 04
Memory
What persists between sessions. Durable facts, an append-only log of what happened, and disposable working state - split by lifespan, not by topic.
the mistake
Appending corrections instead of overwriting them. The next reader gets the old fact and the new one, and has to guess which is true.
read → memory/index (1 line per fact) open → pricing.md # changed 09/07 ↳ 3 files loaded, not 140
Stage 05
Tool
The agent reaches a real system over MCP. Not a chatbot answering about your software - software acting on it, with the server holding the credential.
the mistake
Mapping one tool per API endpoint. The model then needs five calls to answer one question, and each hop is a chance to pick wrong.
call → find_customer_billing_state auth → resolved server-side, not passed ↳ returns customer + plan + arrears
Stage 06
Gate
Anything public, anything involving money, anything you cannot undo stops here and waits for a person. Enforced by the system, not by an instruction.
the mistake
Putting the rule in a prompt. An instruction is a preference - it holds until the context gets long or somebody phrases a request as prior authorisation.
prepare → refund £40.00, ref #8812 token → expires in 15m, bound to payload ⚠ execute blocked — awaiting approval ▌
The guides
All 10 guides →10 maintained explainers, 48 minutes end to end, in three tracks. Start anywhere, but the order is deliberate.
01 / Build
Tool surfaces, memory, routing, skills.
02 / Ship
Identity, approval gates, the security review.
03 / Operate
Team adoption, and why the output was wrong.
Latest writing
All essays →02/08/2026
How Corey is built, and why it is mostly markdown
An agent OS with no orchestration framework, no vector database and no bespoke runtime. Routing, roles, skills, memory and a gate - almost all of it plain files in git. Here is the architecture and the reasoning behind each choice.
02/08/2026
A year of building with AI: what actually changed
Twelve months ago I was pasting code into a chat window. Now a system I built runs the recurring work of four products and opens pull requests while I sleep. The interesting part is not the volume - it is the four times I was wrong about what the bottleneck was.
26/07/2026
The file that exists only for machines, that no machine could read
A file whose entire purpose is being parsed by language models, formatted so that a compliant parser found zero links in it. Every real win that day came from measuring something I had assumed was fine.
25/07/2026
Seven review rounds on a payments path, and not one broken feature
Every finding was code being wrong about the world rather than wrong about itself. A three-seat purchase issuing one ticket is not a bug a test suite has any way to notice, because the code does exactly what it says.
Built with it
Everything on this site comes out of one system. I built Corey, then used Corey to build the rest. That is the whole argument: if the architecture is right, the output is products, not demos.
Corey
The engineAn agent OS that runs the recurring work of a business - the routing, roles, skills and memory described in The Agent OS, packaged so it runs for someone other than me. It lives in Claude Code, works in a folder you own, reaches your tools over MCP, and stops at the approval gate. It wrote its own website, wired its own checkout, and maintains this site.
Presso Network
EventsTicketing, event apps and the payments underneath them, for professional organisers. Real users and real money, which is where most of the auth and approval-gate thinking on this site came from.
Safebites
Allergen safetyTurns a restaurant menu into a clear allergen call for the person eating. Matching against the UK's 14 major allergens, with a places dataset behind it. A wrong answer here puts someone in hospital, so it is the strictest thing I have built.
Pocket
PropertyA private directory of off-market property listings that estate agents query in natural language through their own LLM, over MCP. The clearest example of building for a model as the primary user rather than a person.
This site
PublishingAstro on Cloudflare, agent-maintained, human-approved. The colophon documents exactly what it does unsupervised and what waits for me.
One person. No hires. The interesting part is not the volume - it is that the same routing, memory and approval model held across five very different products, which is the only evidence that any of it generalises.