How Horme works

Horme is built around work, not around chat windows.

A job is represented as a workflow. The workflow contains tasks. Tasks can depend on other tasks. Each attempt to execute a task is a run. Runs create artifacts, hand context to later work, and can stop for human intervention.

Horme is in private beta. Parts of this page describe the connected workflow architecture that is still being built; what runs today is listed below.

The structure

PROJECT
  └── WORKFLOW
        ├── TASK
        │     └── RUN
        │           ├── events
        │           ├── artifacts
        │           └── provenance
        ├── TASK
        │     └── RUN
        └── REVIEW / INTERVENTION

A connected workflow

Consider a feature that needs implementation and independent review.

The next agent should not receive a blank prompt and force the developer to reconstruct the previous step manually. It should receive the relevant output of the work that came before it.

What travels with the work

A handoff can include:

The goal is not to send every token from every prior conversation. The goal is to send the relevant context needed for the next step.

Runs are separate from tasks

A task is the work that needs to be completed. A run is one attempt to complete it. A review is its own task, with its own runs.

task  implement rate limiting
  run 1  claude code  failed
  run 2  claude code  completed

task  review rate limiting
  run 1  codex        2 findings

Keeping tasks and runs separate makes retries, reviews, failures, and provenance understandable. Runs and retries already work this way in the private beta.

Provenance

Horme keeps the history underneath the work instead of scattering it across terminals and chat sessions.

A developer should be able to look backward and understand:

• Who changed this?
• Which run produced it?
• What did the reviewer see?
• What findings were passed forward?
• What changed after review?
• Where did a human intervene?

Needs You

Agents should be able to work without demanding constant attention, but Horme should never silently move past a decision that belongs to the developer. Examples include:

• A permission request
• A clarifying question
• Blocked execution
• A review decision
• A potentially destructive action

When that happens, Horme surfaces the intervention clearly. Downstream work waits. Independent work can continue. The Needs You inbox is being built.

Current private beta and product direction

Horme is in private beta. The current execution foundation runs real Claude Code and Codex tasks through one run model.

The connected workflow diagrams on this page describe that direction, not a shipped feature.

Why this architecture matters

A multi agent product becomes difficult to trust if it only shows several agents in one dashboard. The orchestration layer has to understand the relationships between their work. Horme is designed so that the system can eventually answer:

• This task exists because that task finished.
• This agent received this artifact.
• This review produced these findings.
• This fix addressed those findings.
• This verification checked that fix.
• This human approved the result.

That connected history is what turns multiple agents into a workflow. For the category itself, start with What is AI agent orchestration?