AI Agents Overview

Last updated: 2026-09-30

Explains the feature specification, individual parameters, and operational rules for AI Agents, which act autonomously — for example performing root-cause analysis or creating tasks — in response to incident creation or status changes.

Overview

Lorel.ai’s AI Agents automatically carry out a predefined initial response when triggered by events such as incident creation.

When an incident occurs, an agent automatically gathers contextual information (logs, detection events, related incidents, and so on), analyzes the situation with an AI model, and then performs actions such as appending analysis results to the incident or creating tasks.

Both built-in and custom agents can be triggered automatically based on a policy, or run manually and immediately by a user against a chosen incident. Agents also support test execution (dry-run), which lets you verify behavior without affecting the incident, and an execution rate limit that prevents runaway repeated execution. For past executions, you can browse the list and details, and see the total number of runs.

There are two kinds of AI Agents:

  • Built-in agents (AI Agent from JIG-SAW / built-in)

    Registered in Lorel.ai as standard features from the start, ready to use as-is. They start automatically when a new incident occurs, and automatically perform situation analysis or an initial response appropriate to the incident type.

  • Custom agents

    You can freely design these to match your own operational rules — the instructions given to the AI (the prompt), the execution rate limit, connected tools, and the actions to run (creating tasks, sending notifications, and so on).

Either kind of agent must be assigned to an “Incident Policy” before it will actually run automatically. An agent that isn’t assigned to a policy will not run automatically, even while enabled.

What you can do

Operations available to each project member for the AI Agents feature.

Feature / operationDescriptionRequired role
Create, edit, delete custom agentsCreate a new custom agent with its own prompt, actions, execution rate limit, and tool connections, or update or delete one from the project.Project Administrator / Editor
Enable / disableSwitch an agent’s operating status to Enabled or Disabled. A disabled agent is excluded from both automatic and manual execution.Project Administrator / Editor
Manual executionRun an agent immediately against a chosen incident (only enabled agents can be run).Project Administrator / Editor
Test execution (dry-run)Test the agent’s reasoning without causing side effects such as appending to the incident or creating tasks.Project Administrator / Editor
Browse, search, filter the listList all registered agents, filter by tab (All / Built-in / Custom), and search by keyword.Project Administrator / Editor / Worker / Viewer
View agent configuration detailsView the definition — basic info, agent tool settings, data settings, and so on.Project Administrator / Editor / Worker / Viewer
View execution historyView a paginated list of past executions per agent, plus a detailed log for each run (input/output, errors, skip reasons).Project Administrator / Editor / Worker / Viewer
View total runsView the total number of times the agent has run.Project Administrator / Editor / Worker / Viewer
View linked policiesView the list of Incident Policies that trigger this agent automatically, and jump to each policy screen.Project Administrator / Editor / Worker / Viewer
Change data protection (PII) settingsChange how personal information (address, email, username, phone number) contained in the AI’s input and analysis output is protected.Project Administrator / Editor

AI agent behavior and configuration specification

Detailed specification for built-in agents, creating and managing custom agents, individual configuration items, and execution verification.

1. Built-in agents

Basic specification for the agents built into Lorel.ai from the start.

  • Role of provided agents: Agents that perform an initial response appropriate to the operational phase — such as log/event analysis and root-cause estimation when an incident occurs — are provided by default.
  • Automatically provisioned in new projects: The moment you create a new project, built-in agents are automatically set up in an Enabled state with no additional configuration required.
  • Trigger (what starts automatic execution): They run automatically when a new incident occurs. The trigger condition can’t be changed. Automatic execution also requires an explicit assignment to an Incident Policy — with no assignment, the agent doesn’t start, and no other agent substitutes for it automatically.
  • Manual execution: Regardless of the automatic-trigger condition, an enabled built-in agent can be run immediately and manually from the target incident’s screen.
  • What can’t be changed (fixed specification): Because these are built-in agents, you can’t create additional built-in agents, delete them, or change their name, description, reasoning, trigger condition, or actions. The only operations available to users are enabling/disabling and changing data protection settings.
  • Execution rate limit (fixed specification): Users can’t change the execution rate limit.

2. Creating, editing, and deleting custom agents

