feat: Agent harness integration — SLIM daemon client, channel discovery, and A2A bridging

[Tehsmash]

Overview

This issue proposes a set of capabilities to make SLIM a first-class transport layer for autonomous agents. The goal is to define the components and workflow an agent needs to: discover SLIM infrastructure via the Agntcy ai-catalog/directory, join channels, exchange messages with other participants, and bridge those messages into agent-native protocols (e.g. A2A).

---

Motivation

Agents operating in multi-agent environments need a secure, low-latency way to:

• Find and connect to shared communication channels
• Receive invitations and queue messages asynchronously
• Route messages to other agents using their preferred protocol

Right now SLIM has strong primitives (channels, sessions, SLIMRPC) but no cohesive story for how a standalone agent process bootstraps into this ecosystem and uses it as a persistent background transport.

---

Proposed Flow

1. Agent is configured with:
   - Address of its local SLIM node
   - Address of the Agntcy ai-catalog/directory

2. Agent starts the SLIM client daemon under a chosen identity
   (certificate / JWT / shared secret — whatever auth the node requires)

3. Agent queries ai-catalog to locate a channel-manager service

4. Agent (via daemon) sends a SLIMRPC message to the channel-manager:
   - List available channels

5. Agent picks a channel and requests an invitation

6. Channel-manager sends an invite; the daemon:
   - Accepts the session automatically, OR
   - Queues the invite for explicit acceptance
   - Notifies the agent (signal / callback / IPC event)

7. Daemon joins the channel and begins receiving messages:
   - Messages are queued locally
   - Agent is notified of new messages

8. Agent acts on messages:
   - Reads them directly from the daemon queue
   - OR pipes a sub-client (e.g. A2A CLI) to the channel to consume/produce messages
   - OR uses the channel as a transport to deliver A2A messages to a specific named participant

9. Agent can also use ai-catalog to find other individual agents and send them
   direct SLIM messages (e.g. "please request an invite to channel X")

---

Key Gap: SLIM Client Daemon

The most important missing piece is a SLIM client daemon — a long-lived background process that an agent can start to maintain a persistent SLIM identity and connection.

Responsibilities

Capability	Description
Identity management	Start with a given identity (cert/token) and maintain it across reconnects
Session handling	Accept or queue incoming session invitations; notify the agent
Channel subscription	Subscribe to one or more channels and buffer inbound messages
Outbound messaging	Accept send requests from local clients via IPC (socket/pipe/stdin)
Sub-client bridging	Expose a local endpoint that protocol adapters (A2A, HTTP, etc.) can connect to
Offline queuing	Buffer messages so agents can process them at their own pace

Interface options (to be decided)

• Unix domain socket / named pipe — allows any local process to connect as a sub-client
• Local HTTP/gRPC endpoint — language-agnostic; easy to integrate from Python/Go/JS agents
• stdin/stdout pipe — simplest for CLI-driven agents
• Event callback / signal — notify parent process when a new message or invite arrives

---

Related Components

Channel Manager CLI

Extend (or create) a CLI that an agent can invoke to:

• channel-manager list — list channels exposed by a discovered channel-manager
• channel-manager invite <channel> <identity> — request or send an invite
• channel-manager participants <channel> — list current channel members

A2A ↔ SLIM Bridge

Allow an A2A client to use a SLIM channel as its transport:

• SLIM channel carries A2A task envelopes as payloads
• A2A CLI can address a specific participant in a channel by their SLIM name/identity
• Inbound A2A tasks arrive via the daemon queue and are dispatched to the agent's A2A handler

ai-catalog Integration

Standardise the catalog record schema so agents can query for:

