Your AI Agents Have Amnesia — Here’s the Fix

I’ve got two Claude Max plans, a Max ChatGPT, Max Perplexity, Cursor, and Grok Bot. All running. All burning credits in different ways.

For a long time that was a problem, not a flex. Every one of them started from zero. I’d explain a client to Claude, get good work out of it, then open Cursor the next morning and explain the same client again. Multiply that across a dozen projects and you’re spending more time briefing your tools than using them.

Then I stopped treating agents like chat windows and started treating them like employees.

Onboard your agents like you onboard people

When you hire someone, you don’t re-explain the company every morning. You have a place where things are written down. Someone new starts, they read the docs, they get to work.

So I built that for my agents. They write useful task state, decisions, evidence, and lessons into the appropriate shared records. There’s a read-me at the top that says: if you’re a new agent on our team, start here. A configured agent reads the current records it is authorized to use before acting. The shared-memory architecture explains where those records belong; How the Agents Run the Company connects them to current roles, job packets, handoffs, and review.

The result is that I can work on a project in Claude, save a clear checkpoint, and continue in Cursor after it retrieves that checkpoint. I’ve got so many models going that I can forget which one I talked to. The useful continuity comes from the saved record. Opening another app does not grant it access to an earlier chat, and saving a file does not notify another agent that work is waiting.

This isn’t theoretical. I switched between three different models live and asked each one about work the others had done. They all knew.

The QA layer nobody builds

Here’s where most people get this wrong. They set up agents, the agents start producing, and nobody checks the output.

Every time an agent does something, another agent, different model and different context, needs to come in and QA it. Then a manager layer above that reviews the QA and improves the process. That’s not overhead. That’s the thing that keeps the whole system from quietly drifting into garbage.

We don’t just take an agent’s word for it. I’ll ask one to audit the others: go into GitHub, look at what my agents did in the last twenty-four hours, how many commits, how many tasks, give me a report. Trust but verify. Same as you’d do with a team of humans.

Start with the business goal, not the tool

I get asked constantly about the stack. Why GitHub and EC2? Why not just one?

Wrong question. Start with what you’re trying to accomplish, then pick the tool. Don’t boil the ocean. Not every patient should take the same medicine.

We use Amazon because we host a lot of files and maintain infrastructure for clients. We’re moving our WordPress sites onto Astro, so we handle that hosting ourselves. If you’re not doing that, you may not need it. The stack follows the goal.

What this actually buys you

I get a thousand emails a day. I don’t read most of them. Agents triage, draft, and handle what doesn’t need me.

An agent caught a subscription we’d stopped using and saved us a thousand dollars. Another runs an HVAC scorecard, grading companies in that vertical so we can see who needs what. When a client pinged me that his site was broken, I didn’t copy anything over or explain the history. I told an agent to go into my email and my messages and handle it. It had the context already.

I’ve gotten more done in the last week than in the year before it. And I mean measurable output, sales for clients and real work shipped, not writing code for the sake of writing code.

But the honest answer to why it works isn’t the models. It’s that the agents record the lessons worth keeping: skills, processes, what they tried, and what broke. Reviewed changes go into the maintained source. Each runtime must then refresh its installed copy or retrieve the updated record, and a fresh-task check must show that it actually uses the change. That is how skills propagate; pushing to GitHub alone does not update every running agent.

The part humans still have to do

You can’t read thousands of lines of code. Neither can your team.

So the last piece is visual. This is what we built the Money Tree for: a map of your business where you can see, at a glance, what’s producing and what isn’t. Public credibility on one side, private analytics on the other. Red where something’s broken, green where it’s fine. Open it in the morning and see where to point your attention.

That’s what the agents can’t do for you. They’ll do the work and document it. You still have to look at the whole thing and decide what matters.

Build the map. Then go be useful.

Originally published August 20, 2026.