Incident agents that remember what the last fix actually did
At 3am the on-call engineer asks the agent what happened last time the queue backed up. The agent suggests a restart. Last time, the restart made it worse.
The mixture
- 01 · Persistent memory
- Uses
- 02 · Current context
- Uses
- 03 · Traceable decisions
- Leads
- 04 · Shared context
- Light
- 05 · Scoped retrieval
- Uses
Every incident is the first incident
Operations teams write down almost everything. The problem is that none of it is where the agent looks.
- 01
Postmortems are written, then never read
The postmortem says "do not restart the consumer, drain it first." It lives in a doc nobody opens at 3am, so the agent never retrieves it either.
- 02
Runbooks drift from reality
The runbook references a dashboard that was renamed and a flag that was removed. The agent follows it faithfully and the engineer loses twenty minutes.
- 03
The advice cannot be audited
After the incident, someone asks why the agent recommended the restart. Nobody can say which runbook, ticket or postmortem it was reading at the time.
Mostly traceable decisions. Then three others.
Every application on Alchemyst is a different mixture of the same five jobs. That mixture is what makes this a different piece of software from the one next to it, even though the API underneath is identical.
Every answer keeps its receipts
Every recommendation carries a Context Trace: which runbook, which postmortem, which past incident, with scores. The review starts from what the agent actually saw, and the fix goes into the source that misled it.
- Recommendations cite the runbook they used.
- Post-incident reviews start from evidence.
- Bad sources get fixed once, not argued about.
Uses · Persistent memory
The last incident, remembered
What was tried, what worked and what made it worse is written back when every incident closes.
Uses · Current context
The runbook in force
Superseded runbook versions are subtracted as soon as the new one lands.
Uses · Scoped retrieval
This service, this environment
Service and environment scopes are intersected, so staging advice never reaches production.
That is four of the five. The fifth, shared context (what one agent learns, the next one already knows, on the same definitions), is what leads in Sales agents, Customer success and Enterprise operations instead. Same API, different mixture.
The sources you already have
Bring sources in through the data-source integrations (PostgreSQL, MongoDB, Google Docs, Google Sheets, Amazon S3), an n8n workflow, or a direct context.add call. Each one lands scoped, so retrieval can intersect it with everything else.
01 · Ingest
Scope what you ingest
Every document lands with a groupName: the sets it belongs to. Those sets are what retrieval intersects later, so the structure you choose here is the precision you get there.
context.addimport AlchemystAI from "@alchemystai/sdk";const client = new AlchemystAI(); // reads ALCHEMYST_AI_API_KEYawait client.v1.context.add({ context_type: "resource", scope: "internal", source: "runbooks", documents: [{ content: "Orders queue backlog: drain the consumer group before restarting. Restarting first causes duplicate processing.", }], metadata: { fileName: "orders-queue-backlog.md", groupName: ["sre", "orders", "prod"], // the sets this belongs to },});02 · Write
Write the outcome when the incident closes
An incident is only useful next time if what was tried, and what happened, is stored as context. Write it when the incident closes, scoped to the service.
context.addawait client.v1.context.add({ context_type: "conversation", scope: "internal", source: "incidents", documents: [{ content: "INC-2291: Orders backlog. Restart made duplicates worse. Draining the consumer group, then scaling to 6 replicas, resolved it in 12 minutes.", }], metadata: { fileName: "inc-2291-outcome.md", groupName: ["sre", "orders", "prod"], lastModified: "2026-09-02T03:41:00Z", },});03 · Search
Search before recommending
Search intersects the scopes, subtracts superseded and duplicate content, and ranks what survives. Only that reaches the model, and the whole decision is recorded as a Context Trace.
context.searchconst { contexts } = await client.v1.context.search({ query: "Orders queue is backing up in production", scope: "internal", similarity_threshold: 0.8, minimum_similarity_threshold: 0.5, metadata: { groupName: ["sre", "orders", "prod"] }, // ∩ narrow scope});// − superseded, deduplicated → ranked → into the window// Every search is recorded as a Context Trace.const reply = await llm.respond(message, { context: contexts });
npm install @alchemystai/sdk or pip install alchemystai, both ship the same client. Full reference in the docs.
Incident context is an attack map
Runbooks, architecture notes and incident timelines describe exactly how your systems fail. Keep them in scopes only on-call agents can read, on dedicated or self-hosted infrastructure when policy requires it.
Security & complianceManaged cloud
Encrypted in transit and at rest, isolated per organization, and scoped at write time.
Dedicated infrastructure
EnterpriseSingle-tenant, with VPC peering when your data cannot share a network boundary.
Self-hosted
On-premiseRun the context layer on your own infrastructure, with OpenTelemetry for observability.
The same API, a different mixture
Each of these leads with a different job, pulls from a different set of sources and needs a different call. All of them, by job.
Bring the incident it made worse.
The one where the agent suggested the fix that failed last time.