Connect Elastic Agent Builder agents and Elastic Workflows

Elastic Workflows and Elastic Agent Builder combine deterministic automation with conversational reasoning. You can create workflows conversationally, make workflows available to agents, invoke agents from workflows, and start workflows from conversation events.

Elastic Agent Builder and workflows work together in the following ways:

• Create workflows from Agent Chat: Create and edit workflows by describing what you want in plain language. Kibana generates and updates the workflow YAML for you, so you can quickly build without memorizing step types or Liquid syntax.
• Use workflows from agents:
  • Trigger an existing workflow from a conversation with a workflow tool.
  • Assign pre-execution workflows that run before the agent starts reasoning.
  • Assign post-execution workflows that run after the agent finishes responding.
• Use agents from workflows: Invoke an agent from a workflow with the ai.agent step. To add context to a conversation without triggering an agent response, use the conversation steps . For advanced API operations, use the kibana.request step.
• React to conversation activity: Run a workflow when an attachment is added, updated, or deleted, or when conversation metadata changes. For supported conversation templates, you can also run a workflow when a conversation gets new messages or other changes. Refer to Elastic Agent Builder triggers.

Before you begin:

• Familiarize yourself with the core concepts of Elastic Workflows.
• Turn on Elastic Workflows through the workflows:ui:enabled advanced setting, which is on by default in 9.4 and later. When this setting is off, the workflow options in Elastic Agent Builder are hidden and assigned workflows don't run.
• Make sure you have the appropriate subscription. Elastic Workflows requires an Enterprise subscription on Elastic Stack deployments, or the appropriate project feature tier on Serverless.
• Make sure you have the correct privileges to create and run workflows.

For details, refer to Set up workflows.

Pre-execution workflows run after each user message, before the agent makes any calls to the large language model (LLM) in response. They let you use Elastic Workflows for deterministic preparation or control before the agent begins its reasoning loop.

A pre-execution workflow runs once for each user message. It does not run before every LLM call or tool call within the agent's response.

Pre-execution workflows can:

• Add or rewrite prompt context before the agent starts.
• Cancel the agent run when a workflow detects that the request should not continue.
• Run multiple workflows in sequence when more than one workflow is assigned.

You can assign pre-execution workflows to a single agent or to every agent in a space. If you do both, the agent runs the workflows from both settings.

1. Select Manage components at the bottom of the left sidebar to open the Agents list.
2. Select an agent, then select Settings.
3. Under Pre-execution workflow, select one or more workflows in Workflows.
4. Select Save.

To confirm the setup, send a message to the agent, then check that the run appears in the workflow's execution history.

The following screenshot shows the Pre-execution workflow setting in the agent Settings view.

×

The prerequisites apply here too. In addition, the Agent Builder section in GenAI Settings appears only when the agentBuilder:experimentalFeatures advanced setting is turned on. It's off by default.

1. Go to Stack Management → AI → GenAI Settings.
2. In the Agent Builder section, find Pre-execution workflow and open the Workflows selector.
3. Select one or more workflows.
4. Select Save changes.

To confirm the setup, send a message to any agent in the space, then check that the run appears in the workflow's execution history.

Workflows that you assign here run for every agent in the space, in addition to any workflows you assign to an individual agent. If you assign the same workflow in both places, it runs only once.

Agents keep running these workflows whenever Elastic Workflows is turned on, even if you later turn off agentBuilder:experimentalFeatures and the Agent Builder section disappears. To clear the setting when the section is hidden, use the API. Refer to Remove the workflow from the space setting.

Disabling a workflow doesn't remove it from the agents or spaces that use it. Until you remove the workflow, every message to the affected agents fails. Refer to Disabled pre-execution workflow.

Post-execution workflows run after the agent finishes each response. Use them to audit the exchange, open a ticket, notify a channel, or grade the response. They can't change the response, and Elastic Agent Builder ignores their output.

You assign post-execution workflows to individual agents. Unlike pre-execution workflows, post-execution workflows have no space setting.

• The prerequisites for using workflows with Elastic Agent Builder.
• A role that grants wildcard (*) Kibana privileges, such as the superuser role or the Admin role in Serverless. You need this role to configure an agent's post-execution workflows. Without it, the Workflows selector is disabled. You can't grant wildcard privileges from the Kibana role management UI. Refer to Users and roles for how to assign roles.
• By default, each workflow runs as the user who sent the message, so its steps can do only what that user's privileges allow. If the workflow is private, that user must own it or have Executor or Editor access to it.

Kibana UI

1. Select Manage components at the bottom of the left sidebar to open the Agents list.
2. Select an agent, then select Settings.
3. Under Post-execution workflow, select one or more workflows in Workflows.
4. Select Save.

To confirm the setup, check that Post-execution workflows shows Enabled on the agent overview. Then send a message to the agent and check that the run appears in the workflow's execution history.

The following screenshot shows the Post-execution workflow setting in the agent Settings view.

×

API

To assign post-execution workflows through the Agent Builder API, set the agent field configuration.post_execution_workflow_ids. The following request assigns one workflow:

				PUT kbn:/api/agent_builder/agents/<agent_id>
					{
  "configuration": {
    "post_execution_workflow_ids": ["<workflow_id>"]
  }
}
		

• The update replaces only the keys you send, so the agent keeps its instructions, tools, skills, and other settings.
• Without wildcard (*) Kibana privileges, a request that changes post_execution_workflow_ids returns a 400 error: Only administrators can configure post-execution workflows.

A post-execution workflow runs only when the agent completes its response. It doesn't run in these cases:

