[RFC] Collaboration Context Extension for Cross-Org Agent Interactions

[lbeaumois]

RFC: SLIM Collaboration Context Extension

Repository: agntcy/slim-spec
Type: Feature Request / Specification Extension
Author: Laurent Beaumois (MeetLoyd — AGNTCY Supporter)

---

Summary

Propose a Collaboration Context extension to SLIM that enables bounded, lifecycle-managed collaboration spaces for cross-organizational agent interactions. Today SLIM provides the secure messaging pipe between agents across orgs. This extension adds a thin coordination layer so that platforms can scope, track, and govern those interactions without prescribing how governance is implemented.

Motivation

The Gap

SLIM currently enables Agent A (Org X) to communicate securely with Agent B (Org Y) via SPIFFE identity, MLS encryption, and access control. What SLIM does not define is the concept that a group of agents from multiple organizations are collaborating within a bounded engagement — with a shared lifecycle, scoped membership, and observable boundaries.

In practice, cross-org agent collaboration doesn't happen in isolation. It happens in context:

• An SI firm deploys a team of agents to work alongside a customer's agents on a transformation project
• A supply chain partner's procurement agents collaborate with a manufacturer's inventory agents for a specific contract period
• A legal firm's review agents work with a client's compliance agents during an M&A due diligence window

Each of these has a start, an end, defined participants, and boundaries. Without a protocol-level abstraction for this, every platform must invent its own — leading to fragmentation and interoperability gaps at exactly the layer where cross-org coordination matters most.

Why This Belongs in SLIM (Not Application Layer)

SLIM already handles the hardest parts: identity, encryption, and transport. But when two platforms exchange SLIM messages on behalf of a cross-org engagement, they currently have no standard way to:

1. Agree on a shared context — "these messages belong to Project X"
2. Scope membership — "only these agents from our org participate"
3. Signal lifecycle — "this collaboration is active / suspended / closed"
4. Carry context metadata — opaque fields that platforms can use for their own governance

Without this, SLIM messages are individually secure but collectively unstructured. The Collaboration Context makes cross-org interactions first-class at the protocol level — the same way SLIM Groups made multicast first-class.

Proposal

1. Collaboration Context Identifier

A unique, URI-style identifier scoping a set of cross-org SLIM interactions:

slim-context://{initiator-org}/{context-id}

Example: slim-context://acme-corp/deal-review-2026-q1

The initiator org owns the context namespace. The context ID is opaque to SLIM — platforms assign it however they choose.

2. Lifecycle

A Collaboration Context has a minimal lifecycle managed via SLIM control messages:

State	Description
proposed	Initiator proposes context; invited orgs have not yet accepted
active	At least one invited org has accepted; messages can flow
suspended	Temporarily paused (e.g., pending re-authorization); messages queued or rejected
closed	Permanently ended; no further messages accepted

State transitions are initiated by the context owner (initiator org). Participating orgs can leave at any time (unilateral) but cannot change the context state.

3. Membership Manifest

Each participating org declares which of its agents participate in a given context:

ContextMembership {
  context_id:    string          // slim-context:// URI
  organization:  string          // SLIM organization identifier
  agents:        AgentRef[]      // List of participating agents
  accepted_at:   timestamp       // When this org joined
  metadata:      bytes           // Opaque — platform-specific (see §5)
}

Membership is declared per-org. Each org controls its own membership list. SLIM does not dictate how orgs decide which agents participate — that's an application/platform concern.

4. Context Header in SLIM Messages

Messages sent within a Collaboration Context carry a header field:

SlimContextHeader {
  context_id:    string          // slim-context:// URI
  sequence:      uint64          // Monotonic per-context, per-sender
  metadata:      bytes           // Opaque per-message metadata
}

This is a SLIM message extension, not a replacement for existing headers. Platforms that don't use Collaboration Contexts ignore it. Platforms that do can route, filter, and log messages by context.

The sequence field enables receivers to detect gaps and ordering within a context, supporting audit and replay use cases without SLIM itself providing those capabilities.

5. Opaque Metadata Slots

Both the Membership Manifest and the Context Header include an opaque metadata field (bytes). SLIM does not interpret these — they exist so that platforms can carry their own governance, policy, or compliance data alongside SLIM messages without protocol changes.

Examples of what platforms might put here (not specified by SLIM):

• Policy identifiers
• Classification labels
• Retention tags
• Authorization references

This keeps the spec thin while enabling rich platform-level governance.

6. Observability Hooks

SLIM SHOULD emit OpenTelemetry-compatible events for Collaboration Context lifecycle transitions:

• slim.context.proposed
• slim.context.active
• slim.context.suspended
• slim.context.closed
• slim.context.member.joined
• slim.context.member.left

These integrate with AGNTCY's existing Observability and Evaluation components, enabling platforms to build audit trails, dashboards, and compliance reports on top of standard telemetry.

What This Proposal Does NOT Define

To keep the spec at the pipe level, the following are explicitly out of scope and left to platforms:

