Software teams have had that problem for decades, with people instead of agents, and they solved it with a handful of tools. I think those tools are about to leave engineering. This is the argument I made at the Canggu AI Meetup tonight; the slides are at the end.

The wall is trust, not tokens

Starting an agent is easy. Anyone can point one at an inbox or a spreadsheet in an afternoon.

The hard part comes afterwards. An agent rarely fails loudly. It summarises a little less carefully, skips a field in the CRM, drafts a proposal that is nearly right. If nothing checks the work and nothing records it, you find out weeks later, from a customer.

So the question worth asking isn’t “which agent?” It’s “how would I know?”

How a small team runs millions of lines

The codebase I work in every day is a little over five million lines, spread across 84 apps and services. A small team maintains it. Nobody reads it all, and nobody needs to.

It works because the agents that do much of the work operate inside a few rules we wrote down, and because nothing they produce lands without being checked. There are 253 written playbooks (we call them skills) and 48 specialised agents for planning, coding, reviewing and shipping. None of that is exotic. It’s mostly the standard toolkit of any well-run engineering team, applied to agents instead of people.

Four tools, in plainer clothes

Each of these exists in software because many hands working in one system break things in ways nobody notices until later. Agents are many hands.

• Checks the agent can run itself. Developers have tests: code that fails when something breaks. For everyone else it’s a checklist, a sample to compare against, or a number that has to move. An agent that can check its own work improves without you. One that can’t makes you the test.
• A record of everything. Developers have version history: every change, who made it, and a way back. For everyone else it’s Linear, Drive or Notion, as long as the agent writes where people already read.
• Know-how written down once. Developers have runbooks. For agents, the same idea is a skill: a short instruction loaded when the task needs it. The useful ones come from watching an agent fail at the same thing twice.
• Gates sized to the mistake. Developers have code review. For everyone else it’s approval: light for a draft email, heavier for a payment or a contract.

None of these need a developer. They need the habits developers have.

Keeping track is the one to start with

If I had to pick one, it’s the record. Every agent, whatever it does, writes to the same place: what it did, and whether its check passed.

That’s also how you catch the quiet failure. A shared log turns “the agent seems fine” into something you can see. If it isn’t tracked, it didn’t happen, and if it didn’t happen you can’t tell whether it went wrong.

The steps are about guardrails, not tokens

Boris Cherny, who built Claude Code, describes five steps of AI adoption: gated, then assisted (about one agent per person), parallel (about ten), supervised autonomy (about a hundred), and AI-native (a thousand or more). His point, which matches what I’ve seen, is that tokens alone don’t move a team up a step. Removing the next bottleneck and building the next guardrail does.

The four tools above are those guardrails. Most teams outside engineering are on the first or second step, and the jump to the third is where they start to matter: at ten agents per person, nobody can supervise every output by eye.

One install for the whole team

Habits spread badly by memo. What worked for us was packaging them. The team gets one plugin for Claude Cowork, installed once, with no terminal involved. It holds the skills, the connections to our own systems and the checks:

• Skills. For example, an inbox assistant that learns your tone from your sent mail and drafts replies on a schedule, or one that produces year-end investor statements.
• Connectors. Links to the company’s docs, CRM and data, so a question in plain words gets an answer from the real source.
• Checks. For example, a fact-checker that re-derives every claim in a draft before it goes out.

The plugin is built from what we actually run, so when someone adds a skill or a connection, everyone has it on the next update. Nobody maintains a list, which is the only reason the list stays true.

Can normal teams run this?

The meetup asked. Yes, with the tools, and none of them require writing code. Package the habits once and everyone installs them. Agents break things quietly only when there’s no check and no record; with both, a problem shows up in the log the same day.

The slides

Open questions

• How small can the record be before it stops being useful? A spreadsheet works for one team; I don’t know where it stops working.
• Who writes the skills in a team with no engineers, and who decides when one is wrong?
• Checks are easy for numbers and hard for judgement. What’s the checklist for “is this a good proposal”?

