What should an incident agent store?

Store durable workflow state: goals, steps, observations, decisions, handoffs, and links to supporting alerts, tickets, and runbooks. Keep transient chain-of-thought out of the database.

Can an agent resume after a model or process restart?

Yes. A new process can retrieve the same incident records and recall relevant observations by meaning, scoped to the incident ID.

How do I avoid duplicate work?

Model claimable goals explicitly and use a transaction around goal assignment or status changes. The exact orchestration policy remains an application concern.

Does every relationship appear automatically?

Nested imports create parent-child links. Attach domain-specific links such as supported-by, led-to, or handed-off-to when your workflow knows them.

How is this different from the shared-llm-memory blueprint?

Multi-agent incident response models short-lived, high-velocity coordination state — goals, observations, and handoffs scoped to one active incident. Shared LLM memory models longer-lived customer facts and episodes that persist across provider switches and outlast any single incident.

rushdb

Blueprint: incident response

Four agents. One outage. Shared operational memory.

Triage, root-cause, remediation, and communications agents each need the same incident facts: which ALERT fired, what GOAL is claimed, which OBSERVATION explains the failure, and which DOC or runbook supports the fix. RushDB stores all of it as linked records under one incident_id, so a remediation agent can retrieve the root-cause agent's OBSERVATION directly from the graph instead of receiving it secondhand through a forwarded prompt.

This RushDB blueprint coordinates triage, root-cause, remediation, and communications agents through a shared graph of INCIDENT, GOAL, OBSERVATION, and HANDOFF records that any agent can resume from instead of replaying prompt history.

Start free View docs

Passing prompts between agents is not coordination.

A live incident produces ALERT, TICKET, DOC, and OBSERVATION data faster than any one agent can hold in context, and passing prompts between triage, root-cause, remediation, and communications agents flattens that evidence into a summary that drops the details underneath it. When state lives only in prompt history, a restarted agent re-investigates from scratch, two agents can claim the same GOAL, and the eventual incident summary cites nothing anyone can check.

Before

Each agent carries a separate context window
Handoffs flatten evidence into a summary
Repeated investigation after a restart
Runbooks, alerts, and tickets stay disconnected

With RushDB

Goals and observations written as durable records
Supporting alerts, tickets, and docs linked in the graph
Agents recall incident context by meaning and incident ID
A resumed agent can continue from shared state

Graph intelligence on ingest

Incoming data becomes queryable graph context.

Incident data arrives as ALERT, TICKET, DOC, GOAL, and OBSERVATION records tied to one incident_id, and RushDB writes each into the graph as it's produced rather than waiting for a post-incident cleanup pass. A managed index on DOC.body makes runbooks and prior write-ups searchable immediately, so an agent claiming a GOAL can pull supporting evidence the moment it starts work.

Normalize as incident data arrives

RushDB infers types for ALERT, TICKET, GOAL, and OBSERVATION fields as each record streams in during a live incident.

Auto-link nested structure

A nested incident payload with alerts, goals, and docs becomes traversable parent-child records under one incident_id automatically.

Enrich scattered evidence

Suggested-relationship analysis can propose SUPPORTED_BY or LED_TO links between observations, tickets, and runbooks tied to the same incident.

Suggested relationship analysis requires an LLM configured for the project. Suggestions stay in draft form until you approve them, so inferred domain meaning never mutates the graph silently. You can also add explicit relationships through the SDK or API.

Review suggested relationship patterns

Data model

One flexible graph for the workflow.

Start with the payload shape your product already produces. RushDB stores it as Records, infers typed properties, and keeps nested or approved domain relationships queryable.

Schema sketch

Incident payload

One incident write can carry alerts, goals, docs, and early observations while later agents add handoffs and decisions.

