Version. 0.1
Date. 2026-05-05
Provenance. Claude.ai Discovery session. Operator: Marvin Percival.
Status. Investigation document. Follows and extends the personal memory investigation (v0.1).
Depends on. Recommendations from loomworks-personal-memory-and-proactive-companion-investigation-v0_1.md, all accepted.
The Companion crosses from tool to agent the moment it acts without being asked in that moment. A reactive Companion — user asks, system answers — is a UI layer. The person is the actor; the Companion is the instrument.
A proactive Companion — initiates reminders, observes behavior, extracts personal facts, decides when to speak, orders a car, sends a message — is an entity with agency. It makes judgments. It takes actions the person didn't request in that moment (even if they authorized the general capability). Those actions need attribution, authorization, and audit.
Three capabilities push the Companion over the threshold:
Proactive communication. Already accepted in the personal memory investigation. The Companion initiates — time-based reminders, event notifications, cross-project insights. This is agency over the person's attention.
Financial agency. "Should I order an Uber?" "Book Panya Thai." These require spending money on behalf of the person. This is agency over the person's resources.
Messaging. "Tell Sarah dinner is at 7:30." "Remind the team about the meeting." These require communicating on behalf of the person. This is agency over the person's relationships.
Each raises different questions. All three share one foundational question: what is the Companion's identity, and who authorized it to act?
DUNIN7's OVA protocol (provisional patent, March 2026) combines cryptographic indistinguishability, path-branching topology concealment, and zero-knowledge least-privilege verification. It was designed for exactly this problem: an AI agent that needs to prove it has authorization to act without revealing more about the authorizing person than necessary.
The Companion is the first natural consumer of OVA within the Loomworks ecosystem. Today the engine has agent contributor rows with bearer tokens (Phase 2). These are process-level agents that execute engine operations — shaping agents, render specialists. The Companion is fundamentally different: it acts on behalf of a specific person, in the world beyond the engine, with delegated authority that varies by capability.
Cryptographic identity. The Companion has an OVA identity that is cryptographically bound to the person who authorized it. When the Companion acts externally (makes a payment, sends a message), the receiving party can verify that a legitimate Companion is acting on behalf of a real person — without learning the person's identity beyond what the transaction requires.
Least-privilege verification. The Companion can prove it has permission to spend up to $50 without revealing the person's total balance. It can prove it's authorized to send messages on behalf of the person without revealing the person's contact list. Each capability is verified independently.
Path-branching concealment. External services cannot trace the Companion's actions across contexts. The Companion booking a restaurant and the same Companion ordering an Uber are unlinkable unless the person chooses to link them. This prevents the aggregation of activity profiles by external parties.
The Companion's OVA credential is issued by the person. It is:
Today's engine agents (shaping agents, render specialists) are system-level actors authenticated by bearer tokens. They operate within the engine on engine objects. The Companion is a person-level actor authenticated by OVA credentials. It operates both within the engine (reading engagement memory, orchestrating engine operations) and outside the engine (making payments, sending messages, querying external services).
The two agent models coexist:
| | Engine agents | The Companion |
|---|---|---|
| Identity | System-level bearer token | Person-scoped OVA credential |
| Scope | Engine operations within engagements | Engine operations + external actions |
| Authorization | Static (registered at creation) | Dynamic (person grants/revokes capabilities) |
| Attribution | ActorRef(kind="agent") | ActorRef(kind="companion", person_id=...) |
| Audit | Engine event log | Engine event log + OVA action log |
OVA integration is not a prerequisite for the Companion's reactive behavior (Arc 2's initial scope). OVA becomes necessary when the Companion acts externally — making payments, sending messages, querying third-party services on behalf of the person. This is late Arc 2 or a dedicated arc.
The seam: the Companion's ActorRef gains a kind="companion" value alongside the existing "person", "contributor", and "agent" values. This can ship immediately (it's a vocabulary addition). The OVA credential binding ships later, when external actions arrive.
Not all agency is equal. The Companion's capabilities fall into tiers based on the risk and reversibility of the action:
Tier 0 — Observe and inform. No action taken. The Companion notices something and tells the person. "Your reservation is in 4 hours." "The build finished." "A birthday is coming up." No permission needed beyond the person using Loomworks. This is the proactive behavior from the personal memory investigation — already accepted.
Tier 1 — Engine-internal actions. The Companion acts within the Loomworks engine on behalf of the person. Organizing notes, triggering a manifestation, initiating a shape. These are actions the person could take through the UI; the Companion does them proactively or conversationally. Authorization: implicit in the person's membership and designation on the engagement. No new permission model needed — the existing membership system governs what the Companion can do within the engine.
Tier 2 — Information retrieval from external services. The Companion queries external services: checking restaurant availability, looking up weather, searching for flights. No state changes in the external world. Authorization: the person connects external services (OAuth integrations). The Companion acts within the connected service's read permissions.
Tier 3 — Reversible external actions. The Companion makes a reservation, adds an event to a calendar, creates a draft message. These change state in the external world but are reversible — the reservation can be cancelled, the event deleted, the draft discarded. Authorization: per-service, explicitly granted by the person. Each action requires either pre-authorization ("you can book restaurants under $100 without asking") or per-action approval ("Book Panya Thai for 7:30? [Approve / Decline]").
Tier 4 — Financial transactions. The Companion spends money. Ordering an Uber, paying a restaurant deposit, purchasing tickets. Irreversible or costly to reverse. Authorization: explicit financial delegation with spending limits, per-transaction approval (until the person opts into pre-authorized categories), and audit trail.
Tier 5 — Communication on behalf of the person. The Companion sends messages as the person. "Tell Sarah dinner is at 7:30." "Email the team about the deadline." This is the highest-trust tier because it affects the person's relationships and reputation — a wrong message cannot be unsent. Authorization: explicit messaging delegation, per-message approval (at minimum initially), and clear attribution to the recipient that the message was sent via the person's Companion.
The person grants capabilities to the Companion through a delegation contract. The contract is:
The delegation contract lives in personal memory (the personal engagement from the prior investigation). It is a set of assertions: "I authorize my Companion to spend up to $50 per transaction via Stripe Link." "I authorize my Companion to send text messages to contacts in my Favorites group." These assertions carry provenance like any other — who authorized, when, under what conditions.
The Companion earns broader permissions over time. This is not automatic — the Companion doesn't silently gain capabilities. The escalation is conversational:
Stage 1 — Per-action approval. Every external action requires approval. "Book Panya Thai for 7:30? [Approve]." "Send Sarah: 'Dinner at 7:30 at Panya Thai'? [Approve]." This is the default for every new capability.
Stage 2 — Category pre-authorization. After enough approved actions, the Companion can suggest: "I've booked restaurants for you twelve times and you've approved every one. Would you like me to book directly next time, up to a $50 deposit?" The person grants standing authority for a category.
Stage 3 — Autonomous within bounds. The Companion acts within pre-authorized bounds without asking. Transactions are logged; the person reviews via the audit trail rather than approving each one. The Companion surfaces exceptions: "I booked your usual Thai place, but they only had 8:00 — is that okay?"
The person can regress to any stage at any time. "Actually, ask me before booking from now on."
Stripe's Link wallet for agents (announced April 30, 2026 at Stripe Sessions) provides exactly the infrastructure the Companion needs for financial agency:
| Stripe concept | Companion implementation | |---|---| | Agent OAuth flow | Person authorizes Companion in Loomworks settings → OAuth to Stripe Link | | Spend request | Companion creates spend request with Operator-vocabulary context | | Approval notification | Delivered through Loomworks proactive channel (SSE) + Stripe's native push | | One-time card | Received by Companion, used for the transaction, discarded | | Spending controls | Configurable in personal memory (delegation contract) | | Transaction log | Visible in Library or a new "Activity" surface in Operator vocabulary |
The Companion's OVA credential proves to Stripe that this agent is authorized by a specific person to spend within specific limits. Stripe's OAuth flow handles the payment-method authorization; OVA handles the agent-identity verification. The two are complementary:
This layered verification is stronger than either alone. A stolen OAuth token without the OVA credential cannot initiate transactions. An OVA credential without Stripe authorization has no payment method to use.
The user experience: "Order me an Uber to Panya Thai." The Companion checks the time, the location (from personal memory), the restaurant address (from the dinner engagement), calculates the ride time, creates a spend request via Stripe Link, and sends the approval notification. The person taps approve. The Companion books the ride.
No payment form. No app switching. No credential entry. The person asked; the Companion acted; the person approved.
Financial agency is late-stage work. Prerequisites:
This is Arc 2 late or a dedicated financial-agency arc.
The Companion sends communications on behalf of the person:
The hardest problem in Companion messaging is attribution. When Sarah receives "Dinner at 7:30 at Panya Thai," she needs to know:
Position: messages sent by the Companion are messages from the person. The Companion is their instrument. The recipient sees the person's name. The sending mechanism (Companion) is metadata, like "sent from iPhone" or "sent via Gmail."
The exception: if the Companion sends a message autonomously (without per-message approval), the attribution should indicate this. "Sent by Marvin's Companion" or "Automated reminder from Marvin." This protects the person — if the Companion sends something wrong, the person can point to the autonomous flag and say "I didn't write that."
Messaging requires:
When both parties are Loomworks users, messaging can stay within the platform:
This is the cleanest messaging path — no external services, no attribution ambiguity, full provenance within Loomworks.
Messaging is the highest-trust capability. Prerequisites:
Loomworks-internal messaging ships earlier — it's a natural extension of the Inbox and proactive notification system. External messaging ships later, with the full permission and attribution model.
Every action the Companion takes needs attribution that answers three questions:
The existing ActorRef model gains a new kind:
ActorRef(
kind="companion",
person_id=<the person's UUID>,
capability_ref=<the delegation contract assertion that authorized this action>,
approval_mode="explicit" | "pre_authorized"
)
This ActorRef appears on every event the Companion creates — engine events (assertions contributed, shapes triggered) and external action logs (payments made, messages sent).
Two audit surfaces:
Engine audit. Existing engine event log, FORAY-anchored. The Companion's engine actions (contributing assertions to personal memory, triggering engine operations on behalf of the person) are recorded here with the companion ActorRef. This uses existing infrastructure.
External action audit. A new log for actions taken outside the engine — payments, messages, external service queries. Each entry records: the action, the external service, the OVA credential used, the delegation contract reference, the approval mode, the timestamp, and the outcome. This log lives in the personal engagement (personal memory) and is FORAY-anchored.
The person can review both audit trails through the Library or a new "Activity" surface. In Operator vocabulary: "What has my Companion done?" → a chronological list of actions with context and authorization.
| Component | Change | When |
|---|---|---|
| ActorRef | New kind="companion" value | Early Arc 2 — lightweight |
| Personal engagement | Stores delegation contract assertions | Ships with personal memory (accepted) |
| /operator/converse | Companion can propose external actions with approval cards | Mid Arc 2 |
| SSE channel | Carries approval requests and action confirmations | Ships with proactive behavior (accepted) |
| OVA integration | Companion gets OVA credential bound to person | Late Arc 2 or dedicated arc |
| Stripe Link | OAuth integration for financial agency | Post-OVA |
| External messaging | SMS/email/WhatsApp sending infrastructure | Post-OVA |
| Audit surface | New "Activity" view in Operator vocabulary | Ships with first external action capability |
ActorRef(kind="companion") for attribution.FORAY (universal transaction grammar) was designed for exactly this class of problem: recording structured transactions with tamper-evident anchoring. The Companion's external actions — payments, messages, reservations — are transactions. Each action becomes a FORAY-anchored record: what happened, who authorized it, what the outcome was.
The Companion ordering an Uber produces a FORAY transaction that records: the person, the Companion (via OVA credential), the delegation contract reference, the Stripe payment (amount, one-time card, merchant), the ride details (pickup, destination, time), and the outcome. This is exactly what FORAY was built to hold.
DUNIN7's three protocols converge on the Companion:
The Companion is the first entity that uses all three protocols simultaneously. This is the architectural validation of the protocol family — they were designed to compose, and the Companion is where they compose.
The vacuum thesis says: as AI builders become radically more capable, the requirements specification layer is the single point of leverage. The Companion as agent extends this: as AI agents become capable of acting in the world, the authorization and memory layer is the single point of leverage.
Stripe provides payment rails. Twilio provides messaging rails. OpenTable provides reservation rails. These are commodities. What's not a commodity: the Companion that knows the person well enough to act correctly on their behalf, with authorization that's cryptographically verifiable, with memory that compounds over time, with an audit trail that's tamper-evident. That's the Loomworks position.
Option A: one OVA credential, presented to every external service. Simpler, but allows cross-service linkability. Option B: per-service OVA credentials derived from a root. More privacy-preserving (OVA's path-branching concealment) but more complex.
Leaning: Option B. OVA was designed for this. The Companion presents a service-specific credential to Stripe, a different one to Uber, a different one to the SMS gateway. No external party can link them.
Proactive reminders need to reach the person regardless. But should the Companion execute external actions (make payments, send messages) when the person is unavailable to approve? The pre-authorization model says yes — if the person has granted standing authority, the Companion acts within bounds. But a $50 restaurant booking at 2 AM when the person is asleep feels different from the same booking at 6 PM when they're active.
Leaning: Pre-authorized actions execute regardless of person's online status. The person reviews via the audit trail. But the Companion should prefer acting during the person's typical active hours unless time-sensitivity requires otherwise.
The Companion books the wrong restaurant. Sends the wrong message. Orders an Uber to the wrong address. Who is liable? The person authorized the action (via delegation). The Companion executed it (via engine judgment). The external service processed it (via Stripe/Uber/etc.).
Position: the Companion is the person's instrument. The person is responsible for the Companion's actions, the way they're responsible for an email they sent via Gmail. The person's recourse is: revoke the capability, dispute the transaction through normal channels (Stripe chargeback, message correction), and tighten the delegation contract.
If Marvin and James share an engagement, can Marvin's Companion send a message to James on Marvin's behalf? Yes — through Loomworks-internal messaging (§5.5), scoped by the engagement's membership. Marvin's Companion cannot message James outside of Loomworks unless Marvin has James in his personal contacts and has granted messaging delegation.
Stripe Link is the most mature agent-wallet infrastructure as of May 2026. But the Companion's financial agency should not be Stripe-exclusive. The external service connector framework (§7.3) is service-agnostic — Stripe is the first integration, not the only one. Future integrations: Apple Pay, Google Pay, bank-direct APIs, cryptocurrency wallets.
The Companion is not a legal person. It is a software agent acting on behalf of a natural person under delegated authority. The legal framework is the same as for any software acting on a person's behalf — the person is the principal, the Companion is the agent. This maps to existing agency law. OVA provides the cryptographic evidence chain that links agent actions to principal authorization.
This is not a question Loomworks needs to resolve — it's a question the legal system is resolving as agent commerce matures. Loomworks's job is to produce the cleanest possible authorization and audit trail, so that when legal questions arise, the evidence is unambiguous.
Building on the personal memory investigation's sequence (§7.2), the full Companion-as-agent sequence:
ActorRef(kind="companion") — vocabulary addition, immediate.Steps 1–8 are Arc 2. Steps 9–14 may be a dedicated "Companion Agency" arc.
The Companion becoming an agent is not a feature addition — it's an architectural commitment. It brings all three DUNIN7 protocols (Loom, FORAY, OVA) into their first convergent use. It positions Loomworks not just as a knowledge management environment but as the authorization and memory layer for a personal AI agent that acts in the world on the person's behalf.
The infrastructure is arriving. Stripe's agent wallet shipped five days ago. The pattern — OAuth authorization, per-action approval, spending controls, audit trails — is exactly what the Companion needs. OVA was designed for the identity layer that makes this trustworthy.
The sequence is clear: reactive Companion first (Arc 2 initial), personal memory second, proactive behavior third, external agency last. Each step builds on the previous. Nothing is skipped; nothing is assumed.
DUNIN7 — Done In Seven LLC — Miami, Florida The Companion as agent — Implications investigation — v0.1 — 2026-05-05