It’s tempting to conclude that software itself is getting cheap. I don’t think it is. What’s getting cheap is one part of it: turning a clear intention into working lines. The expensive parts were always elsewhere.

Code was never the bottleneck

Most of the cost of software sits after the first commit. Keeping it running, changing it without breaking something three layers away, explaining it to the next person, deciding what not to build. None of that got cheaper this year.

Cheap code actually adds pressure there. When producing a feature costs little, you get more features, more integrations and more surface area. Every one of them has to be owned, and ownership is what gets expensive.

What becomes valuable

If output is cheap, judgement is what’s scarce. In practice that looks like:

• Knowing where the boundaries are. Which parts of a system should know about each other, and which never should. A model will happily wire everything to everything.
• Choosing what to leave out. The fastest code to maintain is the code that was never written.
• Seeing second-order effects. A change to how money moves, or how data is stored, echoes through places nobody is looking at.
• Writing things down. Models work better with clear constraints, and so do teams. Good specs used to be a courtesy. Now they multiply everyone’s output.

None of these are new skills. They just used to be hidden behind the effort of typing, and now they aren’t.

Different work, not less of it

The work I do has shifted. I spend less time producing code and more time deciding what the code should be, reviewing what was produced, and designing the system it lands in. The job looks more like editing than writing.

That makes the reviewer the bottleneck, which is uncomfortable. A model can produce a thousand plausible lines in a minute, and plausible isn’t the same as correct. So I lean on tests, types and small, reversible steps: the unglamorous tools that make fast change safe.

Open questions

• If juniors learn by writing the code a model now writes, where does the next generation of systems thinkers come from?
• How much review is enough when the volume of changes keeps growing?
• Which of today’s “best practices” were really workarounds for expensive code, and can quietly go?

A different kind of model

Jev, from TypeSafe, is a good example of another shape. Instead of writing free text, you give it structured state and a fixed set of options, and it returns one choice with a confidence attached. No prose, no conversation. A decision.

That sounds like a limitation. In practice it’s the point. A model that can only choose from valid options can’t hallucinate an invalid one. Its answer is typed, so the software around it can trust the format and act on it immediately.

Why small matters

When a model only has to decide, it can be small and fast. That changes what you can build with it:

• Decisions in a loop. Many small choices per second instead of one long answer.
• Cost you can ignore. Cheap enough to call for every step, not just the important ones.
• Predictable behaviour. The set of possible outputs is known in advance, which makes it testable.

It’s closer to a game engine’s logic than to a chatbot, and that’s where it gets interesting.

Interfaces without chat

If the model decides instead of talks, the interface doesn’t need a text box. It can be a character moving through a world, a system choosing its next step, an old piece of software driven by something that has never seen a keyboard.

Those experiments look strange next to today’s assistants, and that’s why I like them. Every new kind of model has made new interfaces possible, and the first ones always look like toys.

Open questions

• Which everyday software is really a long series of small, typed decisions?
• How do you show someone what a decision-making model is doing, without a transcript to read?
• When does a choice from a fixed set stop being enough?

They can reason surprisingly well about whatever is in front of them, but start a new conversation and much of that understanding disappears. You explain the company again. The project again. Your preferences again. The reason a decision was made three weeks ago, again.

For a chatbot, that can be mildly annoying.

For an agent that is supposed to do useful work over time, it becomes a fundamental limitation.

Over the past year I’ve spent a lot of time building with agents and thinking about what happens when they stop being isolated prompts and begin operating as persistent software systems.

Memory turns out to be one of the more interesting parts.

Not because storing information is difficult. We have been exceptionally good at putting things into databases for several decades.

The difficult part is deciding what deserves to be remembered, what it means later, and when it should come back.

Memory is not a transcript

The obvious implementation of agent memory is to save every conversation.

That is useful, but it isn’t really memory.

A transcript is history. Memory is compression.

Humans don’t replay every sentence they have ever heard before making a decision. We retain some facts, forget others, form abstractions and gradually build a model of the world.

An agent needs something similar.