• Channel managers (type: slim/channel-manager, endpoint: slimrpc://...)
• Individual agents (type: agent, slim-identity: ...)

---

Open Questions

1. Daemon lifecycle — should this be a standalone binary (slim-daemon) or a sub-command of slimctl?
2. IPC protocol — which local interface is the right default for broad language support?
3. Invite policy — auto-accept vs. explicit; should policy be per-channel or global?
4. Message ordering / delivery guarantees — does the queue need sequence numbers? replay?
5. Identity portability — can an agent export/import its SLIM identity so it survives restarts?
6. ai-catalog schema — what fields are required for SLIM-capable services?

---

Acceptance Criteria (initial scope)

• slim-daemon (or slimctl daemon) binary that maintains a persistent SLIM connection
• Daemon exposes a local IPC endpoint for message send/receive
• Daemon accepts session invites and queues them; notifies via configurable mechanism
• CLI commands to list channels and request invites against a channel-manager
• Basic A2A-over-SLIM example demonstrating end-to-end agent message exchange
• ai-catalog record schema documented for SLIM channel-manager services

[micpapal]

For point 4 " Agent (via daemon) sends a SLIMRPC message to the channel-manager" we need to expose an A2A server in the channel-manager. This morning I was saying that we can access the info using slim but I was wrong, we can query the channel manager only using the grcp interface. It was in my todo list but I didn't do it yet. In addition we may need to add also a DB to persist all the info about the channels stored in the channel-manager.

Regarding the CLI all the commands are already in slimctl using slimctl channel-manager. We just need to see if we want to improve them. At the moment we have list channels, list channel participants, add/rm channel, add/rm participant to channel.

For the invitation acceptance/allow policy we need to think about something. At the moment the invite is handled at the session layer and the invite is always accepted. We need to see if we need to enforce the policy in the session layer and so add new config to slim, or let the application on top decide to keep the channel or drop it.

The slim daemon looks a lot like an additional abstraction of the current bindings. Do you want a minimal application that can be used by cluade/copilot? Otherwise I am not sure I see much value in this extra layer.

[Tehsmash]

For point 4 " Agent (via daemon) sends a SLIMRPC message to the channel-manager" we need to expose an A2A server in the channel-manager. This morning I was saying that we can access the info using slim but I was wrong, we can query the channel manager only using the grcp interface. It was in my todo list but I didn't do it yet. In addition we may need to add also a DB to persist all the info about the channels stored in the channel-manager.

Do we want to do it via A2A or do we want to do it directly with SLIMRPC, or maybe both?? If we directly expose it through SLIMRPC then we can just compile the proto into SLIMRPC?

For the invitation acceptance/allow policy we need to think about something. At the moment the invite is handled at the session layer and the invite is always accepted. We need to see if we need to enforce the policy in the session layer and so add new config to slim, or let the application on top decide to keep the channel or drop it.

There are two parts I was thinking about, there is:

1. the channel manager accepting the request to invite an Agent to a channel: this could be a policy thing or human in the loop
2. the Agent accepting an invitation to talk or join a channel: this could be exposed through the daemon CLI as a human in the loop style thing.

The slim daemon looks a lot like an additional abstraction of the current bindings. Do you want a minimal application that can be used by cluade/copilot? Otherwise I am not sure I see much value in this extra layer.

Its exactly a wrapper around the bindings, its to enable harnesses which do not have direct code level integration to use SLIM as a client, its basically a CLI version of the bindings. But once we have it and we can expose channels as like a unix socket or something then we can build the other clients like A2A.

[micpapal]

Do we want to do it via A2A or do we want to do it directly with SLIMRPC, or maybe both?? If we directly expose it through SLIMRPC then we can just compile the proto into SLIMRPC?

SLIMRPC will be faster yes, we just need to compile the same protobuf file. I didn't think about it.

[Tehsmash]

Session State Persistence — Handling Ephemeral Membership

A key gap identified: channel membership is ephemeral — if an agent goes offline it leaves the channel and must rejoin. One solution is to persist the MLS session state so it can be restored on reconnect.

The flow below covers the happy path (state still in sync) and the recovery path (state has drifted, moderator re-keys the group):

flowchart TD
    A([Agent joins channel]) --> B[Persist identity + MLS state to disk]
    B --> C([Agent restarts / comes back online])
    C --> D[Agent CLI loads identity + state from disk]
    D --> E["slim_binding.session_from_state(state)"]
    E --> F{MLS state\nin sync?}
    F -- Yes --> G([Proceed — agent is active in channel])
    F -- No --> H[Moderator re-keys everyone]
    H --> I([Proceed — agent is active in channel])

Loading

Implications

• The SLIM client daemon needs a state store (file or DB) to persist identity credentials and MLS group state across restarts.
• On reconnect the daemon calls session_from_state to attempt to restore membership without a full re-invite flow.
• If the epoch has advanced while the agent was offline the group moderator (channel-manager) detects the mismatch and triggers a group re-key so all members share a fresh epoch.
• This makes channel membership durable rather than ephemeral — an agent can survive process restarts, host reboots, or network partitions without losing its place in a channel.

Open questions added by this

• What format / location should the state store use? (single encrypted file, SQLite, keychain?)
• Who owns the moderator role — always the channel-manager, or can it be any participant?
• How long should stale/offline members be tolerated before the moderator forces a re-key?