Limitations and known issues in Elastic Agent Builder

This section lists the limitations and known issues in Elastic Agent Builder.

In version 9.4+, index search tools support cross-cluster search (CCS). Index search tools only search remote clusters when you explicitly configure a cross-cluster pattern like remote_cluster:logs-*. Without a remote pattern, the tool resolves indices locally. To learn how to configure a tool for remote clusters, refer to Index search tools.

In previous versions, only ES|QL tools support CCS. To search remote clusters, use a custom ES|QL tool and instruct your agent to query remote_cluster:index_name.

Elastic Agent Builder tools can exclude documents stored in the frozen tier. Searching that data recovers searchable snapshots from object storage. These searches are slow and can cause tool calls to time out.

Behavior depends on your version:

• 9.4.0 through 9.4.7, and 9.5.0 through 9.5.4: Tools read frozen tier data.
• 9.4.8 and 9.5.5: Tools always exclude frozen tier data, and the options to include it aren't available.
• 9.4.9, 9.5.6, and later: Tools exclude frozen tier data by default. You can include it with the options in this section.

Query tools exclude documents in frozen tier indices. This includes the built-in execute_esql, generate_esql, and search tools, plus custom ES|QL tools and index search tools.

• If only some matching documents are frozen, the tool returns the rest.
• If every matching document is frozen, the tool returns no documents.

Mapping tools differ:

• get_index_mapping can omit fields that exist only in frozen backing indices. This applies when it reads a data stream, an alias, an index pattern, or a remote index. A request for one local index still returns that index mapping.
• index_explorer can omit those fields for remote clusters. For a local data stream, it returns the data stream mapping, which doesn't apply this filter.

These Security tools have no include_frozen parameter. On versions that exclude frozen tier data, they always exclude it. The options in this section don't apply to them:

• security.alerts
• security.attack_discovery_search
• security.search_entities
• security.get_entity, when it reads profile history
• security.pci_compliance

To include frozen tier data, use one of these options:

• For one tool call: Ask the agent to include frozen tier data. Built-in tools accept an include_frozen parameter. The parameter description tells the agent to set it to true only when you or the agent instructions ask for frozen tier data. For details, refer to Frozen tier data in built-in tools.

• For a custom tool: In Data tiers, select Include frozen tier data. Or set include_frozen to true in the tool configuration object in the Tools API.

• For all five built-in tools in a space: Turn on Elastic Agent Builder: Include frozen tier data by default (agentBuilder:includeFrozenByDefault). This is an advanced setting. Use it for Model Context Protocol (MCP) clients, where you can't adjust a single agent prompt.

  When the setting is on, the parameter description tells the agent to set include_frozen to false only when you or the agent instructions ask to exclude frozen tier data. An explicit include_frozen value on a tool call overrides the setting. The setting doesn't affect custom tools or the Security tools in this section.

Including frozen tier data doesn't extend tool timeouts. Queries over large amounts of frozen data can still time out.

The A2A server does not currently support streaming operations. All agent interactions use the synchronous message/send method, which returns a complete response only after task execution completes.

Human-in-the-loop prompts work only in interactive Elastic Agent Builder conversations. A sub-agent execution cannot collect a response to these prompts, whether the sub-agent runs in the foreground or the background, so Elastic Agent Builder declines any action that requires confirmation or authorization.

The sub-agent run itself does not fail. The tool call returns an error result and the sub-agent continues, so the sub-agent can report the declined action in its output.

A2A executions behave differently: the action is not declined. Instead, the conversation round remains in the awaiting_prompt state, but A2A clients cannot respond to the prompt.

The execute_api tool follows the same rule in sub-agent runs and in workflow ai.agent steps: it declines any Elasticsearch or Kibana API operation that requires confirmation, unless the operation is approved in advance. You can approve operations in advance in these ways:

• For every run of an agent: Add the operations to the agent's auto-approved APIs. This approval is stored with the agent, so it applies to every run, including runs from workflows, and to the sub-agents the agent starts.