Imagine an engineering agent working inside a large codebase.

Over time it might discover that:

• a certain service deliberately avoids local state,
• a particular API has an ugly compatibility constraint,
• the team prefers one architectural pattern over another,
• a bug that looks obvious has already been investigated twice,
• one engineer tends to care deeply about backwards compatibility,
• another system is scheduled to disappear in six months.

None of those facts necessarily belong in the immediate prompt.

But they can dramatically change the quality of the next decision.

The useful unit of memory therefore isn’t:

Here is everything that happened.

It is closer to:

Here is what appears to remain important.

That distinction sounds small. It changes the architecture considerably.

More context is not the same as more intelligence

Large context windows created a tempting idea: perhaps we can simply give models everything.

Eventually, that becomes its own failure mode.

An agent with access to thousands of irrelevant facts can be worse than one with ten useful ones. Retrieval becomes noisy. Old assumptions survive long after reality changed. Contradictory information accumulates.

Context has a cost even when the model can technically accept it.

The real problem becomes selection.

When an agent is working on a database migration, what should it remember about the product?

When it is replying to a customer, what should it know about the architecture?

When a user changes their mind, how quickly should an older preference lose authority?

The quality of a memory system is therefore not measured by how much it stores.

It is measured by how well it decides what to surface.

That starts looking less like a database problem and more like an information architecture problem.

Which, conveniently, means software engineers get to reinvent librarianship with embeddings.

Memories have different lifetimes

Another thing that becomes obvious surprisingly quickly: not all memory should behave the same way.

Some things are effectively permanent.

This application uses PostgreSQL.

Some are durable preferences.

Prefer boring infrastructure over introducing another service.

Some are observations.

The current implementation appears to be CPU-bound during type checking.

Some are temporary.

We are debugging the authentication flow this week.

And some are conclusions that may later turn out to be wrong.

This bug is probably caused by caching.

Treating all of these as equivalent creates trouble.

Useful agent memory needs some notion of provenance, confidence and time.

Where did this belief come from?

Was it explicitly told to the agent or inferred?

Has it subsequently been contradicted?

When was it last relevant?

That metadata matters because an agent is not merely retrieving facts. It is retrieving beliefs about a changing system.

Software changes.

Organizations change.

People change their minds.

A memory system that cannot forget eventually becomes a very confident historian of a world that no longer exists.

Forgetting is a feature

This may be the counterintuitive part.

Good memory requires good forgetting.

Engineers naturally like persistence. Losing information feels like failure.

But forgetting can be an important form of compression.

If an agent worked through twenty hypotheses before finding the cause of a production bug, the useful long-term memory probably isn’t all twenty hypotheses.

It might be:

Requests to this service can appear stale because this cache is process-local. Prefer the shared Redis path for cross-instance state.

The investigation mattered while solving the problem.

The conclusion matters afterward.

That raises an interesting question: should agents periodically reinterpret their own histories?

I think increasingly they will.

Rather than memory being written once and retrieved forever, persistent agents may continuously consolidate what they know. Recent experiences become observations. Repeated observations become patterns. Some patterns become durable knowledge. Others decay.

That starts to resemble learning, even if the underlying model weights never change.

Memory changes the interface

Persistent memory also changes how software feels.

Today we largely think of AI interfaces as conversations.

Open a box. Ask a question. Receive an answer.

But once the system remembers projects, decisions, people and unfinished work, the conversation becomes only one view into something larger.

The interesting object isn’t the chat.

It is the evolving relationship between the agent and its environment.

An agent might remember that a migration was postponed, notice the dependency has since disappeared, and bring the issue back months later.

It might understand why a particular architectural decision was made instead of merely observing that the code exists.

It might recognize that the problem somebody is describing today looks suspiciously similar to an incident from last year.

At that point the system begins to feel less like a tool waiting for commands and more like another participant in the work.

That introduces plenty of uncomfortable questions around privacy, control, observability and trust.

It also makes the software considerably more useful.

The model is only part of the product

Building with increasingly capable models has reinforced something I already believed about software.