Specification for the lifecycle of custom agents and configuration changes.

  • Creating an agent: Creation is restricted to the Project Administrator and Editor roles. The fields defined at registration are:

    • Basic info (name, description (optional), prompt)
    • Actions (up to 10)
    • Execution rate limit
    • Agent tools (Runbooks, Sources, Access — up to 20 combined)
    • Information passed automatically (related incidents, detection events)
    • Data protection settings (per-agent PII protection)

    There is no plan-based limit on the number of custom agents you can create.

  • Editing an agent: You can change or update the configuration of a created custom agent at any time. You can update the name, description (optional), prompt, execution rate limit, actions, agent tools, information passed automatically, and data protection settings.

    • You don’t choose a trigger condition on the agent itself: There’s no field, at creation or afterward, for choosing which incident event starts the agent. All four supported event types (created / resolved / reopened / escalated) are automatically registered as candidates when the agent is created; of these, created, resolved, and reopened can currently be selected on screen. Which condition actually triggers it is decided separately, on the Incident Policy where you link this agent (see “AI Agent assignment specification” in the Rules Overview guide).
  • Deleting an agent: You can delete a custom agent you no longer need. Deleting it completely erases the agent’s configuration data from the project; this can’t be undone, and its execution history will no longer be accessible either.

3. Basic info

The area at the top of the screen that defines the agent’s basic identifying information and instructions.

  • Name (custom only): The agent’s name (up to 255 characters).
  • Description (optional, custom only): The agent’s role or summary (up to 1,000 characters). For a built-in agent, a preset description is shown instead.
  • Prompt (custom only): The specific instructions given to the agent (up to 10,000 characters).

4. Actions

The individual operations an agent performs in response to an incident. Up to 10 can be combined per custom agent.

Action typeSummaryRequired fieldsOptional fields
Annotate incidentWrites the AI-generated root-cause analysis into the incident’s activity history. Built-in agents only ever run this action.None (AI-generated content is appended automatically)—
Create taskFiles a task needed to investigate or respond to the incident.Title, severity, how to pick the assignee (same as the incident assignee / a specific member; for a specific member, also the assignee)Due date (days after the run; leave empty for none)
Update incidentUpdates one field on the incident that triggered the run (title, description, severity, assignee, or status; escalation is not available).Field to update, new value—
Update taskUpdates one field on a task you pick in advance (severity, assignee, or status). It doesn’t follow the task that triggered the run.Target task, field to update, new value—
Share the analysis resultNotifies the people you name (roles or members) of the recorded analysis result, in the bell and by email (the first 500 characters as a preview).How to pick the recipient, recipient roles or members—
  • Approval specification: A built-in agent’s “Annotate incident” action runs automatically with no approval step. Each action can be set to “Ask for approval before running.” Once an action requiring approval is reached, execution pauses as Pending until a Project Editor or higher approves or rejects it in the execution history or on the incident screen. If nobody approves it within 24 hours, it ends as Approval timed out. A Runbook suggestion always requires approval.

5. Execution rate limit

Prevents system overload or a burst of executions caused by rapid repeated runs.

  • Built-in agents: Users can’t change the execution rate limit.

  • Custom agents: You can set an individual execution rate limit per agent.

    • Max executions
    • Time period (minutes)

    If not set, no execution rate limit applies. Runs beyond the execution rate limit (automatic or manual) are skipped automatically.

  • Relationship to plan limits: Separately from the above, the monthly AI execution limit differs by contract plan (Starter: up to 10 per month; Standard and Enterprise: no limit, billed per execution; execution is not possible without a contract, or on an unsupported plan). Test executions (dry-run) are excluded from this limit.

6. Agent tools

Defines connections to external tools. The tools configured here (Runbooks, Sources, Access) are called autonomously by the agent only when it decides during analysis that it needs them — a configured tool is not necessarily called on every run.

  • Runbooks (custom only): Choose the Runbooks the agent can suggest as a response procedure. The agent decides whether to suggest one based on its analysis, and a human approves whether it’s actually run.
    • Interaction with actions: If the agent suggests a Runbook, the normal actions configured beforehand (such as creating a task) don’t run — the same applies if the suggestion is invalidated on the final check right before execution. Normal actions (up to 10) only run when no Runbook is suggested.
    • Execution mode constraint: Only “Suggest” mode (requiring human review and approval before running) is supported for a connected Runbook — there is no mode that runs it automatically without approval.
  • Sources (custom only): Choose the monitoring-event sources the agent can read. During analysis, the agent reads the most recent events ingested by the selected Source, limited by a time range and item count (read-only). Endpoints and other detailed connection settings are managed on the Sources screen in the sidebar.
  • Access (custom only): Choose the connection settings the agent uses to directly check the state of an external service. You can select only an Access entry that is [Active] and whose allowed operations are limited to read-only ones. An Access entry that includes write operations, has no operations selected, is [Pending verification] or [Suspended], or was activated by manual approval can’t be selected. During analysis, the agent autonomously chooses and calls read APIs within what that Access connection permits, to check current operational state (read-only; it can’t change any resource).
    • Region restriction: When linking a connection, you must specify the default region used for reads. You can also limit which regions can be read from; if you don’t, no region restriction is applied.
    • Registration limit: Agent tools (Runbooks, Sources, Access combined) can total at most 20 per custom agent. The same target can’t be registered more than once.
  • Policies using this agent: The list of Incident Policies assigned to trigger this agent automatically. Automatic execution requires the link on the policy side — if nothing is listed here, the agent will not start automatically.