• Permission models — how orgs decide which agents can join a context
• Approval flows — whether human authorization is required and how it works
• Governance policies — what rules apply within a context
• Trust hierarchies — how trust is graduated between internal and external contexts
• UI/UX — how collaboration contexts are presented to users
• Billing/metering — how cross-org interactions are accounted for

Relationship to Existing SLIM Concepts

SLIM Concept	Relationship
Groups	A Collaboration Context MAY use SLIM Groups for its multicast. The Context provides lifecycle and membership; Groups provide the transport.
Sessions	Sessions operate within a Context. Multiple sessions can belong to one Context.
Authentication	Context membership is verified via existing SLIM/SPIFFE identity. No new auth mechanism needed.
Access Control	Existing SLIM access control applies. Context membership is an additional scoping layer, not a replacement.

Use Cases

SI Firm + Enterprise Customer

A consulting firm (Org A) deploys 5 AI agents to work with a customer's (Org B) 3 agents on a digital transformation. The Collaboration Context scopes this engagement: only these 8 agents can exchange messages within it, the customer initiated it, and when the project ends, the context is closed and no further messages flow.

Supply Chain Collaboration

A manufacturer (Org A) and supplier (Org B) create a Collaboration Context for quarterly procurement. Agents negotiate orders, confirm deliveries, and reconcile invoices within the context. At quarter end, the context closes. Next quarter, a new context opens — potentially with different agents.

M&A Due Diligence

A acquiring company (Org A) and a target company's legal advisors (Org B) establish a Collaboration Context for due diligence review. Org A's compliance agents and Org B's legal review agents exchange analysis within a tightly scoped context. The context metadata carries classification labels both platforms use for their own data handling. When the deal closes (or collapses), the context is closed — creating a clean, auditable boundary around every cross-org interaction that occurred during the engagement. Both platforms can independently verify the interaction boundaries via observability events.

Implementation Considerations

• Backward compatible: Platforms that don't implement Collaboration Contexts continue to work — the context header is optional
• Minimal state: SLIM nodes need only track active context IDs and their membership; lifecycle state is lightweight
• No new transport: Uses existing SLIM messaging; context is metadata, not a new channel
• Aligns with SLIM Groups: Could be implemented as a managed layer on top of SLIM Group creation/teardown

Prior Art

• SLIM Groups: Established the pattern of managed agent collections with lifecycle
• OAuth 2.0 Scopes: Bounded authorization contexts for API interactions
• XMPP MUC (Multi-User Chat): Room-based collaboration with membership and lifecycle
• Kubernetes Namespaces: Bounded resource scoping with metadata and RBAC integration

Next Steps

1. Gather feedback from AGNTCY community on the concept and scope
2. If there's interest, formalize as a section in the SLIM specification draft
3. Prototype implementation using existing SLIM Groups as the transport layer
4. Validate with at least two independent platform implementations

---

This proposal is contributed by MeetLoyd (meetloyd.com), an AGNTCY supporter building an enterprise AI governance platform with production SLIM integration for cross-organizational agent collaboration.

[Tehsmash]

Hi @lbeaumois! Thanks for the proposal its really interesting. One thing that I'm trying to understand is where the gap is in the existing group communication semantics. Mapping the proposal the existing group logic I can see:

• a "context" could be a new group channel. Members (and only the members required) are invited to that channel by the channel moderator. No need for special routing, each agent will receive an invite from the moderator and receive the messages.
• Lifecycle is managed by the moderator and if they close the channel then the "context" is closed.

What I do see missing is an inter-org bootstrap / rendezvous channel, so that orgs can come together to initiate a new context channel, and that may require messages following a similar schema to your proposal.

[lbeaumois]

Thanks @Tehsmash - this is really helpful and exactly the kind of feedback I was hoping for.

You're right that SLIM Groups cover most of the runtime semantics I described. A context channel with a moderator managing membership and lifecycle maps well. I think the proposal was over-specifying what Groups already handle - so that's useful calibration.
Where I think the real gap is - and you nailed it - is the inter-org bootstrap / rendezvous. In the use cases we're building for (SI firm + enterprise customer, M&A due diligence, etc.), the hardest part isn't the messaging once the channel exists. It's the negotiation that happens before:

1/ Discovery: Org A knows it wants to collaborate with Org B, but how do they find each other's SLIM endpoints and agent capabilities? (This may overlap with Agent Directory + the ai-card work.)
2/ Proposal: Org A proposes a collaboration: "we want to create a channel with these agents for this purpose." How is that proposal expressed and delivered?
3/ Acceptance: Org B reviews the proposal, decides which of its agents will participate, and accepts. What does this handshake look like on the wire?
4/ Channel creation: Once both sides agree, the moderator creates the Group channel with the agreed membership.

After step 4, existing SLIM Group semantics handle everything.

The opaque metadata slots from my original proposal could still be useful in the rendezvous messages - letting platforms carry their own policy/governance data during the bootstrap without SLIM interpreting it.
Would it make sense to narrow this RFC to focus specifically on the rendezvous protocol? Happy to revise the proposal if that's a more useful contribution.