Case study: agentic automation
Automation agents that can resume, retry, and explain their work.
Keep long-running workflow state outside the process so an automation agent can survive retries, wait for approval, and continue with the right operating context.
Long-running agents fail when workflow state lives in process memory.
Real automation is not a single prompt. It is a sequence of tool calls, approval gates, retries, and handoffs. When that state stays inside one worker process, a restart can repeat side effects or lose the reason a workflow paused.
Before
- Workflow progress hidden inside one agent run
- Tool output copied between prompts
- Retries risk repeating side effects
- Human approvals tracked in a separate system
With RushDB
- Goals, steps, approvals, and observations stored explicitly
- Every tool result attached to the active workflow
- Blocked steps retrieved by workflow ID
- A restarted worker resumes from durable 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.
Workflow checkpoints, approval gates, tool output, and operating context stay durable across retries.
{
"workflowId": "onboard-acme",
"kind": "customer_onboarding",
"GOAL": [{ "goalId": "activate-enterprise-account", "state": "open" }],
"STEP": [
{ "name": "verify-domain", "status": "completed", "idempotencyKey": "step-001" },
{ "name": "provision-workspace", "status": "blocked", "idempotencyKey": "step-002" }
],
"APPROVAL": [{ "name": "security-review", "status": "approved" }],
"TOOL_OUTPUT": [{ "tool": "dns-check", "status": "passed" }]
}Working example
Resume customer onboarding after an approval gate.
The onboarding agent stores completed work, pauses workspace provisioning for security review, and later retrieves the blocked step plus the relevant operating procedure.
WORKFLOW onboard-acme
GOAL activate-enterprise-account
STEP verify-domain status: completed
STEP provision-workspace status: blocked
APPROVAL security-review status: approved
SOP enterprise-onboarding{
"labels": ["STEP"],
"where": {
"workflow_id": "onboard-acme",
"status": "blocked"
},
"limit": 10
}{
"workflow_id": "onboard-acme",
"next_step": "provision-workspace",
"approval": "security-review: approved",
"guidance": "Provision after enterprise security review."
}TypeScript SDK
Persist the checkpoint. Retrieve the next action.
The workflow engine still owns execution policy and idempotency. RushDB gives each run durable, queryable state plus semantic access to the operating context it needs.
Implementation blueprint
Build the resumable automation path.
The long-running automation pattern uses the same durable goal-claiming and output-writing primitives as the multi-agent war-room demo.
- 01Model WORKFLOW, GOAL, STEP, APPROVAL, SOP, and TOOL_OUTPUT records
- 02Write each checkpoint before running side-effecting tools
- 03Use transactions for step claims and approval-state transitions
- 04Retrieve blocked or pending steps by workflow ID
- 05Resume with scoped SOP retrieval and idempotent tool boundaries
Build path
- Keep workflow state outside any one worker process.
- Treat human approval as an explicit record and status transition.
- Persist tool outputs with idempotency keys and workflow IDs.
- Use scoped semantic retrieval for operating procedures and prior observations.
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 around step claims, approval transitions, and side-effect boundaries.
Open docsRecords
Model workflows, goals, steps, approvals, and tool output as explicit durable records.
Open docsSemantic search
Retrieve SOPs, prior observations, and workflow context by meaning while filtering to one workflow.
Open docsHow it works
Build the smallest useful workflow first.
01
Model workflow state explicitly
Store the workflow, goals, steps, approvals, and tool observations as records with your workflow ID.
02
Pause without losing context
Write blocked status and approval records before the worker exits or hands control to a human reviewer.
03
Resume with scoped retrieval
Find the blocked step, verify the gate, and recall only the operating guidance relevant to the active workflow.
Know where it fits.
Keep side effects idempotent
RushDB persists workflow state, but your tool boundary should still use idempotency keys before provisioning, billing, sending, or mutating external systems.
Make approval gates visible
Treat human review as an explicit record and status transition so operators can inspect why an automation paused or resumed.
Questions developers ask.
Next step
Start with one focused workflow.
Related use cases
Explore all use cases