7. Data settings

Defines the data the agent references during analysis, and the protection applied to that information.

  • Information passed automatically: Context that the system automatically gathers and always includes in the AI’s instructions (the prompt) at execution time.

    • The triggering incident itself: Information about the incident that triggered the run (including its full timeline and comments) is always passed automatically, regardless of any setting.
    • Related incidents (custom only): Pulls in a summary list of past incidents under the same Incident Policy. Setting the lookback period (minutes/hours/days) and max item count controls how much past-trend context the AI is given during analysis.
    • Detection events: Pulls in the actual events (alerts, etc.) that detected the incident, plus the content of the detection rule behind them. The max item count applies per incident, and the same limit applies to each past incident when related incidents are also included.
  • Data protection settings (PII protection): The protection level for personal information (address, email, username, phone number) exchanged with the AI. Built-in agents are configured per project, while custom agents are configured per agent (the default, if unset, is Unprotected). You choose one of three levels for both the input (before it reaches the agent) and the output (before results are saved or shown). Detection is not perfect, so avoid entering sensitive information where possible.

    • Input (before it reaches the agent): If personal information is detected, choose to stop it from being sent to the AI (block before it reaches the agent), send it masked (hide before it reaches the agent), or send it as-is (unprotected).
    • Output (before results are saved or shown): If the analysis result contains personal information, choose to block the write to the incident (block if it appears in the result), save/show it masked (hide the result), or save/show it as-is (unprotected).

    Particularly sensitive data such as credit card numbers or cloud credentials is always automatically protected by the system, regardless of this setting.

8. Execution, verification, history, and statistics

Specification for verifying agent behavior and reviewing past execution activity and statistics.

  • Manual execution: Runs an enabled agent immediately against a chosen incident. Both built-in and custom agents support this. Specifying an incident is required — there is no way to run without one. A disabled agent can’t be run.
  • Test execution (dry-run): A verification feature that exercises the same production code path while producing zero side effects — no incident annotation, task creation, or Runbook queuing. Dry-run history is not saved, and it doesn’t count toward the monthly billed execution count. A separate monthly test execution limit applies per plan. You pick one target incident to run against, and the result is shown on screen only (closing the dialog discards it).
  • Viewing execution history: View a list of past executions per agent.
    • List format: Paginated. The per-agent list doesn’t support filtering by date range or status.
    • Detail log fields: Trigger type (event-driven / manual), target incident (linked), execution status (Running / Pending / Completed / Failed / Skipped / Approval timed out / Rejected), start time, and duration. On failure you can see the error; if skipped due to a limit, you can see the reason.
  • Viewing total runs: You can see how many times an agent has run in total.
    • Total runs: The all-time number of times the agent has run.

Limitations

  • Built-in agent constraints: You can’t create additional built-in agents or delete them. You also can’t change the name, description, reasoning, trigger condition, or actions (only enabling/disabling and changing data protection settings are available). If you need custom reasoning or actions, create a custom agent instead.
  • No automatic Runbook execution mode: Built-in agents never suggest or auto-trigger a Runbook. A Runbook suggested by a custom agent always requires human review and approval — there is no mode where an external tool runs automatically without human approval.
  • Deleted data can’t be recovered: Deleting a custom agent is a complete deletion — the configuration can’t be restored afterward.
  • Custom agent creation and execution limits (plan-based): There is no plan-based limit on the number of custom agents you can create, but the monthly AI execution limit differs by contract plan (Starter: up to 10 per month; Standard and Enterprise: no limit).