Escalate to AI
1stLine by Burava AI Escalation lets responders ask a customer-owned AI assistant to investigate an Alert Instance.
Burava does not sell you inference and does not hide the assistant runtime. AI Escalation currently uses OpenCode as the assistant server runtime. You host the AI Escalation Controller in your own environment, build the controller image you want, install OpenCode yourself, and decide which tools, MCP servers, CLI commands, skills, agents, and notes the assistant may use for each matching rule.
AI Escalation is designed for assisted response, not automatic execution. The assistant can return an AI Response and Suggested Actions, but it cannot proceed with actual alert actions by itself and it cannot escalate to somebody by itself. A responder reviews the assignment and chooses whether to run any suggested action in 1stLine or directly from the alert destination.
What Burava provides
Burava provides the AI Escalation feature in 1stLine and publishes a minimal controller image.
- Public examples repository: burava-public/1stLine-ai-escalation
- Controller image package: 1stline-ai-escalation-controller
- Example Dockerfile: Dockerfile
- Example Docker Compose setup: docker-compose.yml
- Example Kubernetes manifests: example/k8s
- Example OpenCode config: opencode.example.json
- Example agents and skills: example/opencode
The published controller image is intentionally small. It contains the controller runtime. It does not include OpenCode, MCP servers, CLI tools, provider credentials, customer configuration, or the example agents and skills. You build your own image on top of the controller image and install exactly the tools you want the assistant to use.
The public examples show one possible image that installs OpenCode, selected MCP servers, common diagnostic CLI tools, and starter agents and skills. Those examples use generic instructions. Treat them as a starting point, then replace or extend them with your own operational runbooks, internal tools, and access model.
How AI Escalation works
At a high level:
- You create an AI controller Connection in AI Escalation.
- You run the AI Escalation Controller in your private network with the connection secret.
- You create one or more AI Escalation rules in Rules.
- Each rule chooses a scope, Conditions, enrichments, a timeout, a response character limit, and Allowed suggested actions.
- When a responder clicks Escalate to AI on an Alert Instance, 1stLine finds matching rules and prepares one AI assignment.
- 1stLine deterministically finds similar Alert Instances from the same organization and Alert Schema with the same fingerprint, then adds them to the assignment context.
- Matched rule enrichments, the current Alert Instance context, and similar alert context become one task for your controller.
- Your assistant returns an AI Response and optional Suggested Actions.
- A responder reviews the assignment in 1stLine and chooses whether to run any suggested action.
Matched enrichments can include:
- Context
- Skill
- Agent
- MCP
- CLI
- Note
Controller network model
The controller is built for private-network hosting. From a deployment point of view, treat it as a long-running outbound controller: it stays running inside your network, opens an outbound connection to 1stLine, and receives assignment notifications through that connection. The current public example configuration uses:
{ "firstline": { "baseUrl": "https://1stline.burava.com", "mailboxWebSocketUrl": "wss://1stline.burava.com/api/ai-escalation/mailbox" }}This means you do not need to publish an inbound webhook endpoint for 1stLine to call. The controller only needs outbound access to 1stLine, plus whatever internal systems your tools need to reach.
The controller also has local HTTP control endpoints for health, configuration inspection, local assignment triggering, and abort handling. If you enable those endpoints, keep them private and protect the protected routes with the configured control token.
OpenCode execution model
For each AI assignment, the controller orchestrates OpenCode instead of running an opaque Burava-hosted assistant.
The controller:
- Receives an assignment notification from 1stLine.
- Fetches the full assignment task by assignment UID.
- Creates an assignment workspace under the configured workspace root.
- Writes the raw task payload to
.firstline/task.json. - Writes the generated prompt to
.firstline/prompt.md. - Starts or leases an OpenCode server from the controller pool.
- Reads the current OpenCode config.
- Merges your baseline OpenCode config with assignment-specific enrichments from matched AI Escalation rules.
- Updates the OpenCode server config for the assignment.
- Starts an OpenCode session and submits the generated prompt.
- Waits for the assistant output.
- Validates
response.mdandsuggested-actions.json. - Sends the response text and structured suggested actions back to 1stLine.
- Runs
opencode export <sessionId>and stores the exported session JSON in the assignment workspace.
The OpenCode server pool is reconciled to active assignments + warm_opencode_servers. For example, warm_opencode_servers: 1 keeps one OpenCode server warm while the controller is idle, then starts more servers as assignments become active.
Similar alerts in assignment context
1stLine adds similar Alert Instances to the AI assignment before the controller receives it.
This is deterministic, not semantic search. 1stLine looks for Alert Instances that have:
- the same organization
- the same Alert Schema
- the same fingerprint
The current Alert Instance is excluded from the similar-alert list. The assignment includes up to 10 of the most recently created matching Alert Instances as same_pattern_alerts.
This helps the assistant compare the current alert with recent recurrences of the same alert pattern: previous status, recurrence count, resolved examples, repeated services, and prior response context. It also means good Fingerprint Fields matter. If fingerprints are too broad, unrelated alerts can be grouped together. If fingerprints are too narrow, genuinely repeated alerts will not appear as similar context.
Rule scope and overlap
AI Escalation rules are intentionally additive. More than one enabled rule can match the same Alert Instance.
Rule scope controls which alerts a rule is allowed to match before Conditions are checked:
- Global rules can match any Alert Instance in the organization.
- Schema rules can match Alert Instances created through the selected Alert Schema.
- Chain rules can match Alert Instances connected to the selected Escalation Chain.
After scope matching, 1stLine checks the rule Conditions. If a rule has no Conditions, it matches every Alert Instance inside its scope. If a rule has Conditions, all Conditions must match.
This means overlapping rules are normal. For example, a P1 payment alert can match:
- one Global rule that adds the standard incident triage skill
- one Schema rule for the payment alert payload
- one Chain rule for the payment on-call Chain
If those matched rules use the same controller Connection, 1stLine creates one AI assignment for that Connection. The assignment receives the merged enrichments from all matched rules, the combined Allowed suggested actions, the shortest assignment timeout, and the smallest response character limit. If matched rules use different Connections, 1stLine creates one assignment per Connection.
Use this model deliberately:
- put common, organization-wide guidance in Global rules
- put payload-specific runbooks in Schema rules
- put team or service ownership instructions in Chain rules
- use Conditions to prevent broad rules from matching alerts that do not need that context
Enrichments become OpenCode context and permissions
AI Escalation rules decide what 1stLine sends to the controller. When multiple rules match the Alert Instance, 1stLine merges the matched rule enrichments and alert context into one assignment.
Enrichments can include:
- Context: a link or file path to contextual material the assistant should read.
- Skill: a link or file path to a skill markdown file the assistant should fetch and load before working.
- Agent: a link or file path to an OpenCode agent markdown file the assistant should fetch and place into
.opencode/agents/before invoking it. - MCP: MCP server command or JSON configuration that should be allowed for the assistant.
- CLI: command-line tools that should be allowed for the assistant.
- Note: inline instructions or context written directly into the rule.
The controller turns those enrichments into assignment-specific OpenCode configuration and prompt instructions. MCP and CLI enrichments add permissions and configuration hints, but the binaries must already exist in your custom image.
Context, Skill, and Agent enrichments are references, not embedded files. Use Link when the assistant should fetch a remote file. Use File path when the file already exists in the controller environment or assignment workspace. In both cases, the assistant must have the required environment variables, credentials, network access, and authorization method to read the target file.
For Agent enrichments, 1stLine does not inject the agent definition into opencode.json. The assignment prompt tells the assistant to fetch the agent markdown and copy it into the OpenCode agents directory for the assignment. Per OpenCode’s official docs, agent permissions should live in the agent markdown frontmatter, including subagent permissions such as mode: subagent and permission.task or other permission rules. See OpenCode Agents and OpenCode Permissions.
If a single enrichment requires multiple files, add a Note enrichment that tells the assistant exactly which files to fetch and how they fit together. Do not hide multi-file instructions inside a vague Link or File path field.
What the assistant can and cannot do
The assistant can:
- inspect the Alert Instance context sent by 1stLine
- inspect similar alert context included in the assignment
- use the OpenCode tools, MCP servers, CLI commands, skills, agents, and notes that you installed and allowed
- write a customer-facing
response.md - write a structured
suggested-actions.json - suggest allowed actions such as resolving the alert or starting an Incident
The assistant cannot:
- receive the original destination webhook URL from 1stLine
- apply Alert Instance actions directly through the 1stLine UI
- escalate to another person by itself
- bypass the responder review step in 1stLine
- use tools that are not installed or allowed in your controller image
What AI can suggest
Rules decide which suggestions the assistant is allowed to return.
Available suggested action types are:
- Resolve
- Escalate further
- Escalate to
- Start incident
- Join incident
The assistant cannot apply those actions by itself from the 1stLine UI. It suggests them, and a responder runs them from the AI assignment page.
The controller submits only the response text and structured suggested actions. It does not execute the suggested actions, and it does not generate public callback links for the assistant to follow.
Forwarding AI responses
AI responses can be sent back to an alert destination when the Alert Schema has AI Escalation Mapping enabled.
Configure this on the Alert Schema under AI Escalation Mapping:
- Enable AI escalation mapping turns the forwarding payload mapping on.
- Title Field chooses where 1stLine writes the AI response title.
- Fallback Title Field gives 1stLine another title field to use when the preferred title is missing.
- Message Field chooses where 1stLine writes the assistant response text.
- Assignment Link Field chooses where 1stLine writes the AI assignment details link.
- Overrides can write additional mapped values into the forwarded payload.
When 1stLine forwards an AI assignment response, it builds a new payload from the original alert payload and the AI assignment result. The payload also includes an ai_escalation object with the assignment UID, Alert Instance UID, response text, assignment link, suggested actions, and response status.
Destination resolution for AI assignment response forwarding is:
- AI Override Forward To on the Alert Schema, when configured.
- the original alert
forward_todestination, when present. - Default Forward To on the Alert Schema, when configured.
Use AI Override Forward To when AI assignment updates should go to a different destination than the original alert. This override is used only for AI escalation updates and takes priority over both the producer forward_to value and Default Forward To.
Where to review AI Escalation
Use these pages:
- AI Escalation for Connection Overview, controller health, and Rules
- AI Escalation Assignments for recent assignment delivery, responses, suggested actions, and failures
- Alert Instances to start Escalate to AI and follow links back to AI assignments
Related pages
- Set Up AI Escalation Controller
- Create AI Escalation Rule
- Review AI Escalation Assignments
- MCP Server
- Alert Instances
OpenCode, Docker, Docker Compose, Kubernetes, GitHub, and other third-party tools mentioned on this page are third-party brands. Burava does not own, represent, or speak for those brands.