{
  "incidentId": "inc-42",
  "severity": "sev2",
  "startedAt": "2026-06-03T09:14:00Z",
  "ALERT": [{ "alertId": "login-errors", "service": "auth", "count": 1842 }],
  "GOAL": [{ "goalId": "goal-rca", "state": "open", "ownerRole": "root-cause-agent" }],
  "DOC": [{ "docId": "runbook-auth-rollback", "title": "Auth rollback runbook" }],
  "OBSERVATION": [
    { "summary": "Failures started after auth rollout", "confidence": 0.82 }
  ]
}

Working example

Resume the investigation from graph state.

The root-cause agent stores an observation against the incident. A later remediation agent retrieves that evidence without receiving the earlier prompt history.

Input

INCIDENT inc-42
  ALERT login-errors
  GOAL identify-root-cause
  OBSERVATION "Failures started after the auth rollout"
  DOC auth-rollback-runbook

Query

{
  "labels": ["OBSERVATION"],
  "propertyName": "summary",
  "query": "What changed before login failures started?",
  "where": { "incident_id": "inc-42" }
}

Result

{
  "agent_id": "rca-agent",
  "incident_id": "inc-42",
  "summary": "Failures started after the auth rollout",
  "runbook": "auth-rollback-runbook"
}

TypeScript SDK

A complete starting point.

The example includes the one-time index setup so the retrieval path is explicit.

from rushdb import RushDB

db = RushDB('RUSHDB_API_KEY')

tx = db.tx.begin()
try:
    goals = db.records.find(
        {'labels': ['GOAL'], 'where': {'goalId': 'goal-rca', 'state': 'open', 'INCIDENT': {'incidentId': 'inc-42'}}, 'limit': 1},
        tx,
    ).data
    goal = goals[0]
    goal.update({'state': 'claimed', 'claimedBy': 'rca-agent'}, tx)
    tx.commit()
except Exception:
    tx.rollback()
    raise

context = db.ai.search({
    'labels': ['DOC'],
    'propertyName': 'body',
    'query': 'What changed before login failures started?',
    'where': {'INCIDENT': {'incidentId': 'inc-42'}},
})

Implementation blueprint

Build the incident war-room path.

Use this sequence to coordinate triage, RCA, remediation, and communications agents through shared RushDB records.

01Import one incident with alerts, tickets, docs, goals, and agents
02Create a managed index for DOC.body
03Claim GOAL records transactionally before each agent writes output
04Attach OBSERVATION, STEP, HANDOFF, and DECISION records to the incident
05Assemble the final summary from cited graph evidence

Build path

Model INCIDENT, ALERT, TICKET, DOC, GOAL, OBSERVATION, STEP, HANDOFF, and DECISION records.
Use transactions around goal claims and critical status changes.
Retrieve incident context by incident ID plus semantic search over indexed docs.
Require final incident summaries to cite the records they used.

Relevant docs

Read the exact primitives behind this pattern.

These links point to the RushDB docs pages that map directly to this blueprint: ingestion, labels, properties, values, SearchQuery, relationships, semantic search, MCP, or deployment.

Transactions

Use transactions for goal claims, handoffs, and critical incident-state changes.

Open docs

Relationships API

Connect observations to alerts, tickets, runbooks, decisions, and remediation records.

Open docs

Semantic search

Recall relevant runbooks and prior observations by meaning while filtering to the active incident.

Open docs

How it works

Build the smallest useful workflow first.

Write shared state

Store incidents, goals, steps, observations, and handoffs as records instead of hiding the workflow inside prompt history.

Connect evidence

Link observations to the alerts, tickets, decisions, and runbooks that support them.

Resume from the graph

Let the next agent recall relevant state by meaning while filtering to the active incident.

Know where it fits.

Durable state, not multi-agent chat

The useful proof is a resumed agent completing work from RushDB records without access to the earlier prompt history.

Use transactions for claims and handoffs

In production, claim goals and write critical workflow changes transactionally so two agents do not take the same task.

Questions developers ask.

Next step

Start with one focused workflow.

Start free

Related use cases

Explore all use cases

Agent memory

Keep state, decisions, and tool output available across sessions.

Explore agent memory

One memory across LLM providers

Keep customer context available when your application switches model providers.

Explore shared LLM memory