Managing context depends on good retrieval. Rather than have agents rediscover the same content for every question, burning tokens by retracing similar steps over and over again, Elastic’s agentic AI capabilities enable us to precompute these details and store them in a structured, searchable form, and they let agents load that context directly. We call this precomputed unit of context a Knowledge Indicator.

The default agentic retrieval augmented generation (RAG) pattern does the opposite. It retrieves whole documents and dumps them into the model's context at query time, paying for that retrieval in tokens and latency on every single question. Precomputing the answer as a KI moves that cost out of the hot path and does it once.

How it works: AI Index, Kibana Workflows, and the query-ki skill

Building context through AI indices has three main parts: the AI Index (a special Elasticsearch index where KIs live), Kibana Workflows to create your KIs, and a query-ki skill to help agents directly query KIs using ES|QL: 

This blog post is similar to Part 1 in that we’re using the same core building blocks. But in this post, we’re demonstrating a very different use case. Instead of precomputing index metadata, we’re distilling specific facts from our indexed documents that may be used to directly answer agents’ questions without subsequent searches. We've also provided a notebook, if you'd like to create the same KIs yourself, end to end, as you go through these examples. 

Prerequisites: Elasticsearch Serverless and an LLM API key

This tutorial assumes you have:

1. An Elasticsearch Serverless project. You can sign up for a trial if you don't have one.

2. An API key to access your Elasticsearch project.

3. An OpenAI-compatible large language model (LLM) API key, to access AI indices via Deep Agents scripts.

Load the BrowseComp-Plus sample corpus into Elasticsearch

First, we’ll need some sources. Sources can be data that already exists in your Elasticsearch indices or external data accessed via connectors or ES|QL data sources.  For this blog, we’ll create an index, browsecomp-plus, to hold our example data, with the following mappings:

and populate it with a small sample of BrowseComp-Plus data via the _bulk API. You can use the supporting notebook to load a sample of this data in your project. 

Create the AI Index that stores your KIs

Just like in Part 1, the first step is to create an AI Index:

This is preconfigured with the same required mappings as we listed out in Part 1. We perform hybrid search here using semantic_text out of the box.

How agents retrieve KIs using ES|QL

A KI is a document in the AI Index. What makes KIs useful is retrieval, or querying the AI Index to find the right content. This query is packaged within a small, portable skill that’s harness-agnostic and can be run in any agent harness. 

Here’s a sample query-ki skill:

Save this asskills/query-ki/SKILL.md.

Here’s what this skill is doing: 

• We’re defining corpus_entry as our KI use case.

• We’re performing a hybrid ES|QL search on our AI indices, filtering by the appropriate type, using reciprocal rank fusion (RRF) as the default method to fuse results.

• The KI results will directly ground the agent’s answer when determining what facts are relevant to the users’ query.

When we say that AI indices and KIs are harness-agnostic, it’s because the skill is just instructions plus a query. It will work in Elastic Agent Builder, a Kibana workflow agent, Claude Code, or any other harness. We’ll be using Deep Agents for examples of how to query it outside the Kibana ecosystem. Since an AI Index is, at its core, an Elasticsearch index, you can also explore your data directly. 

Precompute facts as KIs for agentic RAG

In this example, we extract actual facts so agents can retrieve an answer without consuming a full document. We generate one fact-based KI per selected document, though the actual number and structure of KIs you generate are completely customizable.

We'll use a sample of the BrowseComp-Plus corpus, indexed into a browsecomp-plus index, with docid, url, title, and text fields.

Baseline: Retrieving whole documents with RRF

As a baseline, here's a simple RRF query:

This drops several hundred words of raw body text into the model's context. It may work, but it's expensive, and the cost compounds with every miss.

Build the Kibana workflow

The workflow below reads a batch of documents with a single ES|QL query and writes one fact-level KI per document into the AI Index. Each iteration runs two steps: generate_ki distills a raw document into a structured KI, and sink_ki writes it to the AI Index keyed on docid so reruns are idempotent.

