So, settle in because I'm about to tell you what I've learned.

If you've been following me on X/Twitter, you'll probably know that I've been chipping away at Vetuu, a massively multiplayer online roleplaying game (MMORPG). When I first sat down to plan the game I ended up making a defensive decision which at the time I had no way of knowing would actually be the perfect primer for giving agents longterm memory. The decision was simple, instead of jumping into gameplay loops I decided to focus on architecture instead.

Back in 2025 (which feels like a life time ago) only the research-nerd layer of AI was talking out loud about agent memory. Mem0 had just landed but the broader conversation hadn't really reached most working developers. That was bad news for me because a long-running solo MMO like Vetuu probably wouldn't survive long without it. Fortunately, I was working in a place full of AI nerds so I started paying attention to what they were posting and that's when I started to go down the rabbit hole.

What I've ended up building is a chain of eight things the agent does every time I spin up a session. It starts by reading where we left off, leans on two libraries for grounding, sketches a plan before any code (yes, I believe in plan mode), attacks the plan from five angles, writes the code, attacks the code from five more angles, commits, pushes and merges while obeying my risk-gate, and finally finishes by writing a note for the next agent. None of these are particularly exotic on their own. BUT stitching them together is the part most people are content on skipping (usually in favor of velocity) and then end up paying dearly for it down the line.

So my chain begins where every session begins, with the agent reading back where I left off. Every working session it spins up starts by reading a history of what's been happening on the project, just like flipping through a PRD before joining a meeting to discuss the merits. It learns what shipped yesterday, what was borked last week, what I was trying to fix on Friday and never quite finished, etc, etc. None of which I will ever remember because I don't have room in my brain for every piece of context, especially if there was a weekend in the middle, or I was sleep-deprived or distracted or just deep in something else, which most weeks I am to be fair. Without this, every session would start from zero, and zero is a VERY expensive place to start these days when you're building something in a frontier model.

What compliments the memory? Well, my agents lean on two libraries and I didn't realize how powerful this was going to be until I kept shouting into the ether and learned to take the definition of insanity seriously. Agents need very specific and often niche training manuals to succeed in highly specialized areas. If we're being brutally honest this is probably the moat for most companies that want to survive. That little bit of institutional knowledge that makes your product crush evals that no agent out of the box could. So what are mine or at least how am I beginning to build the moat?

