Create rules and action policies with Elastic Agent Builder

Use an agent with the rule-authoring skill (rule-management in 9.5) instead of the rule form. The agent resolves the data source and proposes a configured Kibana Universal Alerting rule.

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 page using the navigation menu or the global search field, select the Space Settings tab, and turn on agentBuilder:experimentalFeatures.
  • To search for and edit existing rules and action policies, the contextEngine:enabled advanced setting also turned on - On the Space Settings tab, turn it on in each space where you use the agent.
  • To search for existing rules and action policies from a conversation, the agentBuilder:experimentalFeatures advanced setting turned on - On the Space Settings tab, turn it on. Refer to Enable experimental features. The agent can still create rules and action policies with this setting off. It can also edit a saved rule from its details page, or a saved action policy from its edit page.
  • A space that uses the Classic or Observability solution view - The rule-authoring and action-policy-authoring skills aren't available in other spaces.
  • An Elastic Observability Serverless project - The rule-authoring and action-policy-authoring skills aren't available in other project types.
  • The required privileges - Your role needs the privileges to use Elastic Agent Builder and save rules and action policies.

To create a rule, go to Alerting → Rules in the Observability navigation menu, or find Rules using the global search field.

Select Create rule → Create with agent. When the Rules list is empty, select With AI Agent.

In the rule creation options, select Create with agent.

Alternatively, open any agent in Elastic Agent Builder that has the rule-authoring skill configured.

The rule-authoring skill covers ES|QL query patterns, thresholds, grouping, and the Kibana Universal Alerting data model.

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 on the Rules page 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%.

The agent proposes the workflows and action policies needed to deliver notifications.

The rule-management skill creates the action policies itself.

After the rule-authoring skill proposes a complete rule that opens alerts, it offers to set up notifications. If you accept, the agent loads the action-policy-authoring skill. That skill creates the action policies.

Note

Action policies invoke workflows for alerts only. If you ask the agent to set up notifications for a rule that doesn't open alerts, it explains the limitation and offers a way forward:

  • Unsaved rule - The agent changes the draft rule so that it opens alerts. Then you save the rule.
  • Saved rule - Whether a rule opens alerts can't change after you save it. The agent offers to create a new rule with the same query and schedule that opens alerts, then set up notifications on that rule.
  • Workflows - Workflows are the delivery mechanism. They define what happens when Kibana Universal Alerting 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. Kibana evaluates them against the rule's alerts and invokes the workflow for the alerts they apply to. When you create an action policy with a rule, the policy applies to that rule's alerts.
    • The agent links the policy to the rule with a routing tag.
      • If the rule already has a routing tag that no other rule uses, the agent reuses it.
      • Otherwise, the agent adds a notify-<rule-name> routing tag to the rule and the policy. The tag is lowercase with hyphens, for example, notify-high-cpu-prod.
      • The policy also applies to alerts from any other rule with that routing tag.
      • If the agent adds a routing tag to a rule you already saved, save the rule again so the tag takes effect.
    • The action policy references the rule by ID.

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

The three objects depend on each other. Save them in this recommended order:

  1. Rule - Save the rule first. The link between the rule and the action policy takes effect only after the rule is saved.
  2. Workflow - The action policy references the workflow as a destination. The reference must resolve to a persisted workflow.
  3. Action policy - Save the action policy last.
    • You can't select Create policy while a workflow destination is still a draft. You can save the policy before the rule. The policy doesn't apply to the rule's alerts until the rule is saved.
    • You can't save the action policy until both its rule and its workflow exist.
Note

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.