Copy and paste the following YAML into the Elastic Workflows editor:

Here’s what this workflow is doing: 

• query_corpus runs an ES|QL query against the browsecomp-plus index, applying some rules, like dropping documents with empty bodies and trimming each body to 12,000 chars so the agent prompt stays inside the context window.

• Note: In this example, we’re cherry-picking some concrete KI IDs, because generating KIs for every document in the index would take a long time, and we want this exercise to be short for those following along.

• loop_corpus_docs iterates over every returned document, running the following two steps per document: 

• generate_ki reads the document and calls an LLM to emit a strictly grounded, structured KI.

• sink_ki bulk-writes each KI into the AI Index (ai-index-idx-my-corpus) as a KI of type corpus_entry. It forces _id to be the same as the document’s docid so rerunning the workflow is idempotent.

To summarize, this workflow turns each raw corpus document into a compact, searchable metadata record that agents can find and judge without reading the full source into the context window.

This workflow is used for example purposes, and the same foreach caveat as in Part 1 applies. For scale, use workflow.executeAsync or native parallel support. The cheat sheet is useful for optimizing Workflows. There could also be cost and efficiency gains in production by using ai.prompt or by choosing different models with which to create KIs. 

Inspect the KIs in your AI Index

Once the workflow runs, you can query the AI Index to browse what was written:

Here’s an example of what one of the KI documents looks like: 

Query KIs from LangChain Deep Agents

We’ll use LangChain Deep Agents with an OpenAI-compatible key to show that AI indices and KIs will work with any agent harness, inside and outside of Kibana’s Agent Builder ecosystem. 

First, let’s create facts_baseline_agent.py to measure our baseline before applying KIs: 

When I ran this baseline query, What was the actress who played Torvi from Vikings also known for?, it output the following:

(Note: Deep Agents automatically adds the read_file tool to handle paginated tool results, which is why it shows up in the output.) 

Next, let’s create an agent that knows how to use our query-ki skill, facts_ki_agent.py: 

This agent will query the KI indices to generate the answer, rather than pulling every document into context. 

When I ran these results against the same query, here was the output: 

How much can precomputing facts reduce agent token usage?

Both agents had similar conclusions, but they took far different paths to get there: 

The same question and the same grounded answer result in 93% fewer tokens and two tool calls instead of eight, when answering from KIs.

Baseline (No AI Index)

With AI Index

Total tool calls

8

2

read_file calls

2

1

esql_query calls

6, all against the browsecomp-plus index

1, from ai-index-idx-*

Tokens consumed

386,187

27,625

Latency

44.86s

15.22s

Answer

Grounded, correct

Grounded, correct

Exact tool call counts, latency, and answers will vary between runs and using different agents. 

Both agents produced solid, grounded answers. The difference is cost. Querying KIs from the AI Index cut token use by 93% and cut latency by roughly two thirds. Here’s how both paths went, side by side:

That was in-depth, but it shows what AI indices and Workflows do together: the same answer, at a fraction of the tokens.

Build precomputed context in Elasticsearch Serverless

This walkthrough shows how to generate more sophisticated KIs based on documented facts and query them for knowledge retrieval use cases using Elasticsearch primitives. 

Managing context is critical in agentic search systems. And at its core, context is a retrieval problem. AI indices help you manage context within the Elastic Stack. Try it out in Serverless, and let us know what you think in our Discuss forums or the #stack-kibana channel in our Community Slack.

We’d also love to hear from you about what use cases you’d like to solve using AI indices.

While AI indices will be included in future Stack releases, today we recommend using Serverless.

How it works: AI Index, Kibana Workflows, and the query-ki skill

Building context in this walkthrough has three moving parts:

1. An AI Index, where KIs live. It's a regular Elasticsearch index or data stream with a specific naming convention triggering component templates to configure the right mappings automatically.

