Kinetic Layer

​

Alfred acts, not just remembers

Your vault holds what Alfred knows. But knowledge without action is just a filing cabinet. The Kinetic layer is where understanding becomes execution — handling the things that need doing so you don’t have to.

​

Temporal — the execution engine

Temporal provides durable workflow orchestration. Unlike simple cron jobs, Temporal workflows survive process restarts, automatically retry failed activities, log full execution history, and accept external signals. It runs as a Docker container on your encrypted volume. Every specialist, every intuition process, and every scheduled job runs as a Temporal workflow. You can monitor them from the Workflows section of your dashboard or via the API.

​

Matters

Matters are standing concerns that group related work. Think of a matter as an ongoing area of attention — “Kitchen renovation”, “Q2 product launch”, or “Tax preparation”. A matter doesn’t have a status lifecycle of its own; it exists as long as it’s relevant and collects the errands that belong to it. When the Curator or Judgment identifies work that relates to an existing matter, new errands are automatically grouped under it. This gives you a single place to see everything associated with a concern, rather than a flat list of unrelated tasks.

​

Errands

Errands are the execution units of the Kinetic layer — actionable tasks Alfred carries out on your behalf. They originate from everywhere:

• Instincts — when Judgment matches an instinct with an execution block, it creates an errand automatically
• Conversations — “I should call the accountant next week” becomes an errand
• Your dashboard — create errands directly when you know what needs doing
• Triage — items you promote from the triage queue become errands
• Consequentials — completing one errand can spawn follow-up errands

Each errand has an owner (alfred or human), a tier that governs its power, and optionally a skill — a methodology file that tells Alfred how to approach the work. Errands belong to a Matter when one exists.

​

Status lifecycle

Every errand moves through a defined lifecycle: todo → active → blocked → done

• todo — queued and waiting for the Task Runner (or you) to pick it up
• active — currently being worked on
• blocked — waiting on a dependency, another errand, or external input
• done — completed, with a ledger entry recording what happened

​

Triage

Not everything that arrives deserves immediate processing. When the Curator encounters an item it’s uncertain about — ambiguous intent, low confidence, or potentially sensitive — it routes the item to the Triage queue instead of acting on it. Triage items sit in your dashboard waiting for a human decision:

• Promote — convert to an errand (optionally assigning it to a matter)
• Dismiss — discard the item; Alfred learns from the dismissal

This keeps Alfred from acting on things it shouldn’t while ensuring nothing important falls through the cracks.

​

Tiers

​

The Task Runner

The Task Runner is a Temporal workflow that runs every 2 minutes, picking up errands with status=todo and owner=alfred. For each errand, it follows a pipeline:

1. Check prerequisites — verify depends_on and blocked_by are clear
2. Mark active — set the errand to active so it’s visible in your dashboard
3. Assemble context — gather the skill methodology, related matter, and relevant observations
4. Execute — run the work via OpenClaw sessions_spawn with full tool access, bounded by the tier’s turn budget
5. Write artifacts — create or update vault records as the skill directs
6. Mark done — close the errand and write a ledger entry recording what happened
7. Handle consequentials — spawn any follow-up errands that flow from the completed work

Errands owned by human skip the runner entirely — they appear on your dashboard for you to handle at your discretion.

​

Skills as methodology

When an errand references a skill, the Task Runner doesn’t just execute blindly — it follows the skill’s reasoning methodology. Skills are plain English files in your vault’s skill/ folder that describe how to approach a type of work: what to look for, what questions to ask, what patterns to follow, what to produce. This means Alfred’s execution is transparent and auditable. You can read the skill, understand the methodology, and refine it over time.

​

Ledger entries

Every completed errand produces a ledger entry — a consequential record that captures what was done, what was produced, and what follow-up errands (if any) were spawned. Ledger entries are stored as vault records, making them searchable and linkable. Ledger entries serve three purposes:

• Audit trail — you can always see exactly what Alfred did and why
• Continuity — follow-up errands reference the ledger entry that created them, maintaining a chain of causation
• Learning — the Distiller and Reflection processes use ledger entries to refine instincts over time

​

Chores

Chores are recurring scheduled jobs Alfred runs automatically on a cadence you define. Standing instructions, handled without you lifting a finger. Each chore is backed by a Temporal workflow running on a cron schedule. When the schedule fires, Alfred assembles the output — pulling from your vault, checking external sources, applying your preferences — and delivers the result through your preferred channel.

​

Rules

Rules are if/then automation defined in natural language. Tell Alfred what to watch for and what to do about it.

“When an invoice arrives by email, extract the amount and due date, then create a task three days before it’s due.”

“If anyone mentions a new competitor in a meeting, create a record and notify me.”

Rules are evaluated continuously against incoming stream events and vault changes. When a condition matches, Alfred executes the action — creating a task, sending a notification, updating a record, or triggering a chore. A single input can be routed by Judgment, processed by the Curator, triaged for human review, trigger an errand via an instinct’s execution block, and spawn follow-up errands — all without you doing anything beyond sharing the content.

​

The thirteen background processes

Alfred runs thirteen automated processes. You don’t need to manage them — they take care of themselves. All processes are managed by the Temporal Engine and can be monitored from your dashboard.