Why the Elasticsearch Platform is the missing piece in your AI stack

Enterprise AI has a dirty secret: The model is the easy part. The hard part is everything around it — memory, retrieval, state management, and the connective tissue that turns a chatbot into something people actually rely on at work.

Most teams solve this by bolting together a vector database for embeddings, a document store for context, a cache layer for sessions, and maybe a time-series database for telemetry. That's four systems to operate, four failure modes to debug, four vendor contracts to manage, and four integration seams where data silently gets lost or stale.

Our team at Elastic has now shipped two AI systems that use the Elasticsearch Platform as the sole data backend: ElasticGPT, an internal chatbot with 2,000+ users, 125,000+ chats, and 400,000+ interactions, and AgentEngine, an API-driven autonomous agent framework. The bet we made on our tech stack was the same each time: one engine for memory, retrieval, and state. No Redis. No Pinecone. No Postgres sidecar. Just the Elasticsearch Platform.

AgentEngine’s backend is built on top of the Elasticsearch Platform with four distinct memory functions. Each one would traditionally require a separate system.

• Episodic memory: Session-scoped conversation history stored as a data stream with index lifecycle management (ILM). Recent turns live on fast storage, compress after 30 days, and auto-delete after 90 — no cron jobs and no manual retention scripting. This replaces a session store like Redis.

• Semantic memory: Long-term facts extracted and distilled across conversations each scored by importance. The agent accumulates knowledge over time and a background consolidation process merges related facts using local embeddings. This replaces a dedicated vector database.

• Procedural memory: Records of which tools the agent used, for what task type, whether it succeeded, and any correction notes. This gives the agent a learning loop; when facing a similar task next time, it recalls what worked. This replaces an analytics or logging system with structured querying.

• Workflow state: Serialized execution snapshots from PydanticAI's graph API. When the agent hits a checkpoint, the full graph state persists to Elasticsearch. Users disconnect and reconnect; the agent resumes from the exact step. This replaces a state backend like Postgres or DynamoDB.

Consolidating your search and AI data into a single platform is a strategic advantage that reduces total cost of ownership (TCO) and accelerates time-to-market.

Most teams I've talked to who are evaluating vector databases are solving the wrong problem. They're asking "which vector database should we use for embeddings?" when the real question is "do we even need a separate vector database?"

Keyword search misses context (e.g., failing to link "ETL crash" with "pipeline failure") while pure AI search often misses exact critical details like product codes. A unified platform runs both simultaneously. It automatically weighs and surfaces the most relevant, up-to-date information so that your AI always has the right context.

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.

In this blog post, we may have used or referred to third party generative AI tools, which are owned and operated by their respective owners. Elastic does not have any control over the third party tools and we have no responsibility or liability for their content, operation or use, nor for any loss or damage that may arise from your use of such tools. Please exercise caution when using AI tools with personal, sensitive or confidential information. Any data you submit may be used for AI training or other purposes. There is no guarantee that information you provide will be kept secure or confidential. You should familiarize yourself with the privacy practices and terms of use of any generative AI tools prior to use. 

Elastic, Elasticsearch, and associated marks are trademarks, logos or registered trademarks of elasticsearch B.V. in the United States and other countries. All other company and product names are trademarks, logos or registered trademarks of their respective owners.