The AI I built doesn't forget, and it doesn't work alone

When I finished typing the title for this blog post, I paused for a minute. “Doesn't work alone,” I thought — or was it “doesn't walk alone”? Glad it wasn't “walk alone” since that's the Liverpool slogan, and the Arsenal fan in me would never allow it. Lol.

This isn't about soccer, but about how to get more value out of your AI projects if you aren't already doing so. Most people use AI the way you'd use a very smart stranger you meet once. You explain your situation, they give you good advice, and then they vanish. Tomorrow you come back and explain the whole thing again. It's useful, but it's amnesiac. Every conversation starts from zero.

The version of Claude Code I run is set up almost the opposite way. It's less like a chat box and more like an employee who keeps a notebook, hires specialists when a job needs them, and gets a little better every week because it writes down its own mistakes. Here's how it actually works — plain enough for anyone, with enough detail that the builders among you can copy it.

It remembers

The single biggest change I made was giving it a memory that survives between sessions.

Under the hood it's almost boringly simple: a folder of plain text files. There's one index file that gets loaded at the start of every single conversation — think of it as the table of contents the assistant reads before it does anything. Then each individual fact lives in its own small file, tagged with what kind of fact it is: something about me (I'm the CEO of an insurtech company, I have three kids), a piece of feedback ("never ask him to paste secrets into chat"), a note about an ongoing project, or a reference to some external resource. The files even link to each other, wiki-style, so related lessons cluster together.

Why does this matter so much? Because AI conversations have a hidden ceiling. When a chat gets long enough, the older parts get summarized and compressed to make room — the model literally loses the fine detail of what happened earlier. For most people that means the assistant quietly forgets the thing you told it twenty minutes ago. In my setup, the important stuff was already written to a file the moment it was learned, so it survives that compression. The assistant can lose the conversation and still keep the knowledge.

The payoff is the part I like most: it files its own lessons. When something breaks in a new and interesting way, it writes a "feedback" memory describing what went wrong and how to avoid it next time. A real example — one of my automated systems once appended a credential to a config file without a trailing newline, which silently mashed two secrets together and broke a deployment for weeks before anyone noticed. That's now a permanent written rule: always check for a newline before appending. It will never make that exact mistake again, because it left itself a note. Over months, that turns a general-purpose assistant into something that actually knows my specific systems and their specific landmines.

It's not one assistant, it's a team

The second shift is that "it" isn't a single thing answering me. It's a coordinator that can hand work to specialists.

When I ask for something non-trivial, the main assistant doesn't just start typing code. It can dispatch what are effectively sub-employees, each with a narrow job:

• An Explore agent that only reads and searches — I send it into a big codebase to find how something works and report back the conclusion, without dumping thousands of lines on me.
• A Plan agent that acts like an architect: given a goal, it designs the approach and weighs trade-offs before a single line is written.
• A bug-hunter that works test-first — it reproduces the bug with a failing test, fixes it, and only declares victory when the test passes.
• A deploy-verifier that watches a deployment go live, checks the real site is actually up, and automatically rolls back if it isn't.

Each specialist starts fresh, does its one job, and returns just the answer — not the mess of its work. It's the difference between one overworked generalist and a small, well-scoped team. And there's a discipline layered on top: for anything risky — deploying, pushing code, deleting things — it has to stop, show me exactly what it's about to do, and wait for my explicit yes. That plan-first gate has saved me from more than one confident mistake. In fact, this very blog post went through it: it drafted a plan, I edited it, and only then did it start writing.

It picks the right-sized brain, and scripts do the real work

Two smaller things make the whole system practical rather than just clever.

First, cost-aware routing. AI models come in different sizes, and the big ones are far more expensive per use. So the setup matches the model to the job: a small, cheap model for quick lookups and formatting, a mid-sized default for normal coding, and only the largest, most capable model for genuinely hard problems — cross-system architecture, security reviews, decisions that are expensive to get wrong. You wouldn't put your most senior engineer on data entry; same idea.

Second, a rule I think of as "the AI decides, the scripts execute." For anything I do repeatedly, the actual work is done by plain, deterministic little programs — the kind that behave identically every time — while the AI's job is to read the instructions, pick the right tool, and coordinate. The judgment is fuzzy and human-like; the execution is boring and reliable. That combination is what lets me trust it to run things while I'm asleep.

What it actually runs

Here's where it stops being a coding assistant and starts being an operation.

All that machinery — the memory, the specialist agents, the routing — drives a self-hosted AI gateway I run on a cloud server. It sits between my chat apps and the AI models, and it powers a whole fleet of always-on agents that each live in their own channel and handle a slice of my life and work: one does outbound sales research, one watches the markets and logs trades, others draft and publish blog posts, one is a concierge tracking onboarding deadlines, and one literally builds small working apps overnight from a queue of ideas. They coordinate, they message me when something needs a decision, and they clean up after themselves.

None of that required a team of engineers. It required treating the AI less like a magic answer machine and more like infrastructure you configure carefully — give it a memory, give it specialists, give it guardrails, and give it the cheapest brain that can do each job.

That's the real shift, and it's the thing I'd tell anyone thinking about this seriously: the frontier isn't a smarter chat box. It's the moment you stop asking an AI for answers and start building an organization around one. The models are already good enough. What's been missing for most people is the setup around them — and the setup is the part you can actually own.