Memory Type Deep Dive: Workflows

You know how to ride a bicycle. You know how to make coffee. You know how to deploy a new release to production. These are all examples of procedural memory — knowing how to do something, as opposed to knowing what is true.

In the Open Memory Specification, procedural memory is captured by the Workflow memory type. Defined in Section 8.4 of OMS v1.0, Workflows encode learned sequences of actions with explicit triggers — when some condition is met, execute these steps in this order. They are the reusable playbooks that agents can follow, share, and improve over time.

This post covers the Workflow memory type in depth: its trigger-steps model, how agents learn workflows from patterns, versioning through supersession, serialization details, and practical use cases across industries.

What is a Workflow?

The spec defines a Workflow as:

Procedural memory — learned sequence of actions.

A Workflow has two core components: a trigger that describes when to execute, and steps that describe what to do, in order. This is a simple but powerful model that captures everything from "if disk is full, run these cleanup commands" to "when a new employee starts, follow this onboarding checklist."

The key word in the spec definition is learned. Workflows are not just static procedures written by humans — they can be extracted from observed patterns in an agent's behavior. When an agent notices that it keeps performing the same sequence of tool calls in response to the same kind of situation, that pattern can be formalized as a Workflow grain and reused.

Required Fields

The Workflow type has four required fields (Section 8.4):

Both steps and trigger must be non-empty — a workflow without a trigger condition or without any steps is meaningless. The steps array must contain at least one element, and trigger must be a non-empty string.

Here is a minimal Workflow:

{
  "type": "workflow",
  "trigger": "disk usage exceeds 90%",
  "steps": [
    "Check largest files in /var/log",
    "Archive logs older than 30 days",
    "Clear temporary files in /tmp",
    "Notify admin via Slack"
  ],
  "created_at": 1768471200000
}

The header byte for Workflow is 0x04 (Section 3.1.1, Type enum), so this grain's 9-byte fixed header would begin with 01 00 04 — version 1, no flags set, Workflow type.

Optional Fields

Workflows have just two optional fields:

The default importance of 0.7 is the same as Facts, reflecting that procedural knowledge — knowing how to do something — is as valuable as declarative knowledge. This is higher than Episodes (default 0.5) and Observations (default 0.3), which serve as raw input data rather than refined knowledge.

Workflows also inherit the common optional fields available to all grain types through the core field map (Section 6.1):

These inherited fields enable rich metadata, provenance tracking, and inter-grain relationships — but for many Workflows, the four required fields plus namespace and importance are sufficient.

The Trigger-Steps Model

The trigger-steps model is deliberately simple:

• Trigger: A natural-language string describing the condition under which this workflow should execute. It is a description, not executable code.
• Steps: An ordered array of strings, each describing one action to take. The order matters — per Section 4.6, array elements preserve insertion order.

This design choice is important. OMS is a data format, not an execution engine. The trigger is not a boolean expression that can be evaluated mechanically — it is a description that an agent (or human) interprets. Similarly, each step is a description, not a function call. The agent decides how to interpret and execute each step.

This keeps the format simple and universal. A trigger like "customer reports billing discrepancy" is understandable by any agent, regardless of its implementation language or tool ecosystem. An execution-ready format like if customer.report_type == 'billing_discrepancy' would tie the Workflow to a specific data model.

Trigger Examples

Triggers describe when:

"disk usage exceeds 90%"
"new employee starts onboarding"
"customer requests account cancellation"
"RSI crosses below 30"
"build fails on main branch"
"patient vital signs exceed threshold"
"monthly reporting period begins"

Steps Examples

Steps describe what, in order:

{
  "trigger": "customer requests account cancellation",
  "steps": [
    "Verify customer identity through two-factor authentication",
    "Check for outstanding balance or pending transactions",
    "Offer retention incentives based on customer tier",
    "If customer confirms cancellation, process refund for unused period",
    "Schedule data export delivery within 30 days",
    "Send cancellation confirmation email",
    "Log cancellation reason in CRM"
  ]
}

Each step is a self-contained instruction. The agent processes them sequentially, using whatever tools and capabilities it has available.

How Agents Learn Workflows

Workflows can be authored by humans, but the most powerful use case is agent-learned workflows. Here is how the learning pipeline works:

