Skip to main content
AI SRE is available to accounts on an On-call Pro or higher subscription, with no application needed. Starting September 16, 2026, 08:00 Beijing time, it must be activated in the console before use and is billed on actual usage; see billing terms.

​
Overview

Knowledge is the operational knowledge you hand to AI SRE: a DUTY.md file plus a collection of runbooks, FAQs, service catalogs, cluster configs, and similar files. When a session starts, the agent reads DUTY.md first, then opens other files as needed — bringing your team’s incident-handling experience, naming conventions, and system topology into every diagnosis. Console entry: AI SRE → Customize → Context → Knowledge. Memory, in the same group, is a separate page and is managed separately. An account has at most one Shared knowledge, and each team has at most one team knowledge:
  • Shared (account-level) knowledge is visible to all agents within the account.
  • Team-level knowledge is loaded only in sessions of that team.
Knowledge is one type of AI SRE resource and follows the same two-level scope model. The scope rules for other resources (Skills, MCP, Agents, Environments) are identical.
Knowledge content is used to refine the agent’s domain context (persona, methodology, system knowledge), but it does not override the system’s safety and behavioral guardrails. If a piece of knowledge instructs the agent to bypass security rules, it is treated as unauthorized content and ignored — not as a higher-priority instruction.

​
DUTY.md Structure

DUTY.md is the table of contents entry point for the whole knowledge and is loaded automatically in every session. The agent reads DUTY.md in full, then fetches other files on demand via @filename references. The system attaches no file listing beside DUTY.md: knowledge files sit under the knowledge/ directory of the session workspace, and the agent finds them with ls / glob / grep the way it browses a code repository, so files that DUTY.md does not reference can still be found. If a scope has no DUTY.md yet, that scope is not silently skipped: the system tells the agent that this scope has no guide and which directory holds its files, and requires it to list that directory and read the relevant files before doing substantive work. References use the @<path> style, where the path points to another file within the same knowledge. Subdirectories are supported (e.g., @runbooks/api-5xx.md):
After reading DUTY.md, the agent decides which @references to expand based on the current incident, then reads the corresponding files — substantive content lives in the referenced sibling files; DUTY.md carries only the link list.
This layered @reference architecture keeps DUTY.md concise and readable. Think of DUTY.md as a map, with runbooks, service catalogs, and configs as the detail pages it points to. The agent doesn’t need to load every file into context at once — it only expands the branches relevant to the current incident.
File constraints (enforced at create and edit time):

​
Maintain it in the console

Go to AI SRE → Customize → Context → Knowledge. Each row of the list is one knowledge, labeled by scope (“Shared” or the team name), with its file count, DUTY.md status, and last edit time. The DUTY.md status is one of Not created, Up to date, or Needs refresh · N changes since (other files changed after DUTY.md was written). Click Create to add knowledge for the Shared scope or for a team you belong to; when the account and every team available to you already have one, the button is disabled. When no knowledge exists yet, the page shows a starter instead: Set up AI-SRE opens a new chat that runs /init, and Upload existing docs opens a new chat with the attachment picker open. Click a row to open that knowledge:
  • The file tree is on the left. DUTY.md is pinned at the top with an Auto-loaded tag; the other files are listed under “Other files · Read on demand”. Without a DUTY.md, this spot shows “Not created” and a Let AI generate it button. Above the tree are the usage (used / 5 MB and the file count) and the New file and Upload entries.
  • The file body is on the right. Click Edit to change the open file, switch between Preview and Source, and click Save to write it.
  • Upload: any UTF-8 text file goes straight in, a whole folder can be uploaded at once, and you are asked before a file with the same name is overwritten. PDF, Word, HTML, and similar documents cannot go in directly; click Analyze in chat and the AI reads the document, turns it into Markdown files, and saves them after you confirm.
Files still have to meet the limits above: plain text, at most 1 MiB each, and at most 5 MiB and 100 files in one knowledge. An @reference can name a file that is not in the knowledge, and the save still completes.

​
Ask AI to change it

Below the body is an input box (placeholder: “How should the AI change this knowledge? e.g. add an OOM troubleshooting runbook”). Write what to change and send it: the console opens a new chat whose input already holds a reference to this knowledge and your request; for team knowledge, the chat switches to that team. Once sent, the AI first explains in text which files it will change and how, and saves only after you agree. The page itself offers no change preview or item-by-item review. Let AI generate it and Let AI update it (below) follow the same flow: they move to a new chat with the request already written.

​
When DUTY.md needs a refresh

If other files change after DUTY.md was written, a notice appears above the file tree: “Changes since DUTY.md was written: N. It may need updating.” With edit permission, two actions sit below it:
  • Let AI update it: moves to a new chat and has the AI update the DUTY.md index against the current files; the change is confirmed with you first.
  • Still accurate: confirms DUTY.md is still correct. The notice disappears until the next file change.