The cleverest component is rarely the whole product.

A powerful model without the right context can produce a mediocre result. A slightly less capable model embedded in a system with good tools, useful memory and strong feedback loops can be remarkably effective.

The surrounding architecture matters.

So does product judgment.

What information do we expose?

What actions can the agent take?

When should it ask instead?

What should be remembered?

What should disappear?

What can the user inspect and correct?

Those decisions increasingly determine whether an AI system feels impressive for five minutes or remains useful after five months.

Where this gets interesting

I don’t think the eventual form of agent memory will look much like a folder labelled memories.

It will probably be distributed across several layers: explicit facts, semantic retrieval, project state, interaction history, environmental observations and learned preferences.

Some memory will belong to a person.

Some to a company.

Some to a task.

Some to the agent itself.

And agents will need to reason about the boundaries between them.

We are still early enough that many of these systems feel slightly improvised. That is part of what makes working on them fun.

A lot of AI right now is focused on making the model smarter.

I suspect an equally important frontier is making software around the model better at remembering what matters.

Because intelligence without continuity is useful.

But continuity is what starts turning intelligence into a system.

That’s changing. Software can now propose, decide and act: move funds when conditions are met, rebalance a portfolio, respond to a request at three in the morning. The question is no longer only whether the numbers are right. It’s who, or what, was allowed to act.

From records to decisions

Programmable money made the first step possible. Assets that can be held and moved by code mean the rules can live next to the value instead of in a separate process. Models add the second step: software that can read a situation and choose an action within those rules.

Put together, you get an actor. Not a person, not a tool, but something in between that holds permissions and uses them.

Permission is the product

When software acts, the interesting design problem is the permission model:

• Scope. What exactly may it do, with how much, and for how long?
• Limits. Hard caps that no instruction can override, enforced where the money lives, not in the prompt.
• Approval. Which actions need a human, and how that human sees enough context to say yes quickly and safely.
• Undo. Money often can’t be pulled back, so the checks have to happen before the action, not after.

Good financial infrastructure already thinks this way about people. Delegated access, spending limits and multi-party approval are old ideas. The new part is applying them to something that acts at machine speed and never gets tired.

Accountability doesn’t move

Regulation doesn’t care whether a person or a program made the call. Someone is still responsible. That’s healthy: it forces clear lines between what the software proposes and what an accountable party authorises.

The systems that work will make those lines visible. Every action traced to a permission, every permission traced to a person, and a log you could show an auditor without rewriting it first.

Open questions

• How much autonomy will customers actually want over their own money, once it’s on offer?
• What does a useful audit trail look like for a decision made by a model?
• Where should limits live: in the model, the application, or the asset itself?

A prototype is a question

Most product decisions look obvious in a document and turn out to be wrong in a browser. The flow that read well has a step nobody wants. The data model that looked clean can’t express the one case that matters.

Building the thing is how I find out. A rough version answers more questions in a day than a week of discussion, because it forces every vague decision to become a specific one.

Where the problems hide

The things that sink projects are usually boring: an integration that behaves differently than its documentation, a latency that makes an interaction feel broken, a permission nobody thought about. You meet them early when you build, and late when you don’t.

When I’ve built the first version, I know where those are. That makes me a better reviewer, a better estimator and a better person to argue with about the plan.

Models changed the maths

Prototyping used to be expensive enough that it had to be justified. With models doing much of the typing, a working sketch now costs hours instead of weeks. The trade-off tipped: it’s now often cheaper to build a version and look at it than to debate whether it’s worth building.

The skill that matters is knowing it’s a prototype. It exists to answer a question, and once it has, most of it should be thrown away. The dangerous prototype is the one that quietly becomes production.

What I keep

• Taste. You only develop a sense of what feels right by making many things that don’t.
• Credibility. It’s easier to lead engineers when you still do the work.
• Speed. The shortest path from idea to decision usually runs through something you can click.

Open questions

• At what team size does building it yourself start to get in the way?
• How do you hand off a prototype without handing off its shortcuts?