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.

Elastic is built to adapt to all kinds of data your systems emit: logs, metrics, traces, custom telemetry, and more. But when that data doesn’t match the expected shape due to a schema change, a misconfigured agent, or a rogue service emitting unexpected fields, it can fail to process and silently disappear.

That absence is a signal. But it’s also hard to detect, hard to debug, and hard to report on. And worse, it puts the burden on the client to figure out what happened.

That’s why we built failure store: a new way to capture, debug, and analyze failed events directly in the Elastic Stack. In this blog, we’ll go over Elastic’s failure store and explain how it provides visibility into data ingestion issues, helps debug schema changes, and enables teams to monitor data quality and pinpoint failure patterns.

About failure store

Failure store gives you visibility into failed events that were previously only visible to the client sending the data and to dead letter queues. It works by capturing and indexing failed documents into dedicated `::failures` indices that live in your data stream alongside your production data. You can enable it per data stream or across multiple data streams with a single cluster setting.

Why it matters

Teams are often downstream from the source of truth. They don’t write the code; they just keep it all running. When upstream teams ship changes that break mappings or introduce unexpected fields, failures happen. But without access to the original failed data itself, debugging becomes guesswork.

Even worse, when data fails to be indexed, it doesn’t exist in your indexes—which means it’s much harder to measure the impact. You can’t track which streams are failing most often. You can’t quantify how broken your pipelines are. And you certainly can’t alert on what’s missing if the platform never saw it (except for alerts when data goes missing).

The failure store allows a developer to understand which data failed indexing and why, giving observability engineers the tools needed to quickly understand and fix ingestion failures. Triage also happens quickly since failures are stored in Elasticsearch, with no need to gather information from remote clients or shippers.

Get started

Set up for new data streams…

…or enable for existing data streams

Enable failure store for individual data streams in stack management in Kibana or leverage the _data_stream API:

Enable failure store via cluster setting

If you have a large number of existing data streams, you may want to enable their failure stores in one place. Instead of updating each of their options individually, set data_streams.failure_store.enabled to a list of index patterns in the cluster settings. Any data streams that match one of these patterns will operate with their failure store enabled.

A failing document response

After enabling the failure store, requests that previously would fail are now processed differently. The client now receives a 201 created instead of a 400 Bad Request. Especially if you’re using custom applications or our language clients, make sure to update your code accordingly. When a document goes to the failure store, the response will contain the failure_store: used attribute.

Search and filter failure data just like any other logs, with support for ES|QL and Kibana tools:

Data in the failure store comes with all the context to make debugging simple. Each ::failures index contains information about which pipeline failed, along with specific error messages, stack traces, and error types that help you identify patterns.

Are you getting lots of errors and aren't sure where to start? Use ES|QL and ML functions. With the data exposed in ES|QL, errors can be analyzed with ML capabilities such as CATEGORIZE to help parse errors and extract patterns. Read more about data remediation techniques in our documentation.

Control costs and retention using the same data stream lifecycle you're already using for your other data. Absent a custom retention, failure store data will stick around for 30 days.

Monitor data quality over time with failure metrics and sortable dashboards by failure percentage to find new problem areas that require investigation. Read more about data quality monitoring in the documentation.

Learn more

Failure store is available starting in Elastic 9.1 and 8.19 and will be enabled by default on logs-*-* indexes in an upcoming release. To learn more, check the documentation for setup instructions and best practices.