Pre-Mortem · March 8, 2026 · 8 min read

Using a Pre-Mortem Skill Before AI Agents Execute

Before agents run fast, ask how the project could fail. A pre-mortem turns imagined failure into blockers, proof requirements, and better execution plans.

Using a Pre-Mortem Skill Before AI Agents Execute cover illustration

Key takeaways

  • Run pre-mortems before high-risk or customer-facing agent work.
  • Convert risks into owners, mitigations, and proof gates.
  • Use pre-mortems to decide whether a workflow should be automated at all.

Fast execution needs slower thinking upfront

Agents make it easier to execute before the team has understood the risk. That is why a pre-mortem is so useful. Instead of asking whether the plan sounds good, the team imagines that it failed and works backward: what went wrong?

This simple move changes the conversation. It surfaces missing credentials, vague owners, weak data, unclear approval boundaries, unrealistic timelines, and quality standards nobody wrote down.

Use it for work that can embarrass or break the company

Not every task needs a pre-mortem. A low-risk research summary can move quickly. But customer-facing campaigns, production code, paid spend, investor outreach, data migrations, and autonomous publishing deserve one. The more visible or irreversible the action, the more useful the pre-mortem.

The output should not be a philosophical essay. It should create concrete changes: blockers, proof gates, test plans, approval requirements, or a decision not to automate yet.

Ask specific failure questions

Good pre-mortem questions are blunt. What would make this output unusable? What data might be wrong? Which integration could fail? What would harm the brand? What would create legal or privacy exposure? What would make the cost unjustified? What human decision are we pretending the agent can make?

Each answer should become a mitigation or an explicit accepted risk. If nobody owns a risk, the project is not ready.

Convert risks into proof

A pre-mortem becomes operational when it changes proof requirements. If the risk is a fake logo, proof requires real brand asset composition. If the risk is broken GitHub access, proof requires branch creation and test output. If the risk is weak outreach relevance, proof requires sourced personalization.

This is how risk management becomes execution quality instead of a separate checklist.

Keep the pre-mortem in memory

The pre-mortem should be saved to the library and linked to the issue. After the work completes, the postmortem should compare predicted risks with actual results. Were the concerns valid? Did something else fail? Should the runbook change?

Over time the company learns its own failure patterns. That is much more valuable than generic risk advice.

The best pre-mortem may say no

Sometimes the right answer is not to automate yet. The data may be poor, the workflow may be undefined, the downside may be too high, or the required judgment may still be human. A mature AI company accepts that boundary.

The goal is not maximum automation. The goal is valuable autonomy. Pre-mortems help tell the difference.

Related Regentics guides