[RFC] Agent Contacts: cross-owner A2A conversations + decision inbox

The issue names no files or existing tests. Start by reviewing the existing human review cards, Spaces and revision-aware content, per-Dot permissions, persistent work state, and AG-UI surfaces. Define the local contact/revocation model, disclosure card, fixture peer, durable inbox/outbox states, and restart plus duplicate-submit tests before connecting a live A2A peer.

Problem

I’d like OpenDots to support a simple cross-owner workflow:

“Ask my friend’s agent for a shareable update, let the agents handle bounded clarification, and only interrupt us when a human decision is required.”

This is different from same-workspace multi-agent orchestration. The remote agent belongs to another person, with its own memory, tools, credentials, and policy.

Full downstream design: https://github.com/kvnloo/OpenDots/issues/13

Product shape: Agent Contacts

A contact would represent an owner-confirmed remote agent endpoint.

Initial flow:

1. Pair — both owners manually confirm the endpoint over an existing trusted channel.
2. Propose — from a Dot conversation, stage a request to that contact.
3. Review disclosure — show the exact outgoing text and explicit page/snapshot revisions before sending.
4. Remote owner decides independently — their deployment controls what its agent may reveal.
5. Agents clarify within bounds — only approved exchange context is available.
6. Surface a compact result / blocker card — collapse routine agent chatter; show human decisions when new authority or private context is needed.
7. Revoke — immediately prevent future local dispatch/continuation.

Initial scope: one-to-one, text-only, read-only exchanges. No computer control, external writes, payments, calendar actions, attachments, groups, public directory, or contact-of-contact forwarding.

Important architecture boundary

OpenDots should implement this independently. It should not require Hermes as a backend.

The app would own its own:

• contacts registry
• owner-authenticated pairing/revocation
• peer authentication/policy
• durable inbox/outbox
• disclosure decisions
• restricted exchange runner
• delivery/result UI

Hermes can be one compatible contact, not the control plane.

The companion Hermes implementation is separately proposed as a standalone plugin:
https://github.com/kvnloo/hermes-agent/issues/426

Reuse existing OpenDots / CopilotKit surfaces

OpenDots already has several pieces that fit this UX:

• human review cards
• Spaces / revision-aware content
• persistent work state
• per-Dot permissions
• AG-UI rendering
• explicit computer controls

CopilotKit/AG-UI also has A2A middleware support, so I’d evaluate that rather than inventing another agent transport. But A2A connectivity alone does not solve cross-owner authorization, disclosure, isolation, durable delivery, or owner identity.

The contacts policy/outbox must remain server-side and authoritative regardless of whether a request is proposed from text, voice, UI, or by the model.

Security invariants

OpenDots’ current security doc correctly describes the prototype as single-owner. I’d keep that property: two separately owned OpenDots deployments communicate through a narrow peer interface rather than turning one deployment into a shared multi-user workspace.

For the first implementation:

• pairing grants communication, not Space/computer access
• remote display names are not verified human identity
• initial outgoing text is itself a disclosure requiring review
• approvals bind to recipient + exact content/snapshot revision + expiry/policy epoch
• the peer runner sees only approved snapshots + exchange transcript
• no normal thread history, Automatic Learning, browser, shell, computer tools, arbitrary URL fetching, or further delegation
• remote messages are untrusted data, never authority or UI actions
• peer task/history operations are ownership-checked
• delivery state, agent state, and owner-decision state remain distinct
• revocation blocks future local work but does not claim to erase already delivered data

First mergeable slice

I would avoid starting with a full social/contact network.

The first vertical slice could be:

• local contact + revocation model
• owner-only control API
• one disclosure decision card
• deterministic fixture peer / no live model dependency
• durable inbox/outbox state
• narrow-screen + keyboard-accessible UI
• clear states for queued / dispatched / peer accepted / reply received / unknown / expired / failed
• restart + duplicate-submit tests

Then connect a real A2A peer once the policy and state machine are proven.

Interop contract

The Hermes and OpenDots tracks can share only a small versioned behavior contract / fixture set:

• exchange request
• approved shared-context snapshot
• local decision record
• delivery/result receipt

Each runtime keeps its own storage, policy, UI, and release cadence.

The useful test matrix is:

• OpenDots ↔ OpenDots works with Hermes absent
• Hermes ↔ Hermes works with OpenDots absent
• OpenDots ↔ Hermes matches the same observable fixtures
• generic A2A peers either get an explicitly approved manual exchange or a clear incompatibility; no silent downgrade to unrestricted behavior

Credit / provenance

This proposal is intended to compose with existing work, not overwrite it.

• @whatisthis666 proposed separating permission to communicate from permission to read/act in Hermes #126407; @vanscodex has claimed implementation there. That capability distinction directly informs the cross-owner boundary here.
• @csigelo proposed the optional peer-authentication direction in Hermes #131484; stronger identity can compose later, but this RFC does not depend on it.
• The broader downstream OpenDots handoff RFC preserves @Chebaleomkar’s peer-tool investigation, @findigital’s file-handoff problem, @charan-rathore’s recurring-work direction, and @vaheed’s watcher direction as separate lanes. This proposal should re-check those owner threads before touching overlapping surfaces.
• Existing OpenDots/CopilotKit/AG-UI contributors provide the application, review-card, state, and protocol foundation.

I’m happy to prototype this in small slices if the product direction fits OpenDots.

Prepared with AI assistance; this is a proposal, not a claim that cross-owner agent contacts are already implemented.