The assistant can also maintain the knowledge for the current session’s scope, for example “add a runbook” or “update services.md”. It reads, edits, and saves after you confirm.

​
How the Agent Uses Knowledge

Knowledge is not all loaded at once — it follows a catalog-first, expand-on-demand pattern:
1

Session start: load the catalog

When a session starts, the system loads the current scope’s DUTY.md into the session, with no file list attached. Sessions bound to a team load both the Shared-scope and that team’s DUTY.md; sessions not bound to a team load only the Shared-scope one. If a scope has no DUTY.md yet, the system requires the agent to list that scope’s directory and read the relevant files before doing substantive work.
2

Follow references to read files

After reading DUTY.md, the agent decides which @references to expand based on the current incident, then reads the corresponding knowledge file for the specific content.
3

Mount another team's knowledge on demand

In a personal session not bound to a team, the agent can read the knowledge of teams the session creator belongs to. On that read, the system mounts that team’s full knowledge (DUTY.md, runbooks) along with its Skills and MCP into the current session, persisting for the remainder of the session. Each team is mounted at most once per session. A session bound to a team cannot read other teams’ knowledge.
Cross-team mounting is triggered only when the agent explicitly reads a team’s knowledge — it cannot be accidentally triggered by a vague file traversal. Once mounted, that team’s knowledge, Skills, and MCP remain available for the rest of the session.
If knowledge fails to load into the current session, a warning banner appears above the message list: “Knowledge failed to load - AI-SRE may not have access to DUTY.md and runbooks in this session.”, along with a Retry button that re-attempts the load. Until the retry succeeds, the agent may be unable to read DUTY.md and runbooks in that session.

​
Scope & Visibility

Every knowledge has a scope: Shared (account-level, visible across the entire account) or team-level. Edit permissions: team knowledge can be acted on only by members of that team — organization admins must join the team first; Shared knowledge can be acted on only by the Account Owner or admins; there is no “creator retains extra rights” rule. The console grays out rows the current user cannot edit, and disables toggles and action buttons when you lack edit permission. Create and reassign: to create new team knowledge, you must belong to the target team; Shared-scope creation is limited to the Account Owner or admins. When editing existing knowledge, 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. Promoting existing knowledge to Shared scope (Set to Shared) carries the same gate as Shared-scope creation: only the Account Owner or admins can do it — a regular member cannot self-serve this even for their own team’s knowledge. Runtime visibility: at session start, only Shared-scope resources plus resources belonging to the team bound to the current session are loaded. The bound team is either explicitly specified or derived from the team associated with the war-room incident. Whether a session can mount other teams’ knowledge mid-session depends on the session type:
A session bound to a team can use only the Shared knowledge and that team’s knowledge; reading another team’s knowledge is refused, for Account Owners and admins as well. A personal session not bound to a team can mount the knowledge of teams the session creator belongs to on demand; reading a team the creator does not belong to returns the same error as “file not found”. For cross-team troubleshooting, ask the other team to make the relevant knowledge Shared, or do the combined analysis in a personal session.
This two-level scope model applies uniformly to all resources within the account (Skills, MCP, Agents, Environments).

​
Best Practices

Keep DUTY.md to link lists and one-line descriptions only — all substantive content goes into the sibling files it @references. This keeps the catalog concise and readable, and lets the agent expand only the branches relevant to the current incident, avoiding irrelevant content consuming context.
Focus each runbook on one incident type or one service (e.g., runbooks/api-5xx.md, runbooks/db-pool.md), using clear paths as semantic indexes. Subdirectories are supported — you can group files by service or topic (e.g., runbooks/, configs/).
Service catalogs, cluster topologies, and threshold configs are well-suited to .yaml / .json (e.g., services.md, cluster.yaml), so the agent can both read and parse them directly. Script snippets can use .sh.
After adding or renaming a file, update the @references in DUTY.md and any related files. The unresolved-reference warning on save and the still-referenced prompt on delete help you catch broken links promptly.
Put cross-team conventions in Shared knowledge (naming standards, general troubleshooting methods, platform access). Put team-specific service catalogs, on-call runbooks, and upstream/downstream info in team knowledge. Sessions bound to a team receive both.
When troubleshooting surfaces new handling experience, just ask the agent to “add a runbook” or “record this incident pattern.” It will read, edit, and save within the current scope, writing the experience back into the knowledge — creating a continuous learning loop.

Skills

Encapsulate reusable diagnostic workflows as Skills, sharing the same scope model as Knowledge.

MCP (External Tools)

Connect external systems via MCP so the agent can call your tools and data.

Learn about Memory

Preferences, procedures, facts, and lessons the AI notes in conversations, managed separately from knowledge.

Console

Learn how sessions bind to teams and how knowledge is read and mounted during a session.