Incident postmortem: three parallel investigations to a root-cause report

Scenario

A typical case: production sees a spike in 5xx errors, and the on-call engineer has three independent jobs to do at once — dig the error clusters and the first regression timestamp out of the logs, line up recent deploys by time and changed paths, and estimate the affected endpoints and request volume. Short on hands, these run one after another, causality gets pieced together only at the end, and the postmortem often slips to the next day.

The example writes those three investigations as three root tasks that start in parallel at the same moment, then hands their results as explicit dependencies to the downstream root-cause hypothesis and document synthesis.

How it works

The models in the table are the example repository's defaults; the actual choice is made per scenario at the design stage.

Each of the three investigation agents has a system prompt that fixes a JSON output structure: error clusters and the first regression timestamp; deploy candidates ranked by time and changed paths, plus exclusions; affected endpoints and an error-rate range. The two downstream agents output Markdown, and the writer's document sections are fixed as Summary / Timeline / Impact / Contributing Factors / Action Items.

Retries are configured downstream only: hypothesize-cause and write-postmortem each set maxRetries: 2, retryDelayMs: 500, retryBackoff: 2. None of the five agents declares tools or a toolPreset, so under OMA's deny-by-default grants each resolves to zero built-in tools — the logs and deploy records are embedded as text directly in the task descriptions, taken from two sample files under examples/fixtures/ in the repository: the 206-line incident-logs.txt and incident-deploys.json with 5 deploy records.

Result

Runnable output and how to verify it:

An API key is required by default. The script header lists ANTHROPIC_API_KEY as the prerequisite; run it with npx tsx packages/core/examples/cookbook/incident-postmortem-dag.ts.

There is a switch for local verification. Setting EXAMPLE_PROVIDER=openrouter moves all five agents and the orchestrator defaults to openrouter/free on the OpenAI-compatible adapter, reading OPENAI_API_KEY and OPENAI_BASE_URL instead. The agent config committed in the source is still anthropic / claude-sonnet-4-6, and the provider and model in effect are printed at startup.

The script asserts parallelism. After the run, verifyParallelism() takes the spread of the three root tasks' task_start timestamps and prints Parallel execution (< 500ms): YES only if it is under 500 ms — otherwise it prints ASSERTION FAILED and exits with code 1.

The output is saved to disk. On success the postmortem-writer's Markdown is written to incident-postmortem.md in the system temp directory, and the full path is printed to the console; on failure it lists each task whose status is failed.

Cost is visible. At the end of the run it prints total input / output tokens and converts them into an estimate using unit prices hardcoded in the script — a conversion built into the example.

Sources

How this relates to YuanASI

The material on this page is a cookbook example from the official open-multi-agent repository, maintained by YuanASI; the logs and deploy records the script reads are sample data shipped with the repository.

If you want this chain connected to your own logging platform, deploy system and on-call tooling — investigations in parallel, conclusions traceable to specific log clusters and commits, postmortems written to your company template — the matching YuanASI service is Multi-Agent System Integration →