Version. 0.1 Date. 2026-06-09 Status. Standing note. Records an architectural thread from Companion design discussion: FORAY's governing role over agent behavior, and where agent oversight sits. Captured for when agent behavior and oversight become real build concerns. Operator-facing. Recorded, not committed — the buildable position is stated; the parked question is flagged. Relates to. The Companion architecture foundation note v0.1 (the driver axis — agent binding); OVA (agent identity/authorization); FORAY (transaction grammar / ledger); the gated multi-Operator boundary. Author posture. Discovery — the correction and the trajectory are preserved alongside the conclusion, so a later reader can see how the position was reached.
FORAY is the accountability half of the agent-trust model. OVA authorizes an agent to act; FORAY records what it did, with provenance, so that behaviour outside the granted authority is visible and attributable. Because agents are bound to a specific Operator and act under that Operator's delegation, the FORAY events an agent generates are that Operator's — already partitioned by Operator, already attributable. There is no Loomworks-wide stream of anonymous agent activity needing a privileged watcher. Agent oversight is therefore self-contained per Operator: "is my agent staying within the delegation I granted it?" is answerable entirely within that Operator's own world. Cross-boundary oversight arises only in shared, multi-party engagements — which are gated — so it is a future concern, not a present one.
The trust model for an agent acting as a Companion has two halves:
Together: OVA prevents the unauthorized; FORAY makes the authorized auditable and makes deviation visible. FORAY does not stop an action — that is OVA's job at the API. FORAY makes misbehaviour detectable and attributable after the fact, and patterns of it visible over time. This extends a role FORAY already plays (e.g. tune_setting writes a FORAY audit row on every change); it is not a new mechanism.
This sits cleanly under the founding axiom (Engine elevated, Companion/agent subordinate; the Engine knows a caller's identity, authorized reach, and the nature of each action). FORAY is how "the nature of each action" becomes recorded and provenanced.
The position first considered, and set aside: dedicated oversight agents — purpose-built watchers, close to or in the Engine — that observe all activity across the system and report suspicious or non-permitted behaviour, like a platform security-operations layer.
Why it was set aside: a watcher that sees all activity is, by construction, the most over-privileged caller in the system — the single largest least-privilege violation, and the very thing OVA's least-privilege ethos exists to prevent. It also creates a quis custodiet problem: who authorizes the watcher, and what governs its behaviour? Building oversight as a privileged cross-cutting caller introduces a new trust hole rather than closing one.
The correction that dissolved the problem: agents are Operator-bound. An agent always acts on behalf of a specific Operator, carrying that Operator's authority through a delegation contract; the Companion identity is bound to the person (id = person UUID). Therefore the FORAY events an agent generates are that Operator's — in that Operator's engagements, attributable to that Operator's delegated agent, scoped to that Operator's world. There is no Loomworks-wide activity stream for single-Operator work; the activity is already partitioned by Operator and already attributable, by construction.
Where it lands: oversight collapses to the right scale. "Is my agent behaving — staying within the delegation I granted?" is answerable entirely inside the Operator's own boundary, against the Operator's own FORAY trail and delegation contracts. No cross-Operator visibility is required; no privileged watcher exists; least-privilege is intact, because the oversight is the Operator (or a function within the Operator's own authorized reach) examining the Operator's own agents' own trail. The quis custodiet problem evaporates — there is no watcher with cross-cutting reach, only each Operator's bounded, self-auditable world.
The category error named: the privileged-watcher framing imports a multi-tenant security-operations model (one operator polices everyone) that is wrong for Loomworks, where the architecture is Operator-bound all the way down. The FORAY trail is not a shared firehose; it is per-Operator, by the same logic that makes the personal register private. Agent oversight lives in the personal register (your agents, your trail, your bounds), not the universal register (see-across-everyone).
A small set of things are genuinely Loomworks-wide and not Operator-bound; the universal register (E####, shared/multi-party engagements, the substrate) exists for them. If two Operators ever share an engagement (the gated multi-Operator future), an agent acting in that shared engagement generates FORAY events touching more than one Operator's world — and there, oversight does cross a boundary, because the engagement itself does.
So the cross-boundary oversight question is real but confined to exactly the multi-party case that is already gated. It rides the same boundary as multi-Operator work and is parked with it. The open question, when that gate is approached: who is authorized to see across the boundary enough to detect misbehaviour in a shared engagement, and what governs that authority? That is a FORAY-governance question larger than the Companion spec, to be taken up with the multi-Operator decision.
For the single-Operator world that is buildable now, the question does not arise: everything is Operator-identifiable, nothing is Loomworks-wide, oversight is self-contained.