Skip to main content
Private beta: AI SRE is currently in private beta and available to invited accounts only. To join the whitelist test, contact the Flashduty sales team to request access; features and the UI may change during the beta.

​
Overview

A Knowledge Pack 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 follows its references to fetch related files on demand — bringing your team’s incident-handling experience, naming conventions, and system topology into every diagnosis. Each target (account or team) can own at most one Knowledge Pack:
  • Account-level knowledge is visible to all agents within the account.
  • Team-level knowledge is loaded only in sessions associated with that team, and is visible only to members of that team.
Knowledge Packs are one type of AI SRE resource and follow the same two-level scope model. The scope rules for other resources (Skills, MCP, Agents, Environments) are identical.
Knowledge Pack 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 entire Knowledge Pack. It is the catalog itself — the agent reads DUTY.md in full, then fetches other files on demand via @filename references. The system does not attach a separate file listing alongside DUTY.md; the catalog is the body. References use the @<filename> style, where the filename points to another file within the same pack (flat naming, no directory hierarchy): 
# On-Call Knowledge Overview (DUTY.md)

## Service Catalog
Our core services and owners: @services.md.

## Common Incident Handling
- API 5xx spike: see @runbook-api-5xx.md
- Database connection pool exhaustion: see @runbook-db-pool.md

## Clusters & Environments
Production cluster topology and access: @cluster.yaml.
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):
ConstraintValueNotes
Allowed extensions.md .yaml .yml .json .txt .shOther extensions are rejected
Per-file size limit1 MiBFiles exceeding this cannot be saved
Per-pack size limit5 MiBThe usage bar in the console reflects this quota
File count limit100No new files can be added once the limit is reached
Directory hierarchyNot allowedFilenames must be flat — no / or subdirectories
Dot filesNot allowedFilenames cannot start with .

​
Create & Edit

Go to the Knowledges management page to create, edit, enable/disable, or delete Knowledge Packs for your account or teams. The list shows each pack’s Name / Scope / Files / Status / Actions, and a scope filter at the top lets you switch between account and team views.
1

Create a Knowledge Pack

Click New Knowledge Pack. In the dialog, enter a Name (optional — defaults to the target label if left blank) and choose a Scope: account or a specific team. Each target can own only one pack; targets that already have a pack are hidden from the dropdown.
2

Edit Files

Click any row in the list to open the inspector. The left panel shows the file tree; the right panel is an inline editor. Click New File to enter a filename (e.g., runbook.md), or use Upload to import a local file. Markdown files support both Preview and Source views. Click Save after editing.
3

Monitor Usage

The Usage bar on the left updates in real time, showing current usage against the 5 MB quota. The bar turns red when you approach the limit, prompting you to clean up or split files.
4

Enable / Disable / Delete

Use the toggle in the list to enable or disable an entire pack. When disabled, files are preserved but the pack is no longer loaded into AI SRE sessions. Delete removes the pack and all its files permanently.
Reference consistency checks: when you save a file, any @reference pointing to a file that does not exist in the pack returns a non-blocking unresolved-reference warning (the save still completes). When you delete a file that is still referenced by other files, a still-referenced conflict prompt appears first — you can choose to force delete.
The agent can also maintain the Knowledge Pack conversationally during a session — for example, “add a runbook”, “update services.md”, or “record this incident pattern”. It will read, edit, and save directly within the scope of the current session, without you needing to leave the chat. Structured initial onboarding is handled by a dedicated guided flow, not the inline editor.

​
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 (no separate file list attached). Sessions bound to a team load both the account-level and that team’s DUTY.md; sessions not bound to a team load only the account-level one.
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

When cross-team troubleshooting is needed, the agent reads another team’s knowledge. The system then mounts that team’s full knowledge bundle (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.
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.

​
Scope & Visibility

Every Knowledge Pack has a scope: account-level (visible across the entire account) or team-level (visible only to members of that team).
DimensionAccount-levelTeam-level
VisibilityAll agents / sessions within the accountSessions and members of that team only
Edit permissionAccount Owner or account adminMembers of that team, or Account Owner / admin
Loaded in sessionAll sessionsOnly sessions bound to that team
Readable at runtimeEntire accountEntire account (mounting occurs on read)
Edit permissions: the Account Owner or account admin can edit any Knowledge Pack; team members can edit their team’s team-level pack; 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. Runtime visibility: at session start, only account-level 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. Other teams’ knowledge is mounted on demand mid-session, when the agent reads that team’s DUTY.md.
The account is the only security boundary at runtime; team is an “editing / ownership” tag, not a “runtime readable” boundary. This means any session within the account can read and mount knowledge from any other team in the same account — this is the foundation for cross-team collaborative troubleshooting. If certain knowledge is sensitive even to other teams within the account, evaluate carefully before including it in a Knowledge Pack.
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., runbook-api-5xx.md, runbook-db-pool.md), using clear filenames as semantic indexes. Since packs use flat naming (no subdirectories), filename prefixes are your “directory structure.”
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 the account-level pack (naming standards, general troubleshooting methods, platform access). Put team-specific service catalogs, on-call runbooks, and upstream/downstream info in team-level packs. 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 Pack — creating a continuous learning loop.

Skills

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

MCP (External Tools)

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

Console

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