From ToolCalls to Workflows

The ToolCall memory type (Section 8.5) records every tool invocation an agent makes: the tool name, arguments, result, success/failure, and duration. Over time, these records reveal patterns:

1. Observation: The agent (or a meta-agent) notices that in response to situation X, it consistently executes tools A, B, C in that order.

2. Extraction: The repeated pattern is extracted as a Workflow grain with trigger describing situation X and steps describing the A, B, C sequence.

3. Provenance: The new Workflow carries derived_from pointing to the ToolCall grain content addresses that informed the pattern, and provenance_chain entries recording the extraction method.

For example, an agent that repeatedly runs the same sequence when debugging a service outage might generate:

{
  "type": "workflow",
  "trigger": "service returns 503 errors",
  "steps": [
    "Check service health endpoint",
    "Review recent deployment history",
    "Inspect pod resource utilization",
    "Check database connection pool status",
    "Review application error logs for root cause",
    "If resource exhaustion detected, scale horizontally",
    "Verify recovery via health endpoint"
  ],
  "created_at": 1768471200000,
  "namespace": "incident-response",
  "importance": 0.8,
  "derived_from": [
    "a1b2c3d4e5f6...",
    "b2c3d4e5f6a1...",
    "c3d4e5f6a1b2..."
  ],
  "provenance_chain": [
    {
      "source_hash": "a1b2c3d4e5f6...",
      "method": "pattern_extraction",
      "weight": 0.9
    }
  ],
  "structural_tags": ["devops", "incident-response", "auto-learned"]
}

From Episodes to Workflows

Episodes (Section 8.2) capture raw interaction records. When multiple Episodes describe similar sequences of actions, consolidation can extract the common procedure as a Workflow:

1. Episodes record conversations where users describe their processes: "First I check the logs, then I restart the service, then I verify the fix."
2. A consolidation process identifies the repeated pattern across Episodes.
3. The pattern is extracted as a Workflow with source_type: "consolidated" and appropriate consolidation_level on any related Facts.

Procedural vs. Declarative Memory

Understanding the distinction between Workflows and Facts is crucial for correct use of OMS memory types:

The absence of a confidence field on Workflows is notable. Facts require a confidence score because they are claims that may or may not be true. Workflows are procedures — they either work or they do not. Their effectiveness is tracked through other mechanisms: the success_count and failure_count fields (available on all grains via the core field map, Section 6.1) and through supersession when an improved workflow replaces an underperforming one.

Workflow Versioning Through Supersession

Workflows evolve. An incident response playbook gets refined after each incident. A customer onboarding procedure gets updated when new compliance requirements emerge. A deployment pipeline gets improved when a new tool becomes available.

In OMS, workflow evolution is modeled through supersession, not mutation. Since all grains are immutable, you cannot edit an existing Workflow. Instead, you create a new Workflow grain that supersedes the old one.

Here is how the supersession chain works:

Version 1 — Initial workflow:

{
  "type": "workflow",
  "trigger": "new deployment to production",
  "steps": [
    "Run integration tests",
    "Deploy to staging",
    "Run smoke tests on staging",
    "Deploy to production",
    "Monitor error rates for 15 minutes"
  ],
  "created_at": 1768471200000,
  "namespace": "deployment"
}

Content address: <hash-v1>

Version 2 — Improved workflow (adds canary deployment):

{
  "type": "workflow",
  "trigger": "new deployment to production",
  "steps": [
    "Run integration tests",
    "Deploy to staging",
    "Run smoke tests on staging",
    "Deploy canary to 5% of production traffic",
    "Monitor canary error rates for 10 minutes",
    "If canary healthy, proceed to full rollout",
    "Deploy to all production instances",
    "Monitor error rates for 15 minutes"
  ],
  "created_at": 1768557600000,
  "namespace": "deployment",
  "derived_from": ["<hash-v1>"],
  "provenance_chain": [
    {
      "source_hash": "<hash-v1>",
      "method": "workflow_revision",
      "weight": 1.0
    }
  ]
}

Content address: <hash-v2>

