What Happened
Elastic Agent Builder now supports live shared conversations on Elastic Cloud Serverless. Authorized teammates can read a thread’s history and continue questioning the same agent, rather than receiving a static transcript. Elastic describes incident-response handoffs as one use case. Support for Elastic Cloud Hosted and Self-Managed is planned for version 9.6, but timing is not guaranteed [1].
An owner can share a conversation with named members or make it available to anyone who can use its agent. Access is limited to that conversation, stays within its Kibana space, and still depends on Kibana and Elasticsearch privileges [1].
Why It Matters to Businesses
For retrieval-augmented generation (RAG), a shared thread carries more than a final answer: it preserves questions, retrieved context surfaced in responses, and the reasoning path a teammate needs to resume work. That can reduce handoff friction, but it also makes conversation history an access-control concern. Permission to use an agent should not be mistaken for permission to see every conversation with that agent. Elastic’s per-conversation controls address that distinction [1].
This is a collaboration capability, not a new vector-search technique. Teams using LlamaIndex, LangChain, Haystack, or search backends such as Weaviate, Pinecone, Qdrant, Milvus, Elasticsearch, or Vespa still need to design retrieval quality and document authorization separately.
Kimbodo Engineering Perspective
We would treat a shared RAG conversation as a durable business record, not an informal chat link. The practical trade-off is continuity versus exposure: keeping full history helps the next responder, while every retrieved excerpt or user-supplied secret in that history increases what a newly added member may see.
Conversation access and retrieval access are different controls. A user may be allowed into a thread while a subsequent question retrieves documents under a different permission state. The application should enforce document-level authorization at retrieval time and define how it handles historical content when membership or source-document permissions change.
How We Would Implement It
- Keep ingestion, indexing, and retrieval behind an authorization-aware service. Apply tenant and document permissions before passing search results to the model; do not rely on prompts to filter restricted material.
- Store conversation ownership, membership, space, and sharing state explicitly. Default sensitive workflows to named-member access, and require an intentional action to make a thread available to all agent users.
- Before sharing, show the owner the full thread and warn that earlier answers may contain retrieved excerpts or sensitive user input. Add retention and deletion rules appropriate to the workflow.
- If integrating Elastic’s API, read the intended membership before updating it: PUT /api/agent_builder/conversations/{conversation_id}/access_control replaces the entire access-control state. Named sharing uses private with member entries; public with empty entries opens access; private with empty entries stops sharing [1].
- Test handoffs with multiple roles: confirm who can open the thread, what history they can see, and which documents each new query can retrieve.
Risks, Costs and Security
The main failure mode is oversharing accumulated context, especially when a thread moves from named members to everyone who can use the agent. Replacing the whole access-control state also creates an operational risk if an integration submits an incomplete member list [1]. Review changes before applying them and test concurrent administrative workflows.
Long-lived threads add storage, retention, and review obligations; repeated follow-up queries also incur retrieval and model costs. Budget for those costs alongside search-index costs, and verify platform availability before committing to a deployment outside Elastic Cloud Serverless [1].
Where Kimbodo Comes In
Kimbodo builds and operates this in production for businesses — see our RAG Development Services practice, or Estimate My RAG System.
