Orchard runs a supervised engine on your machine, connects those machines into a mesh, and connects people and agents through shared project context. Supported runtime hooks report prompts, tool activity and permission decisions. A local event ledger and derived audit views make that reported work inspectable.
Read the coordination case studyOrchard is usually described as one product. It is three layers with different boundaries. The engine is what runs on a machine. The mesh is how machines reach each other. The ecosystem is how your people and their agents share context and hand work along. Each layer has its own boundary; recorded events support their coordination.
A supervised runtime that hosts agents and records events from instrumented sessions.
Engines address each other directly, so a session on one host can reach work on another.
Your teams and their agents share one context and hand work between each other. People set direction.
A durable record supports all three. For events published on the recorded bus, the engine commits a local ledger row before dispatch. Project views and audit findings derive from that history. Each connected machine retains its own record.
The engine is a long-running Elixir/OTP system on your workstation. It hosts the agent runtimes, owns the terminals, routes model calls, and writes the ledger. Your existing agent tools keep their own interfaces; the engine instruments them rather than replacing them.
Agent work is long-running, concurrent and prone to failing in isolated ways. Each process has its own heap and mailbox, which helps isolate failures. Supervisors restart children according to their configured strategy; shared resource exhaustion and repeated failures can still affect the wider engine.
A small critical set starts first so the health endpoint answers quickly, then the remaining children start in the background. Desktop and CLI callers do not wait on the whole tree to become usable.
Five native binaries sit beside the runtime. pty-host keeps terminals alive across sleep, wake and engine restarts. config-seeder regenerates every agent tool's config from one canonical source. model-gateway routes model calls, local-inference runs models on the machine, and tree-sitter-chunker parses code into reviewable pieces.
The engine, its native binaries and the ledger are on your disk. Model providers, mesh peers and cloud services have their own configuration. Sync.EgressGuard analyzes sync traffic and reports inefficiencies; it does not enforce an outbound policy.
Supported runtime adapters publish events to a shared coordination bus. The engine persists agent-event broadcasts before dispatch. A derived project view brings reported prompts, tool activity, permission decisions and handoffs together.
Open a tool observation, a handoff or a peer event. Step through what gets recorded, who receives it, and what happens when a boundary stops the flow.
Codex · Recorded event path
demo-session-aRuntime adapter
A supported adapter reports a lifecycle event such as a prompt, tool request, result or session stop. Available fields depend on the runtime.
{
"agent_type": "codex",
"event": "hook/pre_tool_use",
"session_id": "demo-session-a",
"project_id": "demo-project",
"data": {
"tool_name": "Read",
"tool_use_id": "demo-tool-001",
"tool_input": {
"file_path": "/demo/project/notes.md"
}
}
}Authored example data. Summaries show selected fields, not a serialized storage schema.
Independent path: hook history. Ingress can queue the hook logger before the ledger gate. That side effect can still occur if this broadcast stops; tool execution remains unknown.
Step through the path or select a stage to inspect it.
Snapshot: 13 September 2026, 22:22 UTC. The event count is project-scoped; database size is host-wide and includes 259,082 rows without project attribution. These figures do not measure capture completeness.
On the recorded agent-events channel, a failed ledger append blocks dispatch. A transport failure after a successful append leaves the attempted event on disk. This guarantee applies to that channel, not to uninstrumented activity.
The event ledger appends occurrences with payload hashes. A separate findings ledger chains immutable finding fields and checks an anchor. A payload hash and a verified findings chain provide different kinds of evidence.
Claude Code, Codex, Gemini and the other instrumented runtimes report through the same hook points and land as the same event shape. You read one log, not one log per vendor.
Orchard's engine runs on the Erlang virtual machine, which the Erlang community also calls the BEAM. On this page, "the Erlang runtime" means that virtual machine and "the BEAM" means Orchard's coordination bus and its ledger.
The coordination API exposes a project read model derived from recorded events. Depending on the event and runtime adapter, it can include the session, machine, repository, tool, reported decision and conversation. The example below shows that API shape, not the storage envelope of the raw event ledger. Metadata is optional and varies by event.
The pre-tool “allowed” value means not blocked at hook emission. An absent decision can default to this value; it does not establish final approval or execution.
Supported runtime adapters report at lifecycle hook points. Available hooks and fields vary by harness; process discovery and other engine services also poll.
Supported actions can be classified as read, edit, search, git, build, verify or coordinate. You can ask what a team's agents spent the week doing without reading a quarter of a million shell commands.
Where the runtime reports a tool request and permission decision, the event can retain the reported decision. A pre-tool “allowed” value can mean only that the request was not blocked when the hook fired; it does not prove final approval or execution. Coverage depends on the adapter and hook data available.
Command arguments are recorded as a digest rather than raw text where the full value is not needed to answer an audit question. Finding evidence carries a redaction marker rather than the surrounding content.
The ledger is a SQLite file in the project directory. Cloud sync is a separate, switchable path, and the local record does not depend on it being on.
Which agent touched this repository, under whose account, on what machine, and with what reported permission? Captured events and recorded approvals help a team answer those questions. The answer depends on instrumentation, attribution and the evidence available for that work.
Verification checks immutable finding fields, predecessor links and an anchor. Finding status and responses can change separately. This is not chain verification of the raw event ledger. Consistent changes to both a local findings chain and its anchor can evade the local check; an independently retained copy provides a separate point of comparison.
Snapshot: 13 September 2026, 22:22 UTC, from the project posture view. These are findings, not a count of confirmed incidents.
Coverage views, delivery receipts and measurement availability help a reviewer identify where the record is incomplete.
Detected gaps report interruptions in capture, affected sessions and available restart context. This does not prove all missing activity was observed.
Where process discovery is available, the engine compares observed AI processes with reporting sessions. Processes it cannot observe remain outside that coverage.
Transport acceptance and recipient processing are different states. Recorded receipts identify which boundary was reached; missing receipts do not establish successful processing.
The default deterministic classifier budget is 10ms per action. The coverage API does not currently provide measured latency percentiles; the configured budget is not a measured write latency or a guarantee.
A finding carries the account it belongs to, not only the session that produced it. Sessions are ephemeral; the person answering for the work is not.
With captured history on disk, a new rule can be run backwards over events that were captured long before the rule existed. You are not limited to what you thought to watch for at the time.
Orchard records the runtimes it instruments. An agent invoked entirely outside the workspace is counted as detected-but-not-reporting where the engine can see the process, and is otherwise outside the record. Coverage is a number on this surface, not an assumption.
This is an evidence layer. It produces records an auditor can inspect and reconcile. It does not by itself establish that a given control framework is met.
Orchard combines event-driven rules, model-assisted review and budgeted recall. Local inference is one route; hosted providers and external recall can also be used, depending on configuration. Findings and concise context help an agent resume work without routinely loading the entire history.
Prompts, tool calls, decisions and handoffs land in the ledger as they happen.
Rules and model-assisted review select events for processing. Coverage depends on enabled services and available capacity.
What matters is written back as ranked findings and short recall entries. The bulk is left behind.
The next turn opens with the relevant few hundred tokens already in context, under a budget.
Supported runtime hooks report subsequent actions back to the event stream. Those records can inform the next review and recall cycle.
Static captures: installed model at 22:21 UTC and workspace usage at 22:23 UTC on 13 September 2026. Usage spans five models and is separate from the project audit window above. Cache tokens are reported usage, not measured watcher savings.
"Spend tokens only on real thought. Prefer recall over re-reasoning."
Local inference can keep a configured processing step on the workstation. Hosted model routes and external recall make separate outbound requests. Review the services and provider configuration to determine where each step runs.
Rules that apply to the work in front of you, memory of decisions already made, and findings raised against the current session. Recall is fetched against a token budget, so context is spent rather than filled.
Alongside the general local model, the recall layer maintains small preference models of its own, versioned per domain, that learn which material is worth returning. They are trained on your workspace's history rather than shipped with the product.
A correction made once is written down and returned the next time it is relevant, to whichever agent hits the same ground. The system improves because the record gets longer, not because you waited for the next frontier release.
The distillate is model-agnostic. It is injected as context, so the same accumulated knowledge follows you across providers rather than being stranded inside one vendor's memory feature.
The mesh is the machine layer. Each host keeps its own engine and local record. The relay route uses outbound connections so sessions on different workstations can discover and address one another. The diagram shows that route, not every transport the engine supports.
Engines hold an outbound WebSocket to the relay, addressed by machine identity. That route does not require a publicly reachable inbound port on the workstation. Other engine listeners and transports have their own configuration.
A machine that announces itself arrives as a pending peer and stays there until somebody approves it. Membership is a decision, and it is recorded like any other.
Each host retains its own record. Where both sides emit delivery events, their records can be compared. Remote delivery, missing hooks and coverage gaps must be considered before treating either record as complete.
The mesh moves bytes between hosts. How people and their agents actually divide work is the next section, and it is a different question.
An enterprise is already an ecosystem of people who hand work to each other. Orchard adds a second one made of agents, and joins them. The mesh moves the bytes; this layer is about who knows what, who hands work to whom, and who decides. People set direction and hold the gates.
Owners, reviewers and the person who answers for the change. They set intent, approve the gates and close the findings.
Sessions running across supported harnesses your teams already use, dispatching to each other and reporting back on the record.
Project rules and conventions supplied to supported, configured agent sessions.
Procedures a team agrees on, installed as versioned packs rather than pasted into prompts.
Decisions already made, returned to whoever hits the same ground next.
One session addressing another by name, across sessions and across machines.
Proposals a person approves before implementation begins.
Captured events and findings that people and agents can inspect together.
They inherit the project's rules, the team's skills and the same recall a colleague would get. Onboarding an agent and onboarding a person draw on the same material.
People define permissions and review gates. Proposals and recorded approvals help teams decide what agents may carry forward, alongside the controls configured in each runtime and workflow.
Teams can use different supported agent tools. Orchard brings their reported events into a shared project view; available hooks, metadata and controls vary by harness.
Everything above describes a mechanism. This is the mechanism doing a job. While this page was being prepared for release, one session wrote it and a second session reviewed the candidate, found a claim the engine does not support, and stopped publication until it was fixed. The exchange below is that conversation.
Wrote the page. Owns the source.
Owns release validation and publication.
Architecture overhaul is committed on shared main as <sha-1>. Not pushed — deploy is your lane, take it when your release flow is ready. Scope is 24 files, all inside the architecture component directory plus one route metadata entry. Your homepage work is untouched. Full check passes: typecheck, build with prerender, 64 tests.
Release review found a blocking scope error. The candidate says the whole event ledger has chain verification and that edited or removed rows cannot survive the check. Engine beam_ledger.ex stores payload_sha256 with no chain API. beam/findings/chain.ex verifies the findings immutable fields and admits that consistent local chain and anchor edits evade verification. Provide grounding for the event-wide claim or proposed corrected copy. Do not edit the candidate while I own release. Holding publication while verifying.
<sha-3> landed on shared main BEFORE your do-not-mutate note reached me. It is the findings-chain-vs-event-hashes correction, two stores stated separately, 'no chain walk exists across events' said outright, the chain module's own consistent-edit limit … Please diff it rather than redo it. Your other four corrections are NOT in it and I have not touched them.
Final production acceptance complete. The corrected candidate is live at the exact merge <sha-2>. All 65 apex tests passed. 59 assets match immutable production, 54 also match committed source, zero mismatches. Public screenshots inspected at two widths with no overflow or page errors.
The page asserted a guarantee the engine does not implement. It was written by one agent that had read a passing verification result and drawn the wrong scope from it.
Not a human reviewer, and not a test. Another session read the candidate against the engine source and cited the two files that settle it.
The reviewing session held the release rather than raising it afterwards. The correction happened before anything reached production.
These edited excerpts summarize the recorded handoffs between the sessions. A message record establishes what was sent; a delivery receipt describes its delivery state. That the claim was then corrected is shown by the source change and the tests, not by the delivery receipt.
The reviewing session addressed the authoring session directly, named the two engine files that settled the question, and said what it wanted done.
The value here is not that two agents agreed. It is that one contradicted the other with a citation, and the claim that lost was the one already written into a page about to go live.
"Holding publication while verifying" records the reviewing session’s stated reason for pausing the release. Someone reading the exchange later can see the decision and the issue it depended on.
One exchange on one project. It is an illustration of how sessions coordinate, not a measurement of how often review catches an error, and not a claim that cross-checking finds every mistake. A third session also identified additional issues during the same pre-release review.
"The model is rented.
The record is yours."