← Back to Blog
How Do I Turn Past Project Post-Mortems Into AI Agent Context So My Next Project Doesn't Repeat the Same Mistakes?

How Do I Turn Past Project Post-Mortems Into AI Agent Context So My Next Project Doesn't Repeat the Same Mistakes?

October 30, 2026·7 min read

Most post-mortems get written once, read once, and buried in a folder nobody opens again. The fix is simple: convert each one into a short, structured context file that your AI agent reads before it plans anything, so the lesson shows up as a constraint instead of a memory. I've run this across 26 ventures and the difference is not subtle.

Why do most post-mortems never reach your AI agent?

Because they were written for a human who was there.

That's the whole problem. A post-mortem written for closure reads like a story: what we set out to do, what went sideways, how we felt about it, what we'd do differently. It's a good document and it does nothing for an agent, because an agent doesn't need the narrative. It needs the rule that came out of the narrative.

I've watched this pattern for years. I trained more than 90,000 people across 18 years running NYIM Training, and the ritual was always the same. Everybody does a post-mortem after a bad project. Almost nobody reads it before the next one. The doc becomes a form of therapy, which is fine, but therapy isn't context.

What's becoming clearer to me is that the lessons learned knowledge base is the most underused asset in a founder's business. You already paid for those lessons. You paid in weeks and money and one very bad Thursday. Letting them sit in a Google Doc is choosing to pay for the same lesson twice.

What does a post-mortem need to look like before an agent can use it?

Four fields and a scope line. That's it.

The four fields:

  • Trigger: what kind of project or decision this applies to.
  • Decision: what we chose to do at the time.
  • Outcome: what actually happened, with a number attached if you have one.
  • Rule: the one-sentence constraint going forward.

The scope line matters more than people think. "Never schedule a kickoff before analytics access is confirmed in writing" applies to client onboarding. It does not apply to a content project. Read that rule without scope and your agent turns into a nervous bureaucrat that tries to enforce it on everything.

A real example from one of my businesses: a venue project ran two weeks past deadline because we assumed the vendor's insurance certificate was already on file. It wasn't. The rule that came out of it: "No vendor is booked until the COI is in the shared drive and dated within 12 months." That is checkable. An agent can check it. "We need to improve vendor onboarding" is not checkable, and that's what most post-mortems produce.

Use whatever tool gets it out of your head, but make the output structured. A Notion database with those five properties works. An Airtable base works. A plain markdown file in a folder works, and it's honestly where I'd start, because you can move it anywhere later.

How do I load those lessons into an AI agent operating system?

This is the part people overcomplicate.

Start with one file called lessons.md. Put your 15 or 20 most expensive lessons in it, each in the four-field format above. Then attach that file to every agent you use. In Claude, that's Project Knowledge. In ChatGPT, that's a custom GPT with the file uploaded. If you're doing dev work, it's a rules file in Cursor. All three are the same move: the lesson travels with the agent instead of living in a doc you forget.

Then add one line to your system prompt: "Before you plan anything, read lessons.md and flag any rule this plan would violate."

That instruction is what turns a pile of lessons into an operating system. Not the file. The instruction that forces retrieval.

When the file gets past 40 or 50 lessons, you'll want retrieval instead of a paste. A vector store on Supabase or Pinecone with the lessons chunked and tagged by project type works well. But I'd hold off. For most founders a few years in, the whole knowledge base fits in a context window with room to spare. Adding a database before you have the content makes you feel productive and teaches the agent nothing.

Because of that, I'd rather see someone with 20 sharp rules than 200 soft ones. The agent gets sharper with fewer, better-scoped constraints.

This is the same architecture I use across my own companies, where a lot of the work runs through an AI agent operating system instead of people re-explaining things every morning. The lessons file is the part that compounds. I wrote about the broader architecture at a.mastermindshq.business/ai-os-book if you want the full picture.

How do I keep the lessons knowledge base from rotting?

You have to treat it like a product with a maintenance schedule, not a document.

Three habits do most of the work. First, every post-mortem produces at most two new rules. Not ten. A post-mortem that generates ten rules generates zero usable context, because the agent can't prioritize them and neither can you. Pick the two that cost you the most money.

Second, review the file every quarter, 30 minutes, and delete anything that no longer applies to the business you're running now. Rules from a phase you've outgrown are worse than no rules, because they constrain decisions that don't exist anymore. I do this on a calendar block with coffee and nothing open except the file.

Third, let the agent draft the post-mortem. At the end of a project, hand it the timeline, the messages, and the final numbers and ask for the four fields. You edit. That takes the work from 90 minutes to 15, which is the difference between a habit that survives and one that dies in month two.

One more thing that pays off: tag each rule by project type so retrieval stays scoped. A simple type: client-onboarding line in the file is enough. Then when the agent plans a new onboarding, it pulls the onboarding rules and ignores the rest.

FAQ

How many lessons should I put in the agent's context?

Start with 15 to 20. That's enough to cover the mistakes that cost real money and few enough that the agent can hold all of them at once. Add at most two per project after that.

Do I need a vector database for this?

Not at the start. A single markdown file attached to a Claude Project or a custom GPT handles most founders for a year or more. Move to a vector store on Supabase or Pinecone when you pass 40 or 50 lessons and scoped retrieval starts to matter.

What if my old post-mortems are inconsistent and buried in Google Docs?

Pull out the five most expensive ones and rewrite only those into the four-field format. Each takes about 15 minutes. You don't need to rescue the archive, you need enough context to stop repeating the top mistakes.

The pattern that actually saves you money is boring: capture the lesson in a format an agent can check, attach it to every agent you run, and force retrieval before planning. I wrote the full playbook for this. How to Build Your Own AI Agent Operating System walks you through the exact architecture I use, step by step. You can get it at a.mastermindshq.business/ai-os-book.

Build your AI operating system from the book

Get Joe Che's AI OS book and turn these ideas into a practical operating system for your work.

Prefer to build it live with Joe? Join the AI Business Mastermind