Curated core
SYSTEM.md, SOPs, skills, scripts, tests, manifest. You never edit the core — you pull new versions like any dependency.
TAO
The Agent Observatory
Curated, portable, operational AI agents. Inspect the dossier. Understand the authority boundaries. Take one home.
What TAO is
Engineered colleagues, not prompt libraries.
TAO is not a skill marketplace, a prompt library, or a collection of character cards. It is a registry of complete operational agents — packages with curated SOPs, deterministic scripts, orchestration, adaptation workflows, and evidence-based verification.
Each agent ships as a versioned package with a clear operating doctrine, bounded authority, and an induction workflow that adapts it to your environment without touching the curated core.
Two-layer portability
Local adaptation
Accounts, regions, paths, tools, approvals. Induction interviews your environment, observes what's safe, and produces a local overlay — without touching the curated core.
The invariant: local adaptation may tighten authority or replace environment bindings, but must never silently weaken safety constraints or verification requirements.
How it works
Four-step journey from discovery to deployment.
Discover
Browse the registry of available agents. Each entry lists maturity, authority model, supported platforms, and surfaces it covers — so you know what you're getting before you commit.
Inspect
Open the dossier. Every agent publishes its SYSTEM.md, agent.yaml manifest, SOPs, and scripts. Read the authority boundaries, the taskrail structure, and the induction workflow. Satisfy yourself it does what it claims and nothing else.
Induct
Clone the agent and run pi run induct. The induction workflow interviews your environment, detects platforms and tools, proposes safe bindings, and generates a local adaptation layer — no manual configuration, no silent surprises.
Deploy
Run tasks through the agent's SOPs. Each operation collects evidence, proposes actions, stops at approval gates, executes through bounded wrappers, verifies results, and produces a full audit trail. You always know what changed and how to undo it.
Registry integration
Consuming packages from an agent harness.
TAO packages are not just human-installable — they can be discovered, fetched, verified, and installed programmatically by a compatible agent system. In practice, a TAO package is a pi-hydra head: its SYSTEM.md becomes the agent's system prompt, its taskrails become callable workflows, and its authority declarations determine what tools the head can use.
Discover & verify
list_registry_agents reads the generated registry index (tao.json) and shows every available package alongside your install state. In verify mode, it re-hashes every installed package against its pinned revision and reports drift — so a tampered file is caught before it affects anything.
Onboard
onboard_agent fetches a package at a pinned revision, verifies its tree hash, materialises exactly the curated file set, and registers it as a head. If the package declares requires (teams referencing their members), those install too — teams as files, not heads, because a team is a composition.
The resolution contract
The index and the repository are separate by design. The index carries repository and revision; acquisition uses the repository's own archive transport:
fetch = <repository>/archive/<revision>.tar.gz
unpack = that tarball's <path>
verify = tree hash of the package == the index's sha256No release pipeline. No npm. The archive transport already exists — github.com/<repo>/archive/<sha>.tar.gz is immutable and unauthenticated. Because the hash covers content, not tarball bytes, it survives GitHub regenerating archives. A 40-hex revision is required in the index; an unpinned index is refused.
Authority → tools, and its honest limit
A package that declares no mutation gets a read-only tool set (read, ls, grep, find, bash). Every TAO package gets bash because its SOPs are scripts. edit and write are added only when the manifest declares a mutation that is not prohibited.
pi-hydra has no approval UI, so TAO's read | propose | mutate | destructive authority stays doctrine-enforced, not harness-enforced. bash is equivalent to full user authority. This is stated plainly because it matters: review a package's source before onboarding it. Installation is always explicit — no task can install a package as a side effect.
Pinning and drift detection
The index requires a 40-hex revision per entry. The installer materialises exactly the hashed file set — never the extracted tree — so excluded directories (local/, backups/) cannot smuggle unverified content into an install. Provenance lives outside the package directory in a ledger, so a re-hash of an installed package still equals its pinned value. list_registry_agents { verify: true } reports any divergence.
This integration is shipped in pi-hydra phases 0–2. Composition — the LLM-driven ad-hoc team builder and the deterministic team.yaml → DAG adapter — is designed but not built. The pi-hydra build log has the full story.
Philosophy
Operational, not theatrical
Judged by repeatable behaviour, not impressive persona paragraphs. An agent that produces verifiable audit logs is worth a thousand character descriptions.
LLM inside the cockpit
Scripts establish facts. SOPs establish sequence. The LLM handles judgment, novelty, and natural-language reasoning — within bounded guardrails, not free-roaming.
Authority is explicit
Every agent declares exactly what it can read, propose, mutate, and destroy. Per-surface approval gates mean you approve each change individually. No inference, no assumptions.
Verification is part of the task
No task completes without evidence. After every mutation, the agent re-probes, compares before and after, and records the result. Completion requires proof, not self-assertion.
Small roster, high trust
Five excellent operational units beat five thousand character cards. Every agent in the registry earns its place through reliable behaviour, clear documentation, and a well-defined scope.
Explore the registry
Each agent has a full dossier — authority model, platform compatibility, taskrail structure, and induction workflow. Inspect before you induct.