Case study: incident response
Four agents. One outage. Shared operational memory.
Give triage, root-cause, remediation, and communications agents a shared graph of goals, observations, decisions, and supporting records.
Passing prompts between agents is not coordination.
A live incident produces alerts, hypotheses, ticket updates, runbooks, and handoffs. When that state lives only in prompt history, agents duplicate investigation and lose the evidence behind a decision.
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.
RushDB turns structured data into graph-ready context without a separate modeling pipeline. Structure already encoded in a nested payload is linked immediately. For flat records imported from scattered sources, relationship analysis can propose stable cross-source patterns.
01
Normalize as data arrives
Import JSON or CSV. RushDB infers property types and adds new fields to the live, queryable ontology without a schema migration.
02
Auto-link nested structure
Nested objects become connected records automatically, preserving the parent-child graph structure already encoded in your payload.
03
Enrich scattered sources
After flat imports or schema changes, analyze the project ontology. RushDB can suggest join patterns and semantic relationship types for your review.
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 patternsData 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.
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.
INCIDENT inc-42
ALERT login-errors
GOAL identify-root-cause
OBSERVATION "Failures started after the auth rollout"
DOC auth-rollback-runbook{
"labels": ["OBSERVATION"],
"propertyName": "summary",
"query": "What changed before login failures started?",
"where": { "incident_id": "inc-42" }
}{
"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.
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 case study: ingestion, labels, properties, values, SearchQuery, relationships, semantic search, MCP, or deployment.
Transactions
Use transactions for goal claims, handoffs, and critical incident-state changes.
Open docsRelationships API
Connect observations to alerts, tickets, runbooks, decisions, and remediation records.
Open docsSemantic search
Recall relevant runbooks and prior observations by meaning while filtering to the active incident.
Open docsHow it works
Build the smallest useful workflow first.
01
Write shared state
Store incidents, goals, steps, observations, and handoffs as records instead of hiding the workflow inside prompt history.
02
Connect evidence
Link observations to the alerts, tickets, decisions, and runbooks that support them.
03
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