Outcome
Operators can interact with AURA from the collaboration tools where operational work already happens, without needing to switch to a dedicated AURA client or depend on one-off integration code for each surface.
A conversation started from Slack, Teams, Google Chat, or another supported adapter behaves like an AURA interaction: the user can start work, continue the conversation, observe what AURA is doing, and provide input when needed.
Problem
AURA currently has protocol-specific ways to interact with agents, but no consistent integration boundary for user-facing communication surfaces.
A2A is intended for agent-to-agent communication. SSE and the web server are designed around AURA's existing clients. External collaboration tools therefore require their own translation and lifecycle plumbing.
That creates two problems:
- Every new surface risks becoming a bespoke integration with its own assumptions about input, output, conversation history, streaming, lifecycle, and agent control.
- Capabilities added to one integration do not automatically become available to the next.
The product should not require a separate Slack-shaped architecture, Teams-shaped architecture, [...], and Google Chat-shaped architecture.
Scope
This epic establishes the reusable boundary for connecting AURA to external user-facing surfaces and provides real integrations.
Adapter contract
Define a consistent way for an adapter to:
- provide a consistent internal encode interface for attaching AURA frontends (Slack, A2A, Completions, OpenAI, etc.) to AURA agent actors.
- the webserver layer just becomes a translation proxy between frontends and agent actor threads.
- subscribe to AURA agent event streams
- communicate whether a human is present and able to interact;
- deliver follow-up input or steering to an active AURA interaction;
- represent capabilities or limitations of the underlying surface without leaking protocol-specific behavior into the agent runtime.
- The contract should allow future adapters to be implemented without changing AURA's core agent behavior for each new protocol.
First-class collaboration surfaces
Initial target surfaces include:
- Slack (Customer identified)
- Microsoft Teams (Customer identified)
- Google Chat (Customer identified)
Slack is the first implementation and should establish the reusable pattern for the others.
Open vs. Commercial
| Capability |
OSS AURA |
Commercial Mezmo |
Notes |
| Adapter API / protocol |
✅ |
Consumes |
This is part of AURA's core runtime contract. Both self-hosted and managed integrations need the same stable way to send input, receive events, map sessions, and steer running work. |
| BYO Slack via Socket Mode |
✅ |
|
Slack Socket Mode uses an outbound connection from AURA to Slack, so the customer can run AURA privately without exposing a public endpoint. |
| Self-hosted Google Chat |
✅ |
|
Google Chat can call a customer-managed HTTPS endpoint, including infrastructure the customer operates outside Mezmo. No Mezmo-hosted relay is required. |
| Community / custom adapters |
✅ |
|
Custom adapters only require the public adapter contract and can run wherever the customer chooses. |
| Slack Marketplace app |
|
✅ |
Slack Marketplace distribution cannot use Socket Mode. A Marketplace app needs stable public HTTPS service endpoint, which makes a managed ingress layer necessary. |
| Microsoft Teams agent / app |
|
✅ |
Teams requires a stable public HTTPS service endpoint, which makes a managed ingress layer necessary. |
| Managed Google Chat app |
|
✅ |
A turnkey Marketplace installation needs a stable public HTTPS service endpoint, which makes a managed ingress layer necessary. |
| Mezmo-hosted public ingress |
|
✅ |
This exists specifically to receive traffic from SaaS collaboration platforms and bridge it to customer AURA deployments that are not publicly reachable. |
| Fleet and admin controls |
|
✅ |
Centralized visibility and administration become necessary when Mezmo operates integrations across many AURA deployments. A standalone OSS instance does not require fleet-level control. |
Extensibility
This epic does not need to deliver a general plugin marketplace or fully dynamic bring-your-own-plugin system, but it should avoid architectural choices that require integrations to be compiled directly into AURA's core runtime.
Outcome
Operators can interact with AURA from the collaboration tools where operational work already happens, without needing to switch to a dedicated AURA client or depend on one-off integration code for each surface.
A conversation started from Slack, Teams, Google Chat, or another supported adapter behaves like an AURA interaction: the user can start work, continue the conversation, observe what AURA is doing, and provide input when needed.
Problem
AURA currently has protocol-specific ways to interact with agents, but no consistent integration boundary for user-facing communication surfaces.
A2A is intended for agent-to-agent communication. SSE and the web server are designed around AURA's existing clients. External collaboration tools therefore require their own translation and lifecycle plumbing.
That creates two problems:
The product should not require a separate Slack-shaped architecture, Teams-shaped architecture, [...], and Google Chat-shaped architecture.
Scope
This epic establishes the reusable boundary for connecting AURA to external user-facing surfaces and provides real integrations.
Adapter contract
Define a consistent way for an adapter to:
First-class collaboration surfaces
Initial target surfaces include:
Slack is the first implementation and should establish the reusable pattern for the others.
Open vs. Commercial
Extensibility
This epic does not need to deliver a general plugin marketplace or fully dynamic bring-your-own-plugin system, but it should avoid architectural choices that require integrations to be compiled directly into AURA's core runtime.