How it works
The govern loop
The architecture is unusual: Machinaut hosts the read side, while you keep the writer and the keys. So the highest-leverage thing to learn is the loop — where each piece runs and how a governed action actually flows.
The loop in one breath
Your agent runs Lodestar inside your environment → it records every step as a verifiable chain and holds risky actions → it ships a copy of that log to Machinaut → your team governs it: approve held actions, audit across every session, prove what happened.
The two planes
Lodestar OSS runs in your environment (the data plane); Machinaut is the control plane. They meet at exactly two arrows.
Your environment
Data plane · Lodestar OSS · you run this
- Guard proxy → kernel → adapters
- Event-log writer
- Approver keys (Ed25519)
- Local approval side-channel
Machinaut cloud
Control plane · we run this
- Ingest → tenant store → indexed search
- Chain report · explorer
- Approval inbox · audit
- Fleet · governance
- Your environment (Lodestar OSS, never hosted by Machinaut). Lodestar wraps your agent, records what it does, and holds risky actions until they’re approved and signed. Your approver keys live here and nowhere else.
- Machinaut cloud (the control plane). It receives shipped logs, verifies and indexes them, and gives a whole team the explorer, the approval inbox, the audit log, and fleet views.
- The arrows are the contract. Logs ship up as recorded events; a signed approval decision comes back down as untrusted transport, verified in your environment. Machinaut is on the transport path, never the trust anchor — see the trust boundary.
There is no live tail. Sessions ship batch-wise (finished, or an in-progress snapshot). “Freshness” is a cheap re-ship — the ingest contract dedupes, so re-shipping a session that grew is free.
The three verbs
Everything Machinaut adds over the local viewer resolves to one of three:
Approve
A risky action (say, a push to main) hits an allow / deny / hold gate in the policy kernel and holds. The customer-side relay announces the hold to Machinaut; it lands in the approval inbox. An approver — someone other than the agent’s author — opens the shipped chain, reads the reasoning that led to the action, and returns a signed Approve or Deny. That resolution is verified in your environment against your pinned keys; only then does the action proceed. A hold that’s never resolved simply times out to a deny — the safe default.
Audit
Every shipped session is searchable across the whole tenant — every project, every teammate, not one operator’s loopback. On top of the sessions themselves, an org-scoped audit log records the governance actions (who approved what, who changed a role) and exports to CSV / NDJSON. This is the “across the fleet” view the local, single-operator viewer structurally can’t give.
Prove
Because the chain is tamper-evident (payload-hashed at the source) and approvals are signed, the record is evidence, not just a log. Share a session as a post-mortem — “here is exactly why my agent did X, and here is the signature that approved it.” The signature verifies independently of Machinaut, which is the whole point: proof you can hand to an auditor, a customer, or a teammate.
A worked example — one held action, end to end
Approve, audit, and prove are one flow, not three features. Watch a single action move through it:
- 1
Hold
Your agent, mid-task, tries to
git push origin main. Lodestar’s kernel gates it — the action is high-risk — and returns hold. The push pauses in your environment; nothing has happened tomainyet. - 2
Announce
The customer-side relay announces the hold to Machinaut, ceiling-gated so the action’s sensitive inputs never leave your environment. It appears in your team’s approval inbox.
- 3
Approve
A teammate — not the agent’s author — opens the shipped chain, reads the observations → … → decision that led to the push, and taps Approve on their phone. The decision is signed with approver keys that never left your environment.
- 4
Verify + proceed
The signed decision travels back down as untrusted transport. Your proxy verifies the signature locally against pinned keys. It checks out — only now does the push proceed. (Had the approver denied, or never answered, the push would not run: a hold times out to a deny.)
- 5
Prove, later
An auditor asks “who approved that deploy, and why?” The audit log names the approver, the chain shows the reasoning, and the signature proves the approval — all verifiable independently of Machinaut.
That is the whole product in one action: a second signer (approve), a standing cross-session record (audit), and evidence that holds up outside our cloud (prove).
The six-stage chain
Every shipped session projects to the same six-stage chain — the spine of every explorer view. Reading it top to bottom is reading the agent’s reasoning, from raw input to governed action.
| # | Stage | What it is |
|---|---|---|
| 1 | Observations | What the agent took in — tool results, files, messages. |
| 2 | Claims | Assertions the agent derived from those observations. |
| 3 | Evidence | What supports or contradicts each claim. |
| 4 | Beliefs | The agent’s calibrated confidence, given the evidence. |
| 5 | Decisions | The choices it made from those beliefs. |
| 6 | Actions | The effects on the world — the governed, approvable steps. |
The chain projection itself is Lodestar OSS — Machinaut renders it, it does not recompute it. What Machinaut adds is that this chain is now hosted, searchable across your fleet, shareable, and wired to the approval write-path.
Where the terms come from