Context

PR #3999 adds profile-scoped Honcho identity with shared workspace and cross-profile observability, building on #3681 (profiles) and #4037 (config isolation).

The follow-up is A2A: making Hermes profiles communicate as distinct runtime peers -- both structured delegation and autonomous peer-to-peer conversation -- while sharing context through Honcho's workspace model.

What #3999 already provides

What's missing for A2A

1. Cross-profile delegation (structured)

delegate_task currently spawns child AIAgent instances in the same process. It doesn't know about profiles. A profile "researcher" should be able to delegate to profile "coder" as a distinct peer.

Minimal change: extend delegate_task to accept a profile target. The child agent runs with the target profile's HERMES_HOME, config, SOUL.md, and Honcho peer identity. The parent and child share a workspace so Honcho context flows naturally.

delegate_task(
    task="refactor the auth module",
    profile="coder",
)

2. Autonomous agent-to-agent conversation (organic)

Profiles should be able to initiate and sustain open-ended conversations with each other without user mediation. Not task delegation -- actual peer dialogue where both agents have agency over the conversation.

Use cases:

• Two agents collaborating on a shared project (coder + researcher exploring an architecture)
• Agents discussing the user's context (building a richer shared model, like Cosmania's multi-agent discussions)
• Ambient agent-to-agent interaction (agents chatting for fun, discovering insights, serendipitous collaboration)
• Demo-ready: visible conversations in the Discord/Telegram/Matrix channel where the user can watch and intervene

Transport options (lightest first):

1. API server relay -- each profile already has an API server mode. One profile POSTs to another's endpoint. Lightest, process-isolated, already exists.
2. Shared platform channel -- both profiles in the same Discord/Telegram thread. User-visible by default. Agents see each other's messages as incoming gateway events.
3. Local message bus -- SQLite queue in shared HERMES_HOME. Background conversations the user doesn't see unless they check.

Conversation control:

• Max turn limit per conversation (prevent infinite loops)
• User can watch, interrupt, or join at any time
• Conversations are logged to Honcho (both peers writing to the shared workspace)
• Agent decides when to end the conversation (or hits the turn cap)

3. Inter-profile session model

When two profiles converse, what happens in Honcho?

• Both peers are in the same workspace (already true from feat(honcho): scope host and peer resolution to active Hermes profile #3999)
• Each peer's messages are attributed to the correct Honcho peer ID
• The user peer observes but doesn't participate (unless they join)
• Session naming: a2a-{initiator}-{target}-{topic_hash} or reuse existing per-directory session

4. Peer-to-peer context retrieval

A profile should be able to query what another profile knows. Already possible through Honcho's shared workspace -- hermes.coder can call dialectic_query targeting hermes.researcher's peer ID.

Minimal change: extend honcho_context tool to accept a --peer argument for targeting a specific profile's AI representation.

5. Addressing

Profiles are the canonical addressing model. hermes.coder is both the Honcho peer ID and the profile identifier. No separate registry needed -- hermes_cli.profiles.list_profiles() is the discovery mechanism, resolve_active_host() is the resolution mechanism.

Conversation visibility model

Scope

• Extend delegate_task to support cross-profile targets
• Add send_message target type profile:<name> for direct agent-to-agent messaging
• Define inter-profile session boundaries in Honcho
• Extend honcho_context for peer-to-peer context queries
• Add conversation turn limits and user intervention hooks
• Keep process-local for v1 (cross-network is a separate concern)

Open questions

1. Should cross-profile delegation use the same per-directory session or create dedicated delegation sessions?
2. Should the child agent inherit the parent's conversation history or start fresh with only the task description?
3. How should Honcho attribute messages in a multi-peer session (both AI peers writing to the same session)?
4. Should there be a hermes honcho ask <profile> <question> CLI shortcut for quick peer-to-peer queries?
5. For visible conversations: should agents auto-create a thread/topic in the platform, or use an existing channel?
6. What's the default turn limit for autonomous conversations? (Suggest: 10 turns, configurable)

Related

• feat(honcho): scope host and peer resolution to active Hermes profile #3999 -- profile-scoped Honcho identity + observability (foundation)
• feat: add profiles — run multiple isolated Hermes instances #3681 -- profiles (runtime isolation)
• fix(honcho): write config to instance-local path for profile isolation #4037 -- instance-local config write path
• Feature: A2A (Agent-to-Agent) Protocol Support — Remote Agent Discovery, Communication & Interoperability #514 -- A2A protocol support
• Feature Request: Remote Agent Connection / Multi-Instance Delegation #689 -- remote agent connection / multi-instance delegation
• feat: delegate_task ACP transport override — spawn ACP child agents from non-ACP parent #2653 -- delegate_task ACP transport override
• Cosmania -- reference implementation for multi-agent autonomous conversation

Suggested follow-up PRs

1. feat(a2a): cross-profile delegation with shared Honcho context
2. feat(a2a): autonomous agent-to-agent conversation via gateway channels
3. feat(honcho): peer-to-peer context queries across profiles