2. Kibana Workflows, which read from your data sources, run an LLM to structure content into KIs, and write those KIs into the AI Index.

3. A query-ki skill, a skill that queries KIs directly from the AI Index using ES|QL, and that a chat agent can call as a tool.

Prerequisites

This tutorial assumes you have:

1. An Elasticsearch Serverless project. You can sign up for a trial if you don't have one.

2. An API key to access your Elasticsearch project. 

Create sample indices for agent routing

First, we’ll need some sources. Sources can be data that already exists in your Elasticsearch indices, or external data accessed via connectors or ES|QL data sources. 

For this blog, we’ll create some indices with example data. We’ll start with an example using three datasets: BEIR/fiqa (financial), beir-nfcorpus (biomedical/nutrition), and beir-scifact (scientific fact-checking). Each index is populated with its own _meta.description. 

Here are the mappings we define for these indices:

Then, using the above convenience scripts, load a handful of documents into each index with the _bulk API.

Now imagine an agent with a question and the indices we’ve just created. The agent has no idea which one is relevant at the start. Without pre-computed context, it either performs exploratory lookups (mappings, test searches) to figure out which source to use, or searches all three and hopes the merged results contain something useful. Either approach costs tokens, and if you multiply that inefficiency across every query an agent makes, it adds up.

Create your AI Index

Before generating any KIs, you need an index to store them. We call this an AI Index.

The naming convention is what triggers automatic configuration. Any index whose name starts with ai-index-idx- is a regular index; ai-index-ds- is a data stream. You’ll want to choose data streams for observability use cases, time series data, and when recency is important. Conversely, standard indices are a good choice for static data that will exist for a long while, where recency is not as much of a concern, and may need to occasionally be updated on demand. This naming convention is required for AI indices. 

When Elasticsearch sees the ai-index- prefixes, it automatically applies component templates that configure the right mappings and settings.

Creating an AI Index is a single call:

To see exactly what the component templates applied, inspect the mappings:

The response shows the fields every AI Index gets out of the box:

title, description, and content are each a text field with a .semantic sub-field of type semantic_text, supporting hybrid retrieval.

Data stream indices (ai-index-ds-*) additionally carry a default 90-day data retention policy. This blog uses a standard index (ai-index-idx-*).

Index Metadata as a Knowledge Indicator

The target use case for this example is how the query-index-metadata-ki skill can route an agent to the correct Elasticsearch index, even when index or field names are vague. This reduces mistakes from choosing the wrong index or formulating queries based on incomplete schema exploration.

Since we're creating KIs for our own indices, we can give the LLM a head start: annotate index mappings with human-written _meta.description content. The workflow generates better KIs with more context to work from.

To address this, we'll manually create a Kibana Workflow that profiles each index and writes routing KIs into the AI Index. The workflow chains four steps:

Step

Type

What it does

get_mapping

elasticsearch.request

Read the mapping, including _meta.description and per-field descriptions.

sample_docs

elasticsearch.search

Pull a few real documents so the profile reflects actual value shapes.

profile_index

ai.agent

Generate a structured index profile as structured output.

sink_index_ki

elasticsearch.bulk

Write the profile into the AI Index as a KI.

Paste the following YAML into the Workflows editor:

Let's walk through what this workflow does. We loop over three specified indices with a foreach loop. For each:

1. get_mapping fetches the Elasticsearch index mappings, including any _meta.description annotations we added earlier.

2. sample_docs pulls 3 real documents. Concrete examples give the LLM much better signal than schema alone.

3. profile_index calls ai.agent with the index name, mappings, and sample documents. The LLM returns structured output describing the index's purpose, key fields, and an example ES|QL query showing how to use it.

4. sink_index_ki writes the result into the AI Index as a KI of type index_metadata_entry, keyed on the index name so re-runs are idempotent.

A few things to point out: 

• This workflow hard-codes a specific set of indices. In practice, you could derive the list from an index pattern or a dynamic source. 

