Your agent acts. Your code decides.

Pitot separates two capabilities that are easy to blur: observing what the agent did, and deciding what happens next. A passive Consumer cannot reach the response channel. A Controller is statically registered for one request kind and returns at most one response for the pending action.

Pitot reports. Your controller decides.

Different tools intervene at different points. Pitot sits at the one boundary every coding agent already exposes — the host hook — and keeps the agents your team already chose.

pitot init writes two substrate files: a one-line committed version pin, and a committed shim that hydrates exactly that release — sha256-verified — into a per-user cache and execs it. Fresh clones, CI, and cloud agents run .pitot/bin/pitot with zero setup.

.pitot/
├── version            # one semver line — the only version authority
├── bin/
│   ├── pitot          # committed shim (sh)
│   └── pitot.ps1      # committed shim (PowerShell)
└── conf.d/            # tenant fragments — see plate 05

Full walkthrough, CI story, and the fail-closed rules → Install & the repo-pinned shim.

pitot upgrade verifies the new release, re-checks every tenant fragment against it, and rewrites the one pin line — nothing else. Commit that diff and every clone hydrates the new version on its next invocation. Roll back by reverting it.

--- a/.pitot/version
+++ b/.pitot/version
-0.1.1
+0.1.2

What gets re-validated and how drift is surfaced → Upgrades as a reviewed diff.

Every tool or person that registers processes with Pitot owns exactly one fragment in .pitot/conf.d/, and no tenant ever edits another tenant's file. The effective configuration is the deterministic merge of all fragments in filename order.

Fragment anatomy, requires_protocol, and dir: → Tenant config & typed SDKs.

Typed SDKs install from our own registry through the distribution front door, pinned to the CLI's version. They are optional conveniences — the protocol truth is versioned JSON Schemas and newline-delimited JSON. If a program can read JSON Lines from standard input, it can be a Consumer.

# ordinary Python — reads projected events from stdin
import json, sys

for line in sys.stdin:
    event = json.loads(line)
    print(json.dumps({
        "host": event["host"]["name"],
        "action_id": event["action"]["id"],
        "kind": event["action"]["kind"],
    }), file=sys.stderr)

Once the boundary is open, the missing feature becomes ordinary code.