Skip to main content
Private beta: AI SRE is currently in private beta. Pro or higher accounts can apply for free beta access through the AI SRE private beta application form; after approval, Flashduty will add your account to the whitelist. Features and the UI may change during the beta.

​
Overview

Agent is the resource category that connects AI SRE to external agent ecosystems. The currently supported type is A2A (Agent-to-Agent) — a standard protocol that lets different agents call one another (more agent types may be added later). A2A works in two directions:

Outbound

Remote A2A agents registered in the list. AI SRE delegates tasks to them via the standard A2A protocol — for example, an external agent specializing in metrics analysis or integrated with an internal system.

Inbound

AI SRE itself is also an A2A agent and exposes an Agent Card. External A2A clients can fill in that Card URL to call Flashduty’s AI SRE in reverse, enabling incident / war-room integration and bidirectional event streams.
Delegation does not make you wait: after AI SRE hands a task to a remote agent, the conversation continues immediately, so you can keep working or delegate several tasks at once. When the remote agent finishes, its result appears in the conversation as a new message. Each A2A delegation appears in the conversation stream as a task card carrying an A2A badge, showing the remote agent name, task intent, run status (initializing / in progress / completed / failed / interrupted), and usage metrics such as tool call count, tokens, and elapsed time. Click the card to view the full delegation trace in the right-hand panel.
Instructions are the agent-selection signal. Before delegating, AI SRE sees a list of available agents where each entry is name: instructions. Do not treat this as one line of display copy; use the form’s multi-line editor to write prescriptive guidance (for example, “USE THIS FIRST for …” or “prefer-over-X when …”) that clearly states when to prefer this agent, what it excels at, and what it is not suited for. The more precise the instructions, the better AI SRE can delegate the right task to the right agent.
The A2A agent list and management entry point are on the Plugins → Agents page (menu tab labeled Agents).
Agents covers two distinct concepts. This page (Agents) currently manages A2A Agents (external agent-to-agent calls). The other concept is the Subagent — a platform-built-in task executor that AI SRE dispatches on demand within a session. Subagents have no create / edit entry point; you only observe their behavior in sessions. See “Subagent” below.

​
Subagent

A Subagent is a platform built-in task executor. During an investigation, AI SRE can dispatch a self-contained subtask to a Subagent that completes it independently — dispatch always goes through the single long-running tool agent_dispatch, rather than exposing a separate tool per Subagent. The platform ships several bootstrap Subagents that work out of the box:
NameRole
generalGeneral-purpose worker with full tool access. Use it to offload work whose intermediate steps would otherwise pollute the parent’s context (long reports, multi-file edits, end-to-end builds, repeated probing). Dispatch several in parallel for independent units of work
exploreRead-only investigator restricted to grep / glob / read; it cannot write or execute. Returns a compact summary rather than raw search output — ideal for locating evidence inside a codebase or knowledge dump
In the conversation: each dispatch also appears as a task card in the conversation stream and shares the same status lifecycle as an A2A delegation (initializing / in progress / completed / failed / interrupted). The difference is the badge — a Subagent task card carries an Agent badge, whereas an A2A delegation carries an A2A badge. Runtime limits:
  • Concurrency cap: a session runs at most 20 Subagents concurrently (TaskMaxConcurrentPerSession = 20). This caps how many run at the same instant, not how many a session dispatches over its lifetime — completing one frees a slot, so total work is unbounded. Dispatching past the cap errors (too many active subagents (… running, limit 20)), prompting the model to stop and wait for the running ones to finish before dispatching the rest.
  • Nesting depth: a dispatch chain nests at most 3 levels deep (TaskMaxNestingDepth = 3), preventing a Subagent from spawning itself indefinitely.
Subagents currently have no user-facing create / management UI. They are a built-in runtime capability: you can observe Subagent task cards and their sub-session traces within a session, but you cannot add, edit, or delete a Subagent the way you can an A2A Agent. This page (Agents) currently manages only A2A Agents.

​
Registering an Outbound A2A Agent