One is engineering fundamentals (Brooks on essential versus accidental complexity, Parnas on what to hide in code because it's eventually going to change, the small set of ideas that have aged well over fifty years of building software). The other is game development specifically (combat math, networking patterns, the AI textbooks that explain how non-player characters should behave). I didn't expect this part, but the agent reaches for both libraries in two directions. When it's proposing what to build, the libraries shape the design, this is what I wanted. But in addition when it's reviewing what it just built, the same ideas become a cool lens for whether the work earned its place. This is like having two experts in the room from different specialities and it really, really matters. The first time I felt this was when the agent caught itself proposing some clever mechanism that touched twenty-something files for a problem that turned out to be two edits. Brooks would have called that the sprawl of accidental complexity in 1986, except now the agent was catching it before I had to, so that's freaking cool!

Once the kick off is done, the agent draws me a plan so I can take a look before any code gets touched. This sounds painfully obvious if you're a creative of any kind (measure twice, cut once). But it's also painfully heavyweight if you're used to telling an agent to just go and fix the thing. So what you really want is a plan because as an artifact that plan costs very little to change. You also get to push back on a plan in the same way a real collaborator would. It's worth noting that by nature it's ephemeral (it gets deleted when the work is done) but the act of writing it forces you to think. A worrisome trend emerging right... more and more builders are choosing to skip the thinking steps in favor of velocity, often blind to the tradeoffs.

Then the plan goes through five rounds of challenge, and each round picks a different angle (important to spell the angles out or the agent WILL fake it). During each round the agent will decide whether to promote or demote a claim:

• The first round re-examines the plan from my perspective.
• The second from what could go wrong with the approach.
• The third forces it to step back and ask... are we over-engineering this? This is where it calls on the engineering handbook I mentioned earlier.
• The fourth takes a trip outside the code for evidence (could be a research paper, could be a service contract, could just be checking that what I'm saying about the world is actually true, I'm often confidently wrong).
• The fifth is the cleanup round, where the agent re-reads everything it parked as uncertain in earlier rounds and decides whether to promote it back, confirm the doubt, or escalate it to a real concern.

As I mentioned earlier the trick that makes the whole thing work is that each round has to use a genuinely different angle than the round/s before it. The first time I ran this seriously I tracked the bugs emerging across the rounds, and it went four, then zero, then four, then three, then one. The zero felt absurd at the time, like maybe the chain had tapped out, until I noticed that round had accidentally used the same angle as round one, and the curve was actually telling me something specific. When the angles really differ you find things EVERY time, and when they don't you find sweet FA.

Only after all of that preamble do I actually let the agent start writing code. This is the part most folks imagine when they think about using agents to build, and it's almost always the smallest portion of the actual session. Remember that at this point the agent's already done the heavy lifting (figuring out where it left off, choosing an angle, sketching the plan, defending it from five attacks and my stupid questions). So far in my experience writing the code is the part that tends to go smoothly. Or if it doesn't, that's usually a clear signal to me that there's something off in the angle calibration. I use the mistakes to tweak the angle efficacy, honestly I kinda had to because nothing beats trial and error in practice.

Then five more rounds of challenge, this time against the code that just got written. Same shape as before, I make it run the same system of angles and rotations. The standard angles look at what else in the codebase might have the same root cause (you'd be surprised how many times agents hit symptoms and not causes), whether the earlier fixes accidentally broke something new, how the new code talks to neighboring code, whether the change is grounded in real external evidence, and whether the whole thing might be simpler than I made it (yup, most of the time). By the time those rounds are done the agent has reviewed its own work twice, once at the plan stage and once after implementation, from something like ten different perspectives, which is honestly about what I'd want if I were pair coding with a human. Of course I'm not pair coding with another human and that's the whole point of building this level of rigor into the process.

When all that's done, the session has a kinda closing-down ritual. The agent updates the project's history, notes what shipped today, runs a final cleanup pass on the files it touched. The intuition behind this is probably the one any creative has, it's the state you leave your desk in. It matters because you're going to come back to it, and frankly a lot of the discipline here is about making sure tomorrow I don't open Cursor and immediately want to cry.

The very last thing the agent does is write a short note for the next agent to read. Not a recap, not a summary, basically just a plain English handoff. It covers what's in flight, what's actually next, anything subtle that would be hard to reconstruct cold. The reason most agent setups break down on longer projects is they just don't have this, and so every session starts from zero, which is fine for an afternoon's work and kinda catastrophic for anything meant to live for years. Which is the same memory thing we started the post with, I just turn it around to face the other direction.

What I keep coming back to is how unflashy all of this is. The chain ends up giving the agent roughly the same things a human collaborator would need to do good work. Context of what happened yesterday, the plan before any code exists, a second opinion before anything ships, a clean workspace to come back to, and a note for the next kiddo showing up. The winning formula turned out to be as simple as wiring them all together.

If any of this is appealing, there's a low-stakes way to start. Drop a plain markdown file at the root of your project, name it AGENTS, and most agentic coding tools in 2026 will pick it up and read it (Cursor, Codex, Copilot, Devin all read it natively). Claude Code uses its own equivalent file called CLAUDE, and Gemini CLI uses one called GEMINI, both often symlinked (which is a fancy way of saying a file that points to another file) to AGENTS so all three names can point at the same file. Tell it what you're building, the commands you run, and the two or three corrections you keep having to make. That single file is the foundation everything else in my chain refines. The next step beyond that is a pair of notes you update at the end and start of each working session, one for where you left off and one for what's next, which gives the agent a working memory (which as explained is super important and what most people skip). The step beyond that is writing the plan in a file before work begins, which gives a human collaborator (that's you) a chance to push back while the artifact still costs basically nothing to change.

One thing worth repeating from my previous writing... This isn't cheap, and the specifics will most likely age like milk. A full session of this chain costs more than your average shoot-and-pray prompts, sometimes by a LOT. The model I'm running right now will have a different name next year, and my tool list will likely wither and die.

As @soleio would say... the future belongs to designers who ship.

Have fun, be a little weird and don't let anyone hold you back.