Incident to policy: a postmortem lesson that becomes a rule agents follow

How the Incident to policy workflow will turn the lesson from an incident into a tested policy change and a new context version the next agent reads.

Incident to policy is a workflow for builders and whoever is on call. When an incident closes, the lesson from it will propose a change to policy, be tested against past traffic before anyone relies on it, and go out as a new context version that agents read before they act. RepoOps, PromptCompute and ContextFile each do a part.

The workflow is partly built. Most of its steps already work inside one product each, and the missing piece is the step that turns a lesson into a policy change.

The problem

Postmortems produce lessons. The lessons go into a document, the document goes into a folder, and nobody enforces them. Weeks later an agent that never read the document makes the same change, and the same error comes back.

The gap is between knowing and checking. A lesson that says “never run this migration without a lock” helps only if something stops the next agent from doing it. Without a count, nobody can say how many of the lessons have a check behind them.

How the workflow solves it

The workflow will follow the lesson all the way to a rule. RepoOps opens a lesson candidate from the incident and files it for review. PromptCompute will propose the policy change the lesson implies, where a deny always wins over an allow. Before anyone promotes the rule, PromptCompute runs it in a shadow period, so you see what it would have decided before it decides anything. ContextFile publishes the lesson as a new context version, so the next agent reads it.

A person promotes the lesson at the end, so nothing will reach the agents unreviewed.

Step by step

When the workflow runner ships, a run will take these steps. Present tense means the part works in its product today; “will” means it is still to build.

A run will start when an incident closes in RepoOps, or when an action someone approved turns out badly. PromptCompute already tells RepoOps when an approved action turns out badly, and a lesson candidate opens.

1. RepoOps opens a lesson candidate from the incident.
2. RepoOps files it for review with propose_brain_entry. It also replays the lesson against that repo’s past failures and shows the result.
3. PromptCompute will propose the policy change the lesson implies. A person will approve it.
4. ContextFile publishes a new context version with the lesson, and the version names the incident it came from.
5. PromptCompute tests the new rule before it applies. In a shadow period, requests still go to people while PromptCompute records whether the rule would have agreed. Its Simulate button replays the last 30 days and shows which past requests would have gone differently.
6. A person promotes the lesson. Then it reaches the blocks in CLAUDE.md and AGENTS.md that the next agent reads before it edits that code.

The plan adds one check to the approval. If the shadow test would have blocked a request that later succeeded, the run will show that false block on the approval card, so the person promoting the rule sees its cost as well as its benefit.

What the workflow will report

Each run will report:

• The share of lessons with a check behind them.
• The errors that came back after a lesson was promoted.
• The days from incident to enforced policy.

The first number exists today for each product’s own brain. PromptCompute’s lessons with a check stood at 16 of 21 on 2026-11-07, with 5 unenforced and 1 error that came back. The workflow will report the same figures for your repos, run by run.

Why it matters to the person on call

Each incident should make the next one less likely. With this workflow you will be able to show which lessons have a check behind them and which are still words in a file, and the unenforced ones will become a list to work through.

It will also change what a postmortem produces. Instead of a document, the output will be a reviewed lesson, a tested rule and a context version, each with a record that names the incident it came from.

How to set it up

GitHub is the only outside connection.

When the runner and the signed-in app ship, setup will be:

1. Sign in with PromptReports ID and pick your org.
2. Connect RepoOps, PromptCompute and ContextFile, and link GitHub through RepoOps.
3. Register the agent that will run the workflow.
4. Set the approval policy for promoting a lesson (memory.lesson.promote) and publishing it to the agent instruction files (memory.agentmd.publish).
5. Choose the trigger, a closed incident or a bad outcome, and start a dry run.
6. Start the run. Review the lesson, the proposed rule and its shadow result, then promote it.

An agent will start the run through the PromptReports MCP server or API, with the proposed start_run tool.

Every plan includes this workflow. Plans are per user per month: $25 for 100 workflow requests, $50 for 500, and Enterprise above 500. There is no free tier. One incident taken to policy is one request.

Without the runner, an agent can already do the RepoOps half. It reads the brain with search_brain before it edits, and files a lesson with propose_brain_entry after something breaks. A person approves or revokes each lesson in RepoOps.

What is built today and what is planned

The workflows page lists Incident to policy as partly built: one of three parts is merged, and the RepoOps policy proposal and the PromptCompute approval are still to go.

In the products today:

• RepoOps opens a lesson candidate from a bad outcome and files it for a person to review.
• PromptCompute tells RepoOps when an approved action turns out badly.
• ContextFile publishes a lesson as a context version, and the version names the incident it came from (ContextFile #155).
• PromptCompute runs a new rule in a shadow period and simulates it against the last 30 days.

Planned:

• A reviewed RepoOps lesson that proposes a policy change.
• A PromptCompute approval for that change.
• The workflow runner. No runner exists today. The plan is a durable runner service in the PromptCompute stack, with one run id across products, approvals as steps, and each run metered as one workflow request.

Read more

• Every workflow and its state
• Pricing
• Memory a person can overrule
• RepoOps, PromptCompute and ContextFile