Procedural memory

Successful behavior becomes a reusable procedure — workflows induced from credited traces, and curated skills served as provider-ready tool schemas.

Facts tell an agent what is true; lessons tell it what to watch out for. Procedural memory answers the third question: how do we do this here? Use this pattern when your agents repeat multi-step tasks — you want the second-hundredth ticket to follow a proven procedure, not a fresh derivation. Mubit gives procedures two forms: induced workflows the runtime distills from what actually worked, and curated skills you define and version deliberately.

How it works

Induced workflows (on by default). During idle sweeps, the runtime looks at a run's episodic traces that outcome attribution positively credited — not everything that happened, only what was tied to success (see The learning loop). Once enough credited traces accumulate, it distills them into a workflow entry: an ordered, imperative step list with run-specific values abstracted into placeholders (<ticket_id>, <row_count>), plus a title and one-line description kept in metadata so context assembly can inject a compact hint without spending body-sized budget. By default a run qualifies only if at least one credited source was verified in production — unverified success is not enough to mint a procedure. Workflows are semantic entries: later tasks retrieve them by similarity to the task at hand, and they surface in the Workflows context section (see Context priority).

Curated skills. Skills are managed resources — named tool or playbook definitions attached to a project (or a specific agent), versioned with a candidate → active promotion flow. Where a workflow is discovered, a skill is decided: you write it, review its versions, and activate the one agents should use. skill_type picks the form:

Rules vs workflows vs skills

Walkthrough

Two procedures at Nimbus. The CSV-export fix is induced: Ari resolved enough tickets with credited, production-verified outcomes that the runtime distilled the steps. The refund playbook is curated: it encodes policy, so no one waits for it to be discovered.

import mubit
 
# Module-level helpers read the context set up by mubit.init().
mubit.init(api_key=API_KEY, agent_id="support-ari", project_id="nimbus")
 
# ── Induced: the CSV-export workflow appears on its own ──────────────
# After several credited runs (record_outcome with success signals,
# at least one verified_in_production), an idle sweep induces it.
results = mubit.recall(
    "customer export is timing out",
    session_id="support:TCK-1101",
    entry_types=["workflow"],
)
print(results["evidence"][0]["content"])
# 1. Ask for the report row count for <ticket_id>.
# 2. If over <row_count> rows, switch the export to the batched exporter.
# ...
 
# ── Curated: the refund playbook is policy, so write it deliberately ─
mubit.set_skill(
    "refund_playbook",
    "How to process a customer refund, including the reviewer gate.",
    skill_type="playbook",
    instructions=(
        "1. Verify the charge in billing.\n"
        "2. Refunds over $500: hand off to Rex for approval.\n"
        "3. Apply the refund and confirm to the customer."
    ),
)
 
# Tool-type skills come back as provider-ready schemas — pass straight
# to your LLM call. format: "openai" (default), "anthropic", "gemini", "raw".
tools = mubit.get_skills(format="anthropic")
# anthropic_client.messages.create(..., tools=tools)

Version management is a raw-ops surface: client.advanced.list_skill_versions(...) to inspect, client.advanced.activate_skill_version(...) to promote a candidate, and top-level optimize_skill(...) to generate a candidate from recent outcomes — the full lifecycle is walked through in Prompt optimization (the same loop works for skills), and the HTTP endpoints are in the Control HTTP reference.

When not to use it

• The procedure must be byte-exact (a script, generated SQL, a config to re-execute). Workflows and playbooks are semantic text; store exact artifacts with archive() and fetch them back verbatim — see Verbatim vs semantic entries.
• One-off tasks. Induction needs repetition with credited outcomes; a task you'll never repeat has nothing to distill. Record the outcome anyway — it still feeds lessons.
• Constraints, not procedures. "Never do X" is a rule — unconditional and always injected — not a workflow that competes on task similarity.
• You aren't recording outcomes. Induction feeds on credit. Without record_outcome(), no workflow will ever be induced — close the loop first (The learning loop).

Related

• The memory model — where workflow and rule sit in the entry taxonomy and context priority
• The learning loop — outcome attribution and verification, the signals induction gates on
• Sleep-time consolidation — the idle worker that runs workflow induction
• Write-time reconciliation — why repeated procedures strengthen instead of duplicate
• Prompt optimization — the version → shadow-test → activate lifecycle, for prompts and skills alike
• Control HTTP reference — the /v2/control/skills/* endpoints