Concepts

Holon is easiest to understand as a runtime, not a chat wrapper. The runtime centers on four simple objects that work together:

The mental model in four objects

Agents are the actors. Each agent has a durable home directory, its own guidance (AGENTS.md), local memory, and a work queue. You address an agent by its ID, and it persists across turns — it can sleep, wake, and continue work without losing state.

Work items are the objectives. They capture what the agent is trying to achieve, with a durable plan, a todo checklist, and a completion goal. Work items survive across turns and model calls, so an agent can resume after hours or days without losing progress.

Tasks are the execution. Every command, every child agent delegation, every background operation is wrapped in a task handle. You can inspect task status, read output, send input, or stop a task — the runtime tracks it all.

Trust boundaries are the provenance. Operator input, external webhooks, child agent output, and web-sourced content each carry an origin and a trust level. Holon never flattens them into one undifferentiated prompt stream.

Agent (who)
  └── Work items (what they're doing)
        └── Tasks (how they do it)
              └── Trust classification (where input came from)

Why this matters

Most agent tools work like chat sessions: a prompt goes in, a response comes out, and the state disappears. Holon is different because:

  • You can walk away and the agent keeps working.
  • You can inspect what the agent is doing without reading the entire transcript.
  • You can see where each input came from and how much to trust it.
  • You can delegate work to child agents and supervise their progress.

Boundaries of this section

The Concepts section is written for Holon users and integrators. It explains durable, observable semantics that remain true even if internal engine implementations change.

  • For step-by-step task workflows, see Guides.
  • For exact CLI flags, configuration schemas, and API parameters, see Reference.
  • For internal scheduler invariants and contributor contracts, see Runtime specs.