Architecture, canonical work, claims, run packets, verification, delivery, durable knowledge, and cold-pickup state.
Agents / Assembly 2.0.0 / 2026-08-01
One SISO Agent Stack.
A versioned, publicly installable assembly that keeps every component independently addressable while one distribution pins and verifies how they operate together.
The canonical hierarchy
Great Library of SISO
└── Agents section / browse view
└── SISO Agent Stack versioned assembly
├── SISO Project OS required component
├── SISO Agent Runtime required component
├── Agent Zero required component
├── Skills Hub required component
├── Agent Playbook required component
├── Agent Hooks required component
├── Agent Brain optional component
├── Session Intelligence optional component
├── Agent Integrations optional component
└── Herdr optional external component
SISO Agent Stack Distribution one-clone installer for the assembly
The component row is deliberately flat. Runtime, coordination, memory, model, tool, and playbook labels do not become artificial second-level categories. The assembly record carries each component's contextual role and connections.
What each component owns in this assembly
Runs agent sessions, lifecycle, context, status, profiles, and command surfaces without owning project truth or coordination policy.
Holds intent, priorities, lane boundaries, durable context, dispatch state, evidence distinctions, and final synthesis. The current artifact is a skill, not a generic playbook category.
Supplies reusable capabilities installed into both supported hosts from exact source pins.
Composes skills, tools, prompts, lanes, gates, and evidence into repeatable operating scenarios.
Generates Claude Code and Codex hook configuration from one manifest and verifies exact installed payloads.
Provides durable task, artifact, memory, timeline, heartbeat, cost, and coordination APIs without publishing live databases.
Learns from explicitly supplied sessions while raw inputs and generated state remain outside the distribution.
Houses experimental runtime adapters with independent promotion and rollback gates.
Provides persistent workspaces and addressable lanes while retaining external ownership and Apache-2.0 licensing.
The operating loop
1
Orient
Agent Zero reads the human outcome against Project OS state.
Orient
Agent Zero reads the human outcome against Project OS state.
2
Brief
Agent Zero, Runtime, Skills, and Playbook select roles, capabilities, and an explicit return contract.
Brief
Agent Zero, Runtime, Skills, and Playbook select roles, capabilities, and an explicit return contract.
3
Run
Runtime executes while Hooks and optional Herdr lanes expose observable lifecycle state.
Run
Runtime executes while Hooks and optional Herdr lanes expose observable lifecycle state.
4
Prove
Hooks enforce verification; Project OS and optional Brain persist the appropriate durable truth.
Prove
Hooks enforce verification; Project OS and optional Brain persist the appropriate durable truth.
5
Synthesize
Agent Zero returns verified state and the next bounded action.
Synthesize
Agent Zero returns verified state and the next bounded action.
Skills and playbooks belong together
| Concept | Meaning | Placement |
|---|---|---|
| Skill | A reusable agent capability with a trigger, bounded instructions, and an expected result contract. | With the component or package that owns the behavior; indexed across the stack. |
| Playbook | A scenario-specific composition selecting and sequencing skills, tools, lanes, model choices, evidence, and verification. It may itself be delivered through a skill. | With its owning capability package; not a separate top-level stack layer. |
| SISO Agent Playbook | An independently released package containing scenario skills, tools, prompts, telemetry, and evidence. | Required Assembly component and independently addressable Work. |
| SISO Agent Hooks | Mechanical lifecycle automation around host events, commands, state, and completion verification. | Required Assembly component and independently addressable capability pack. |
Where the other concerns go
| Concern | Why it is not a section under Agents | How it is represented |
|---|---|---|
| Models and CLIs | They are replaceable execution capacity, not durable product hierarchy. | Dependencies, providers, adapters, and evidence attached to the component that uses them. |
| Memory and context | They are responsibilities distributed across Project OS, Agent Base, and Agent Zero. | Owned records and capabilities, with explicit source-of-truth boundaries. |
| Research and evaluations | They explain or test decisions; they do not operate the stack by themselves. | Evidence attached to a Work, Release, Assembly, or decision. |
| A newly independent package | It becomes independently forkable, releasable, or referenceable. | A new stable Work linked into a later Assembly version. |
How the model evolves without pretending V1 is perfect
- Works keep stable IDs even if repositories, names, and sections move.
- An Assembly is immutable. A changed stack creates Assembly 1.1 or 2.0 instead of rewriting history.
- Roles are contextual strings inside the Assembly, not universal object classes.
- New browse trees, dependency graphs, onboarding views, CLI output, and MCP responses are generated from the same Assembly record.
- A category is added only when it is stable over time, mutually useful, and changes what a person or agent can do.
The machine-readable current source is registry/assemblies/siso-agent-stack-v2.json, validated by schemas/assembly.schema.json. Immutable V1 remains preserved. This HTML is an explanation, not a second registry.
Evidence read before classification
V2 is grounded in the exact public Stack manifest, Hooks manifest, clean-install receipts, host-native Claude Code and Codex configuration, component release records, and independent 97/100 and 98/100 adversarial reviews.