Multi-user conversations are generally available (GA)now on Elastic Cloud Serverless, and they arrive for Elastic Cloud Hosted (ECH) and Elastic Self-Managed in upcoming version 9.6. If you’re new to Agent Builder, get started with Introducing Elastic Agent Builder and the GA announcement.

Why share an Agent Builder conversation instead of a summary

A conversation with an agent accumulates context over time. By the tenth round, you’re finally asking the question that you had in mind all along.  Now owners can share conversations without preparing a summary or copying context. For example, consider a hospital shift change. The chart belongs to the patient and stays at the bedside, so the clinician who walks in at 7 a.m. reads the same history as the one who had been there earlier. No one copies the chart into a personal notebook and carries it home. We wanted conversations to work the same way. The thread belongs to the problem, and whoever picks up the problem next reads the same thread, resulting in a zero effort handoff.

On top of that, it’s a live handoff. Most AI chat products publish a conversation as a read-only snapshot behind a link, which is a copy that’s frozen at the moment you shared it. A shared conversation stays live. The recipient continues the same thread against the same custom or built-in agent, and the agent still has the history. Access comes from the Kibana privileges that the recipient already had, not from possession of a secret URL.

How SRE teams use AI for incident response in a shared conversation

Incident response is a compelling use case for live, shared conversations. Here are two ways that site reliability engineering (SRE) teams can put them to work.

How to hand off an incident at shift change

A Service Level Objective (SLO) burn rate alert pages the on-call SRE at 3 a.m. They open a conversation with an agent that has access to their application performance monitoring (APM) traces and log data streams. Over six rounds, they try to solve the problem. Then the SRE’s shift ends.

Instead of pasting a summary into the incident channel, they add the incoming on-call SRE as a member of the conversation and hand over the thread itself. The incoming SRE reads what has already been checked and then asks the next question; the agent still has the service name and the time window in context.

How several engineers work one incident in the same thread

Three engineers split the work:

• One person chases a deploy correlation

• Another looks at node-level memory pressure

• Still a third checks whether an upstream dependency's latency moved

Making the conversation public puts all three in the same thread against the same agent, and because every round shows its author, nobody reruns a query that a colleague ran two minutes ago. The thread becomes the shared scratch pad that an incident channel tries to be, except this one can query the data.

How Agent Builder conversation sharing and access control work

Every conversation is in one of two access modes, and the owner (the user who created it) chooses which:

• Restricted is the default and covers both the unshared case and the selectively shared one. Only the owner and the users listed as members can read the conversation or continue it. A new conversation is private with no members.

• Public makes the conversation readable and continuable by any user who can access the conversation's agent. Public conversations also show up in those users' conversation lists, so they’re discoverable rather than reachable only by someone pasting a URL. A public conversation cannot have a member list, because everyone who can use the agent already has access.

A conversation belongs to the Kibana space where it was created, and sharing doesn’t change that. Making a conversation public doesn’t make it visible from another space.

In addition, sharing a conversation grants access only to that one conversation. It doesn’t grant any privilege that the user didn’t already have. Agent access is checked every time that a conversation is read, and it even applies to the owner. If anyone loses access to a conversation's agent or if the agent is deleted, the conversation stops being readable for them and drops out of their conversation list. 

Members of a restricted conversation can read its full history and continue it by sending messages. The owner retains control over the conversation and its sharing settings.

Action

Owner

Member

Other users

Read and continue

Yes

Yes

Only if the conversation is public

Rename

Yes

No

No

Delete

Yes

No

No

Change sharing

Yes

No

No

How to share an Agent Builder conversation

How to share a conversation in the Kibana UI

To share a saved conversation, select the invite control in its header. From the sharing panel, the owner can choose an access mode and review current members. They can also find people to add. Only the owner can access the sharing controls. Members can view the participant list but cannot change access.

Who sent what, and how to leave a note for the team

Each message identifies its sender with the name and avatar of the person who sent it. Agent responses are labeled with the agent's identity, which keeps a thread legible when multiple people and an agent have all contributed. In addition, when authoring a chat message, you can ask for an agent response or just leave a note for the team.

How to share a conversation with the Kibana API

Sharing from the API is one request. PUT /api/agent_builder/conversations/{conversation_id}/access_control replaces the entire access control for a conversation, so send the state you want rather than a delta.

To share with two named users:

The same endpoint covers all three sharing states.

Goal

access_mode

entries

Share with named users (Restricted in the UI)

private

One {"type": "user", "id": "...", "role": "member"} object per person

Open to everyone who can use the agent (Public in the UI)

public

[]

Stop sharing entirely (Restricted, no members)

private

[]

Read the full specification and API limits in the documentation.

Getting started with Agent Builder conversation sharing

If you’re on Elastic Cloud Serverless, open any conversation you own in Agent Builder and look for the invite control in the header. On Elastic Stack, this arrives in 9.6. Conversation access control covers the access modes and how sharing composes with Kibana and Elasticsearch privileges, and the Kibana API reference has the request shapes. If you haven’t used Agent Builder yet, start a free trial and work through Get started with Agent Builder first.

Tell us what you want next from shared conversations.

The release and timing of any features or functionality described in this post remain at Elastic's sole discretion. Any features or functionality not currently available may not be delivered on time or at all.