• The foreach loop also runs iterations sequentially, which is fine for this guide but slow in production because each iteration involves an LLM call. For scale, use workflow.executeAsync or native parallel support. The cheat sheet has tips on both.

• In the profile_index step, the agent prompt is the special sauce. This is what shapes the accuracy and usefulness of the KIs. 

• Using ai.prompt can improve workflow efficiency (and cost) if you don’t need to load other tools. 

• Cost can be controlled in multiple ways. Richer prompts and structured output often result in higher token utilization, and of course the model you choose significantly impacts total costs. The Elastic Inference Service (EIS) can be a great playground to test different models against the profile_index’s ai.agent step to compare how different models stack up against each other when generating KIs. 

Query your AI Index to verify Knowledge Indicators

Once the beir-index-profile-ki workflow runs, query the AI Index directly in the Discover tab using the following ES|QL query to confirm what got written:

This will result in the following output: 

Build a portable skill to retrieve AI agent context

Retrieval is a critical component in an AI index. A KI is a document in the AI Index, and finding one is a single ES|QL query. We package that query as a small, portable skill so any agent can call it, regardless of the harness it runs in.

We write the skill as a SKILL.md: a YAML header with a name and description, followed by markdown instructions. This is the same Agent Skills format that many harnesses, including Claude Code, LangChain's Deep Agents, and others, load directly. 

The harness reads the header content up front, and only pulls in the full instructions when a question matches the description. The one thing the skill asks of the harness is a way to run ES|QL against Elasticsearch.

Here is a sample query-index-metadata-ki skill:

Let’s break down what the skill is doing: 

• We’re defining index-metadata-entry as a KI type/use case.

• We’re performing a hybrid ES|QL search on our AI indices, filtering by the appropriate type using RRF as the default method to fuse results.

• The KI results will directly ground the agent’s answer when determining what indices are relevant to the query.

Because the skill is just instructions plus a query, it travels wherever your agent does. You can point the same file at a Kibana Workflow agent, Claude Code, LangChain Deep Agents, or any other harness without changing a line of it.

Connect your AI Index to an agent harness 

We want to demonstrate how you can use AI indices to query your data with any harness. For these examples, we’ll use LangChain Deep Agents and an OpenAI-compatible key, but any other agent harness can be easily substituted in, including Elastic Agent Builder.

First, let’s create a baseline to see how an agent will perform without using KIs:

Here’s a modified example that could run the same agent, but now with the ability to search AI indices to return KIs: 

This agent will always query the KI indices to get the answer.

How much do Knowledge Indicators reduce agent token usage?

Since we’re using agents, the results of these scripts are non-deterministic. However, when I ran these results against the query Is there scientific evidence that vitamin D supplementation prevents cancer?, both agents led to the same conclusion, but they took different paths to get there: 

Baseline (No AI Index)

With AI Index

Total tool calls

12

8

read_file calls

0

2

get_mapping calls

3

0

esql_query calls

9

6 

Total indices queried

2 (bounced between beir-scifact and beir-nfcorpus)

1 (beir-nfcorpus)

Tokens consumed

167,763

92,711

Latency

39.58s

36.15s

Answer

Grounded, correct

Grounded, correct

The KI answers were both grounded and correct, but an interesting datapoint is the fact that the overall tool usage and token utilization was smaller when using KIs (latency was roughly equivalent). Here’s how both paths went, side by side: 

Run the full AI Index pipeline in Serverless

This walkthrough offered a deep dive into the build-it-yourself version of AI indices and KIs. In production, you wouldn't hand-write these workflows; a setup agent would generate them, and a feedback loop would refine KIs from the agent's own traces. But the primitives are exactly what you just used: extract KIs with a workflow, store them in an AI Index, and retrieve them with a skill.

Managing context is key to a relevant and efficient agentic search system, and AI indices are a way to manage this context with the full power of the Elastic stack. Try it out in Serverless and let us know what you think in our Discuss forums or the #stack-kibana channel in our Community Slack!