On the A2A Agents list page, click Add A2A Agent and fill in the form:
FieldTypeDefaultDescription
Namestring—A2A agent identifier (e.g., metrics-analyzer). Required
ScopeAccount / Team—Scope: Account (visible account-wide) or a specific Team (visible and editable only to members of that team). Required — see “Scope” below
Instructionsstring—The agent-selection signal shown to AI SRE. It is inserted into AI SRE’s system prompt and available-agent list to decide when to call this A2A agent. Required; write prescriptive guidance that explains when to use the agent, its capability boundaries, and when not to use it. Maximum 2,000 characters
Card URLstring—The Agent Card URL of the remote A2A agent, or just the service origin for agents that follow the default well-known location (for example, https://agents.example.com). If the URL includes a path, the platform reads that exact URL; if only an origin is provided, it resolves /.well-known/agent-card.json by A2A convention. Required. The platform validates that it is a legitimate http/https address and rejects loopback, private, link-local, or cloud-metadata addresses
Auth TypeenumnoneCredential type attached to outbound requests: none / bearer (Bearer Token) / api_key (custom Header + Key)
StreamingboolonWhether to communicate with the remote agent in streaming mode
User Auth ModeenumsharedSee “Auth Modes” below
Skip TLS certificate verificationbooloffShown only when the Card URL uses HTTPS. Enable only when the remote endpoint uses a self-signed certificate inside a controlled network; this skips certificate-chain and hostname verification
Allow OAuth discovery over HTTPbooloffRequired only when “Per-user OAuth” is selected and the Card URL is a non-local HTTP URL. Use only in controlled test environments; after you enable it, the Safari service can fetch OAuth metadata from that host

​
Using the FlashAI Template

FlashAI is the observability analysis product in the Flashcat / 快猫星云 family. It can also be connected as a remote A2A agent for AI SRE. On the A2A Agents page, expand the Connect FlashAI observability analysis panel to create an A2A agent from the FlashAI template. The FlashAI template is not a blanket rule that sends every observability question to FlashAI. It configures FlashAI as the delegation target for Flashcat / 快猫星云-originated alert and incident investigation. For alerts or incidents from Flashcat products such as Event Wall / 事件墙, Firemap / 灭火图, and Polaris / 北极星, AI SRE should prefer delegating analysis to FlashAI. The template prefills multi-line instructions. Its core routing rules are:
  • Prefer FlashAI when the user is investigating an alert, incident, fault, or alert group that clearly originates from Flashcat / 快猫星云.
  • Event Wall / 事件墙 alert events, incidents, and alert groups are positive routing signals.
  • Firemap / 灭火图 faults are positive routing signals, especially fields such as fault_type=firemap or rule_prod=firemap.
  • Polaris / 北极星 faults are positive routing signals, especially fields such as fault_type=polaris, rule_prod=polaris, or the internal marker rule_prod=northstar.
  • Flashcat alerts from n9e.alert should also be delegated to FlashAI when they carry fault metadata such as rule_prod, rule_config.detail_url, workspace, fault_type, fault_workspace, fault_detail_url, or fault_condition.
  • Do not use FlashAI by default for generic metrics, logs, traces, topology, or performance questions that do not include Flashcat / 快猫星云 alert context, a Flashcat URL, product markers, or the fault fields above. Use the available local tools or the customer’s actual observability source instead.
Prepare FlashAI first:
1

Confirm the version

FlashAI must be release-24 or later.
2

Configure FlashAI /config

Open /config in the FlashAI / Flashcat console (for example, https://demo.flashcat.cloud/config), add a2a_server_base_url, and set it to the current FlashAI access domain, for example https://demo.flashcat.cloud.
3

Confirm network reachability

If FlashAI uses a private-network address, only a BYOC Runner deployed in that network can reach it. If cloud Sandbox also needs to call FlashAI, use a publicly reachable domain and configure an allowlist as needed. This is the same network-reachability rule used for MCP SSE endpoints in Sandbox.
After FlashAI is prepared, enter the FlashAI domain in the panel (for example, demo.flashcat.cloud) and click Use this template. The page opens the Add A2A Agent form and prefills:
  • Name: generated from the domain, for example flashai-demo
  • Instructions: multi-line delegation guidance for AI SRE, explaining which Flashcat alerts/incidents should prefer FlashAI and which generic observability questions should not.
  • Card URL: generated from the domain:
https://demo.flashcat.cloud/api/fc-model/a2a/.well-known/agent-card.json
The template only prefills common values. You still choose the Scope (Account or Team) and configure authentication in the form. A2A agents can be installed multiple times for different scopes, so the FlashAI panel does not disappear just because one FlashAI agent already exists. Agent names must still be unique within the account; if the same FlashAI domain needs to be installed more than once, adjust the name in the form.
Do not remove the instructions generated by the FlashAI template unless you have more precise ones. Whether AI SRE proactively calls a remote A2A agent depends mainly on the selection signal provided by the name and instructions; when the instructions are too short or too generic, AI SRE may keep reasoning locally or incorrectly delegate ordinary metrics / logs questions to FlashAI.

​
Auth Modes

A2A agents support three credential-supply modes that determine how credentials are provided when different users call the same remote agent:
All users share the same credentials, configured under Auth Type (Bearer Token or API Key). Suitable for teams that share a single remote account.
Each user provides their own key on first use; the key is encrypted and stored at the account level. Configure the Header name (required), placeholder, and help link (optional) in the Key Schema to guide users on first call.
Each user authorizes via the OAuth 2.1 flow; an authorization window pops up automatically on the first call to this A2A agent, and credentials are stored per user after completion.
For security reasons, saved sensitive fields (such as token, api_key, and client_secret) are returned masked when read. When editing, leaving a sensitive field blank means “keep the current value” — not “clear it.” The stored credential is only overwritten when you explicitly change it.
Use HTTPS for per-user OAuth discovery whenever possible. Enable “Allow OAuth discovery over HTTP” for a non-local HTTP Card URL only in controlled test environments. If an HTTPS endpoint uses a self-signed certificate, enable “Skip TLS certificate verification” only temporarily and only inside a trusted network.

​
Inbound: Letting External Agents Call AI SRE

Expand the “Let External Agents Call Flashduty’s AI SRE” panel at the top of the A2A Agents page to get the Agent Card URL for this account’s AI SRE: 
https://api.flashcat.cloud/safari/a2a/ai-sre/agent-card
Add that URL to any A2A client to call Flashduty’s AI SRE agent via the A2A protocol. Authentication: add Fd-App-Key: <your app_key> in the request header (or use the ?app_key= query parameter). The capabilities declared on the Agent Card include:
Capability (Skill)Description
investigate_incidentEnd-to-end root-cause analysis for a Flashduty incident, correlating logs, metrics, and recent changes
analyze_logsQuery and summarize logs for a target service within a specified time window
analyze_metricsQuery and summarize metrics for a target service within a specified time window
The Agent Card also declares Flashduty’s “run options” A2A extension: callers can override incognito (whether to hide the session from the session list; hidden by default), visibility (private / account), and the environment (cloud / byoc and a specific environment_id) in message.metadata. This extension is optional — plain A2A clients can ignore it and call normally.

​
Incident and War-Room Integration

When a session enters via an incident route (e.g., AI SRE is triggered from an incident or war room), the platform binds the corresponding incident to the session and brings it in as context, anchoring troubleshooting to the correct incident from the start. Based on this, AI SRE can use built-in skills during the conversation to further act on the incident — reading incident details, querying the timeline, creating / viewing war rooms, linking changes, and more. For automatic war-room diagnosis on the IM side, see IM Integration.
Automatic incident integration for A2A is currently supported conceptually and is under active development: automatic incident binding is not yet fully available, and bidirectional event streams across agents will be progressively completed with each release. Do not treat this as a fully available capability — during private beta, only features that have been explicitly enabled should be relied upon.

​
Creating and Managing

The full lifecycle of A2A agents is managed on the Plugins → Agents page.
Click Add A2A Agent, fill in the name, scope, instructions, Card URL, auth settings, and save. You must select a definite scope (account or team) before submitting — the submit button remains disabled until a scope is chosen.
Use the toggle in the list to switch an A2A agent’s enabled state. Only enabled agents appear in AI SRE’s available-agent list and can receive delegated tasks; disabling one makes it immediately invisible to delegation.
Click any row in the list to open the form, where you can view and edit the name, instructions, scope, Card URL, auth configuration, streaming, and auth mode. The form is read-only when you do not have edit permission.
Remove an A2A agent from the current scope. Active sessions that delegated to it will fail. Deletion requires confirmation.
The scope filter bar at the top of the list lets you switch between “All”, “Account only”, and “Specific team”, making it easy to focus on relevant resources when managing many. Each row also has a label showing its scope (account / team name).

​
Scope

A2A agents share the same two-level scope model as other resources (skills, Knowledge Packs, MCP, environments), divided into account level and team level:
ScopeVisibility
Account levelVisible to all members in the account
Team levelVisible only to members of that team
Edit permissions: the account owner or account admin can edit any agent; team members can edit team-level agents in their own team; there is no creator-retains-rights exception. When you do not have edit permission, the corresponding row in the list is read-only. Create and reassign: to create a new team-level agent, you must belong to the target team; account-level creation is limited to the account owner or admins. When editing an existing agent, the account owner or admins can move it to any team to recover resources left behind by empty teams or departed members; regular members can move it only to teams they belong to. Runtime visibility: at session start, AI SRE’s available-agent list shows only account-level resources plus resources belonging to the team bound to the current session (e.g., the team carried in by an incident / war room, or explicitly selected in the UI). A team’s skills, MCP servers, and A2A agents are only mounted into the current session on demand after the agent reads that team’s knowledge during an investigation. The account is the only security perimeter at runtime; team is simply an ownership and editing tag.

Console

Observe A2A delegation task cards and their sub-session panels within a session.

MCP (External Tools)

Connect external tools to agents to expand their capability boundary during tasks.

Manage Knowledge

Use DUTY.md and Knowledge Packs to provide agents with team context and troubleshooting experience.

IM Platform

@ AI SRE in an IM group and learn about automatic war-room incident diagnosis.

Overview

Understand AI SRE’s overall capabilities and positioning.