Automation agents that can resume, retry, and explain their work.

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 like security-review, retries, and handoffs across a WORKFLOW such as onboard-acme. When that state stays inside one worker process, a restart can repeat side effects like re-provisioning a workspace, or lose the reason a STEP was marked blocked and which SOP should guide the next action.

Graph intelligence on ingest

Incoming data becomes queryable graph context.

A WORKFLOW payload nests STEP, APPROVAL, and SOP records under a shared workflow_id like onboard-acme. RushDB links each STEP and APPROVAL to its parent WORKFLOW automatically, keeps status transitions queryable, and indexes SOP content so a resumed worker can retrieve both the blocked step and the operating procedure relevant to that specific workflow_id.

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.

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.

{
  "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.

from rushdb import RushDB

db = RushDB('RUSHDB_API_KEY')

db.records.import_json({
    'label': 'WORKFLOW',
    'data': {
        'workflow_id': 'onboard-acme',
        'STEP': [
            {'workflow_id': 'onboard-acme', 'name': 'verify-domain', 'status': 'completed'},
            {'workflow_id': 'onboard-acme', 'name': 'provision-workspace', 'status': 'blocked'},
        ],
        'APPROVAL': [{'workflow_id': 'onboard-acme', 'name': 'security-review', 'status': 'approved'}],
    },
})

blocked = db.records.find({'labels': ['STEP'], 'where': {'workflow_id': 'onboard-acme', 'status': 'blocked'}, 'limit': 10})

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.

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.

How it works

Build the smallest useful workflow first.

Know where it fits.

Questions developers ask.