After the new grain is written, the index layer sets superseded_by: "<hash-v2>" on the v1 grain (Section 15.3). The system_valid_to timestamp is also set on v1, marking when it was replaced. Any agent looking for the current deployment workflow finds v2. But v1 is never deleted — it remains as an immutable historical record, reachable by its content address.

The derived_from and provenance_chain fields on v2 explicitly link it to v1, creating a traceable lineage. An auditor can follow the chain to see how the deployment procedure evolved over time, who made each change (via author_did), and when each version was active.

Industry Use Cases

IT Operations Runbooks

IT runbooks are a natural fit for the Workflow type. Every standard operating procedure — server provisioning, incident response, backup verification, capacity planning — can be encoded as a trigger-steps Workflow.

{
  "type": "workflow",
  "trigger": "disk usage exceeds 90%",
  "steps": [
    "Identify largest files and directories with du -sh",
    "Check for core dumps in /var/crash",
    "Archive application logs older than 7 days",
    "Clear package manager cache",
    "If still above 85%, notify infrastructure team",
    "Document findings in incident ticket"
  ],
  "created_at": 1768471200000,
  "namespace": "ops-runbooks",
  "importance": 0.9,
  "structural_tags": ["infrastructure", "disk-management", "runbook"]
}

When an AI operations agent detects the trigger condition, it can retrieve the relevant Workflow and execute the steps in order. The structural_tags enable quick filtering: namespace="ops-runbooks" narrows to operational procedures, and tags further narrow by domain.

Manufacturing Standard Operating Procedures

Manufacturing SOPs define step-by-step procedures for operating equipment, handling materials, and performing quality checks. Encoding these as Workflows makes them machine-readable and executable by factory floor agents:

{
  "type": "workflow",
  "trigger": "batch quality check required for production line B",
  "steps": [
    "Pause production line B conveyor",
    "Select 5 random samples from current batch",
    "Measure dimensional tolerances using CMM",
    "Record surface roughness measurements",
    "Compare all measurements against spec sheet QC-2024-B",
    "If any measurement out of tolerance, quarantine batch",
    "If all pass, approve batch and log results",
    "Resume production line B conveyor"
  ],
  "created_at": 1768471200000,
  "namespace": "manufacturing-sops",
  "structural_tags": ["quality-control", "line-B", "batch-inspection"]
}

Automated Trading Strategies

Trading strategies are procedures triggered by market conditions. The trigger describes the market signal; the steps describe the response:

{
  "type": "workflow",
  "trigger": "RSI crosses below 30 on 4-hour timeframe",
  "steps": [
    "Confirm RSI reading on daily timeframe for convergence",
    "Check if current price is above 200-day moving average",
    "Verify volume is above 20-day average",
    "Calculate position size based on 2% portfolio risk",
    "Place limit buy order at current support level",
    "Set stop-loss at recent swing low minus 1 ATR",
    "Set take-profit at 2:1 risk-reward ratio",
    "Log trade setup with entry rationale"
  ],
  "created_at": 1768471200000,
  "namespace": "trading-strategies",
  "importance": 0.9,
  "structural_tags": ["mean-reversion", "equities", "systematic"]
}

DevOps Deployment Playbooks

Deployment workflows benefit from the versioning model. As the deployment pipeline matures — adding canary releases, feature flags, rollback procedures — each iteration creates a new Workflow grain that supersedes the previous one. The full version history is preserved in the supersession chain.

Customer Escalation Procedures

Support teams have escalation procedures that vary by issue severity, customer tier, and time of day. Each variation can be a separate Workflow with specific triggers:

{
  "type": "workflow",
  "trigger": "enterprise customer reports data loss incident",
  "steps": [
    "Immediately page on-call engineering lead",
    "Create P1 incident ticket in tracking system",
    "Acknowledge to customer within 15 minutes",
    "Assign dedicated incident commander",
    "Begin root cause investigation with database team",
    "Provide customer update every 30 minutes",
    "Once resolved, schedule post-incident review within 48 hours",
    "Deliver written incident report to customer within 5 business days"
  ],
  "created_at": 1768471200000,
  "namespace": "customer-support",
  "importance": 0.95,
  "structural_tags": ["escalation", "p1", "enterprise", "data-loss"]
}

Serialization Details

