Create rules and action policies with Elastic Agent Builder

Rule and action policy authoring in Elastic Agent Builder is part of the experimental alerting system in Kibana. The experimental alerting system registers rules and action policies as attachment types in Elastic Agent Builder, so an agent equipped with the rule management skill can propose, create, and configure them through natural language conversation.

Instead of filling out the rule form manually, you describe what you want to monitor and the agent uses its rule management skill and tools to resolve the data source and build a fully configured rule proposal for you.

Before you start, make sure you have the following:

• The required subscription - Elastic Agent Builder requires the appropriate Elastic Stack subscription or Serverless project feature tier.

• The agentBuilder:experimentalFeatures advanced setting turned on - Go to the Advanced Settings menu using the navigation menu or the global search field, and turn on agentBuilder:experimentalFeatures.

• The required privileges - Your role must include the following:

  To...	Required privilege
  Access and use Elastic Agent Builder	Elastic Agent Builder: Read (under Analytics)
  Save the rule	Rules: All (under Alerting)
  Save the action policy	Action Policies: All (under Alerting)
  Select or create the workflow destination	Workflows: Read to select an existing workflow; Workflows: All to create one (under Analytics > Workflows)

You can start from the rule management page by selecting the option to create a rule with an agent, or open any agent in Elastic Agent Builder that has the rule management skill configured. The rule management skill gives the agent domain expertise in experimental alerting system rule authoring, including knowledge of ES|QL query patterns, threshold configuration, grouping, and the alerting v2 data model. When you describe a monitoring requirement, the agent uses its tools to resolve the relevant data source and builds a rule proposal.

The proposal appears as an inline attachment in the conversation, summarizing the rule name, type, schedule, and tags. Opening the attachment shows the full configuration across three views:

• Conditions - The ES|QL query, thresholds, grouping criteria, and schedule the agent constructed.
• Query preview - The results of running the proposed ES|QL query against live data, so you can evaluate whether the rule would produce meaningful signal before committing to it.
• Runbook - A free-text runbook field associated with the rule, which the agent can populate from context in the conversation.

The agent can also search for and attach an existing rule to the conversation using the same inline attachment, opening the same view for inspection or revision.

The agent does not persist the rule automatically. Saving is an explicit action that signals the configuration is ready. Until the rule is saved, the proposal exists only in the conversation and is not evaluated against data.

When Elastic Agent Builder saves or edits a rule, Kibana automatically adds an agent-builder-assisted tag to it. The tag appears in the rules list and works as a normal filter tag. You can remove it or edit it manually. If the agent edits the same rule later, the tag is re-applied automatically.

Use these prompts as a starting point, then adjust them to your data and thresholds:

• Create an error threshold rule on the checkout service data. Alert when there are more than 3 HTTP 5xx errors in the past 5 minutes, grouped by URL path.
• Monitor average CPU usage across all hosts. Alert when any host exceeds 90% for more than 10 minutes.
• Alert when log volume from the payments service drops below 100 events in a 5-minute window. This likely means data has stopped flowing.
• Set up a rule that tracks error rate by service. Alert at medium severity when the rate exceeds 1%, and critical when it exceeds 5%.

After a rule is saved, you can ask the agent to configure notifications. The rule management skill handles this by creating workflows and action policies.

• Workflows - Workflows are the delivery mechanism. They define what happens when the experimental alerting system determines that a notification should be sent, such as posting to Slack, emailing a team, triggering PagerDuty, and so on.
• Action policies - Action policies are the gating mechanism. They evaluates alert episodes from the rule on a continuous schedule and invokes the workflow when the episode clears the action policy's match conditions and frequency settings. When the agent creates an action policy alongside a specific rule, the action policy is automatically scoped to that rule.

Both objects are proposed as inline attachments and must be explicitly saved before they take effect.

The three objects have a dependency chain that determines the order in which they must be saved:

1. Rule - The action policy references the rule by ID. The ID is not available until the rule is persisted.
2. Workflow - The action policy references the workflow as a destination. The reference must resolve to a persisted workflow.
3. Action policy - Can only be saved after both its rule and workflow dependencies exist.

Action policies saved or edited through Elastic Agent Builder also receive the agent-builder-assisted tag automatically, with the same behavior: user-editable and re-applied on subsequent agent edits.

• Elastic Agent Builder - How the Elastic Agent Builder platform works, including agents, skills, and tools.