• For one workflow step: List the operations under approvals.auto_approved_apis in the ai.agent step. This approval applies only to that step and to the sub-agents it starts, in addition to the agent's auto-approved APIs.

• For one sub-agent run: Before starting a sub-agent, a parent agent can ask you to approve operations for it. The request can name individual operations, a group such as all indices operations, or every such operation on Elasticsearch or Kibana. The outcome depends on your response and any existing auto-approvals:

  • If you approve, the sub-agent can call those operations without another prompt.
  • If you deny, the sub-agent runs without access to them.
  • If all requested operations are already auto-approved, you aren't asked.

  A sub-agent can also call any operation that the parent agent or the sub-agent itself auto-approves.

This limitation is separate from the waitForInput step in Workflows, which pauses a workflow execution for reviewer input.

ES|QL tools are subject to the current limitations of the ES|QL language.

Ensure your cluster version supports the ES|QL features you intend to use.

For a complete list of ES|QL limitations, refer to the ES|QL limitations documentation.

The following errors suggest your selected model may not be compatible with Elastic Agent Builder:

Error: Invalid function call syntax
		

Error executing agent: No tool calls found in the response.
		

To learn more, refer to Model configuration in Elastic Agent Builder.

Current testing shows that Claude 4.6 Sonnet may generate invalid ES|QL for dashboard and visualization workflows, particularly with reserved keywords, dotted field names such as system.load.1, and incorrectly formatted aliases.

Workaround: Use a higher-tier model, such as Claude 4.6 Opus, for ES|QL-heavy dashboard generation. To learn more, refer to Recommended models.

This error occurs when a conversation exceeds the maximum context length supported by the LLM. This typically happens when tools return large responses that consume the available token budget.

To learn more, refer to Context length exceeded in Elastic Agent Builder conversations.

The .execute_esql tool is designed only for ES|QL syntax, not other query languages.

When using SQL syntax with the default agent, it attempts to use the .execute_esql tool instead of recognizing the input as SQL.

This results in parsing errors like this:

[
  {
    "type": "error",
    "data": {
      "message": "parsing_exception\n\tCaused by:\n\t\tinput_mismatch_exception: null\n\tRoot causes:\n\t\tparsing_exception: line 1:15: mismatched input 'WHERE' expecting {<EOF>, '|', ',', 'metadata'}",
      "stack": "ResponseError: parsing_exception\n\tCaused by:\n\t\tinput_mismatch_exception: null\n\tRoot causes:\n\t\tparsing_exception: line 1:15: mismatched input 'WHERE' expecting {<EOF>, '|', ',', 'metadata'}\n    at KibanaTransport._request (Desktop/Dev/kibana/node_modules/@elastic/elasticsearch/node_modules/@elastic/transport/src/Transport.ts:591:17)\n    at processTicksAndRejections (node:internal/process/task_queues:105:5)\n    at Desktop/Dev/kibana/node_modules/@elastic/elasticsearch/node_modules/@elastic/transport/src/Transport.ts:697:22\n    at KibanaTransport.request (Desktop/Dev/kibana/node_modules/@elastic/elasticsearch/node_modules/@elastic/transport/src/Transport.ts:694:14)"
    }
  }
]
		

Disabling a workflow doesn't remove it from the agents or spaces that use it as a pre-execution workflow, so every message to those agents fails with a Workflow Failed error. On 9.4.x, and on 9.5.0 through 9.5.2, the disabled workflow also disappears from the Workflows selector, so you can't clear it from the UI without re-enabling the workflow first.

Workaround: Re-enable the workflow, clear it from the selector, save, then disable the workflow again. You can also clear it through the API. To learn more, refer to Disabled pre-execution workflow.

On 9.2 deployments, the Copy your MCP server URL button does not include the space name when used from a custom Kibana Space.

Workaround: Manually add /s/<space-name> to the URL. For example: https://<deployment>/s/<space-name>/api/agent_builder/mcp

For more information about Elastic Agent Builder and Spaces, refer to Permissions and access control.

• Get started
• Troubleshooting