When a Workflow grain is serialized following the canonical algorithm (Section 4.9):

1. Validate required fields: type must be "workflow", steps must be a non-empty array of strings, trigger must be a non-empty string, created_at must be present.
2. Compact field names via the field map: type becomes t, created_at becomes ca, namespace becomes ns, importance becomes im. The Workflow-specific fields steps and trigger keep their full names (Section 6.4).
3. Preserve array order: The steps array maintains insertion order (Section 4.6). This is critical — the whole point of a Workflow is that steps execute in sequence.
4. NFC-normalize all strings (Section 4.4), including every step string and the trigger string.
5. Omit null values (Section 4.5).
6. Sort map keys lexicographically (Section 4.1).
7. Encode as MessagePack.
8. Prepend the 9-byte fixed header with type byte 0x04.
9. Hash with SHA-256.

For a Workflow with namespace and importance set, the compacted and sorted keys would be: ca, im, ns, steps, t, trigger — six keys in lexicographic order.

Workflows and the Success/Failure Feedback Loop

While Workflows do not have a confidence field, they participate in a feedback loop through two core fields available on all grain types (Section 6.1):

• success_count (int, non-negative) — number of times this workflow was executed successfully
• failure_count (int, non-negative) — number of times execution failed

Because grains are immutable, these counts are tracked by creating new Workflow grains that supersede the current one with updated counts. Over time, the ratio of successes to failures provides an empirical reliability measure.

A workflow with a high failure count is a candidate for revision — the agent (or a human) can analyze the failure patterns and create a superseding Workflow with improved steps. The provenance_chain on the new grain links back to the old one, and the method might be "workflow_revision" or "pattern_extraction" depending on how the improvement was derived.

Sharing Workflows Across Agents

Because Workflows are self-contained grains with standard serialization, they can be shared between agents, teams, and organizations:

• Within a team: Agents in the same namespace can discover and use each other's Workflows.
• Cross-team: The related_to field (Section 14.2) can link a Workflow to related Workflows in other namespaces, with relation_type: "similar" or "elaborates".
• Cross-organization: Workflows can be exported as .mg files (Section 11) and imported by other systems. The content address provides integrity verification — the receiving system can confirm the Workflow has not been tampered with.
• With signing: For high-trust sharing, Workflows can be wrapped in COSE Sign1 envelopes (Section 9) with the author's DID, providing cryptographic proof of authorship.

Design Considerations

Step Granularity

How detailed should each step be? There is no spec-defined rule, but practical guidance:

• Each step should be a single, actionable instruction
• Steps should be understandable in isolation
• If a step has sub-steps, consider creating a separate Workflow for the sub-procedure and referencing it with related_to

Trigger Specificity

Triggers should be specific enough that the agent can reliably determine when to activate the workflow, but general enough to apply across similar situations. A trigger like "something goes wrong" is too vague. A trigger like "PostgreSQL connection pool at IP 10.0.1.42 exceeds 95% utilization on the read replica" is too specific. "Database connection pool utilization exceeds 90%" strikes a better balance.

Namespace Organization

Use namespaces to organize Workflows by domain: "ops-runbooks", "deployment", "customer-support", "trading-strategies". This enables efficient namespace-based filtering via the header namespace hash (bytes 3-4) without payload deserialization.

Summary

Workflows encode procedural memory — the knowledge of how to do things. Their trigger-steps model is deliberately simple: a natural-language condition paired with an ordered list of natural-language actions. This simplicity makes them universally portable across agents, languages, and domains.

The real power comes from three characteristics:

1. Learnability: Agents can extract Workflows from observed patterns in ToolCall and Episode grains, formalizing ad-hoc behavior into reusable procedures.

2. Versioning: The immutability model and supersession chain provide automatic, auditable version history. Every workflow revision is traceable, every change is documented, and every previous version is recoverable.

3. Shareability: As standard OMS grains, Workflows can be shared across agents, teams, and organizations with integrity verification via content addressing and optional cryptographic signing.

Whether encoding IT runbooks, manufacturing SOPs, trading strategies, or customer escalation procedures, Workflows turn informal knowledge into structured, verifiable, portable procedural memory. They are the playbooks that agents can follow, share, improve, and trust.