Workflow memory graphs

Workflow memory graphs represent past runs, tasks, and outcomes as nodes and relationships so OpenClaw can reason about what happened and what to do next. For US users, that means better continuity, fewer repeated mistakes, and smarter automation. This post covers concepts and practical use.

OpenClaw is a personal AI agent that runs on your machine and executes workflows across email, calendar, files, and APIs. Workflow memory is the stored record of what the agent did and what resulted. A graph structure: nodes (e.g., runs, tasks, entities) and edges (e.g., "run A produced task B," "sender X was triaged as Y"). lets the agent query and reason over that history. This post explains workflow memory graphs for US users.

Why graph-shaped memory?

Flat logs ("run 1 did X, run 2 did Y") are enough for audit. But when the agent needs to answer "what did we do last time we saw this sender?" or "which workflows touched this file?" or "what's the dependency between this task and that one?", relationships matter. A graph lets you:

• Traverse from an entity (e.g., email id) to past runs and outcomes.
• Aggregate by sender, project, or workflow type.
• Reason about cause and effect (e.g., "after we did X, user corrected to Y").

In the US, teams that run many workflows benefit from this for both the agent (smarter next steps) and for humans (debugging and compliance).

What goes in the graph

Nodes can represent:

• Workflow runs: id, workflow name, start/end, status (success/fail), trigger (user, cron, event).
• Tasks or steps: within a run: action, params (redacted), outcome.
• Entities: email id, calendar event id, file path, project id, sender, label.
• Outcomes: user correction, downstream result (e.g., "meeting accepted"), or failure reason.

Edges can represent:

• Produced: run R produced task T; task T produced outcome O.
• Touched: task T touched entity E (e.g., read email E, wrote file F).
• Followed: run R2 followed run R1 (e.g., same workflow, next execution).
• Corrected: outcome O was corrected by user to O'.

You don't need a full graph DB to start. A relational schema (runs, tasks, entities, outcomes, and link tables) can represent the same relationships and be queried like a graph for the agent's purposes.

How OpenClaw uses it

• Before a run: query: "past runs for this workflow," "last outcome for this sender," "tasks that touched this file." Inject summary or key facts into the prompt or workflow config so the agent avoids repeating mistakes and uses past success patterns.
• During a run: record each task and outcome as nodes/edges. Link to entities (email id, file path) so you can traverse later.
• After a run: update the graph (run node, task nodes, edges to entities and outcomes). Optionally compute aggregates (e.g., "success rate for workflow W by sender") for reporting or for the next run.

The agent can "remember" via this graph: either by being fed a short summary of relevant subgraphs or by having a tool that queries the graph (e.g., "get last 5 runs for workflow X" or "get outcomes for sender Y").

Implementation options

• Embedded: SQLite or similar with tables for runs, tasks, entities, and relationship tables. Application code (or a small service) writes and reads; the agent gets results via a tool or pre-run query. Good for single-user or small US teams.
• Graph DB: Neo4j, or a graph layer on top of Postgres (e.g., recursive CTEs or an extension). Use when you need complex traversals or very large history.
• Hybrid: recent runs in a fast store (e.g., Redis or SQLite); older data in a warehouse or analytics platform. Query recent for agent context; use warehouse for long-term analytics. Tools like SingleAnalytics can help US teams store and query event-level workflow data alongside other product data so you have one place for both agent context and business analytics.

Retention and privacy

• Retention: keep graph data as long as useful for the agent and for compliance. Prune or archive old nodes/edges by policy; avoid unbounded growth.
• Privacy: store entity ids and metadata (e.g., sender domain, label), not full content (email body, file content). Redact PII from outcome notes. In the US, align with your data and retention policies.

Summary

Workflow memory graphs give OpenClaw a structured, queryable history of what ran, what it touched, and what resulted. Model runs, tasks, entities, and outcomes as nodes and edges; use the graph before runs for context and after runs for updates. For US users, that improves continuity and debugging. When you want to combine workflow memory with product and business analytics, SingleAnalytics gives you one platform to unify events and insights.