• The agent run fails, or the user stops it.
• A pre-execution workflow cancels the run.
• The agent is paused on a human-in-the-loop prompt. The workflow runs later, after the user answers and the agent finishes that response.
• The agent reads an existing conversation without saving to it, such as an ai.agent step that sets ephemeral: true and a conversation ID.

When an agent has more than one post-execution workflow, they run in the order they're listed. Elastic Agent Builder waits up to 120 seconds for each workflow to complete, fail, or pause for input before it starts the next. A workflow that's still running after that wait doesn't block the workflows that follow.

Elastic Agent Builder sets execution.triggeredBy to agent-builder-hook for these runs, so a workflow can check that value and skip runs that someone started directly. Refer to execution.triggeredBy.

If a workflow fails, the agent's response stays in place. Kibana logs the failure and still runs any later workflows assigned to the agent. In the following cases, Kibana logs the failure before it records an execution, so the failure doesn't appear in execution history:

• The workflow doesn't exist, for example, because someone deleted it.
• The workflow is turned off.
• The workflow has validation errors.
• The workflow is private, and the user who sent the message doesn't have access to run it.

Declare the inputs you want the workflow to receive under its manual trigger, not at the workflow root. Elastic Agent Builder doesn't detect inputs declared at the root of a workflow saved in 9.5 or later. Refer to inputs. Inside the workflow, reference an input as {{ inputs.prompt }}.

The following workflow logs each exchange:

name: log_agent_exchange
enabled: true
triggers:
  - type: manual
    inputs:
      properties:
        prompt:
          type: string
        response:
          type: string
steps:
  - name: log_exchange
    type: console
    with:
      message: "User asked: {{ inputs.prompt }}. Agent answered: {{ inputs.response }}"
		

Elastic Agent Builder always sends prompt, response, round_id, and tool_calls. It also sends conversation_id and agent_id when the run has them, even if the workflow doesn't declare them. It sends round_connector_id, workflow_context, and tool_results only when the workflow declares them. To keep one of these three out of the workflow, remove it from the manual trigger.

The tool_results data is truncated and might not be the complete tool output. To limit size, Elastic Agent Builder truncates tool_results before the workflow receives it: each string to 4,000 characters and each array to 50 items. If a result's data is still larger than 32,000 characters, Elastic Agent Builder replaces it with type: other and data set to { "omitted": "result data exceeded 32000 characters" }.

If the workflow sets additionalProperties: false, declare every input that Elastic Agent Builder sends, including conversation_id and agent_id. Otherwise, the run fails input validation and appears as a failed execution in the workflow's execution history.

triggers:
  - type: manual
    inputs:
      properties:
        prompt:
          type: string
        response:
          type: string
        conversation_id:
          type: string
        round_id:
          type: string
        agent_id:
          type: string
        round_connector_id:
          type: string
        workflow_context:
          type: object
        tool_calls:
          type: array
          items:
            type: object
            additionalProperties: true
        tool_results:
          type: array
          items:
            type: object
            additionalProperties: true
      additionalProperties: false
		

Follow these steps to invoke an ai.agent as a step within a workflow.

1. Open the Workflows editor and create or edit a workflow.
2. Add a new step with the type ai.agent.
3. Set the agent-id parameter at the top level of the step to the unique identifier of the target agent. If you omit it, the step uses the built-in Elastic AI Agent.
4. In the with block, set the message parameter to your natural language prompt.
5. Optionally, in the with block, set the schema parameter to a JSON Schema object to receive structured output from the agent instead of free-text.
6. Optionally, route the step to a specific model by setting connector-id or inference-id at the top level of the step. These parameters are mutually exclusive.

version: "1"
name: analyze_flight_delays
description: Fetches delayed flights and uses an agent to summarize the impact.
enabled: true
triggers:
  - type: manual
steps:
  # Step 1: Get data from Elasticsearch
  - name: get_delayed_flights
    type: elasticsearch.search
    with:
      index: "kibana_sample_data_flights"
      query:
        range:
          FlightDelayMin:
            gt: 60
      size: 5

  # Step 2: Ask the agent to reason over the data
  - name: summarize_delays
    type: ai.agent
    agent-id: "elastic-ai-agent"
    with:
      message: |
        Review the following flight delay records and summarize which airlines are most affected and the average delay time:
        {{ steps.get_delayed_flights.output }}

  # Step 3: Print the agent's summary
  - name: print_summary
    type: console
    with:
      message: "{{ steps.summarize_delays.output }}"
		

Set agent-id and other configuration keys at the top level of the step. Set inputs like message in the with block.

For the complete step reference, refer to ai.agent.

A workflow can add events, such as notes, and user messages to an Elastic Agent Builder conversation. The agent reads user messages and notes the next time it runs on the conversation. For example, a workflow can post incident updates as they arrive, and a later ai.agent step or chat request can summarize them.

Use these steps:

• ai.conversation.create: Create a conversation and get its ID.
• ai.conversation.add_event: Add an event, such as a note.
• ai.conversation.add_user_message: Add a user message.

Use the generic kibana.request step to interact with Elastic Agent Builder APIs programmatically.

1. Add a new step with the type kibana.request.
2. Set the method (for example: GET, POST).
3. Set the path to the specific Agent Builder API endpoint.

name: list_agents
enabled: true
triggers:
  - type: manual
steps:
  - name: list_agents
    type: kibana.request
    with:
      method: GET
      path: /api/agent_builder/agents
		

The elastic/workflows GitHub repo contains more than 50 examples you can use as a starting point.

• Tools overview
• Workflow tools
• Author workflows with natural language
• Event-driven triggers
• Agent Builder API