Knowledge
Knowledge is Firetiger’s accumulated understanding of your systems. As agents investigate, query, and interact with your infrastructure, they build up a structured body of knowledge that makes every subsequent interaction smarter. This knowledge is shared across all agents in your organization.
You don’t need to seed knowledge manually — it’s built automatically from your telemetry. But you can supplement it with human-authored context via Firetiger.md.
Services
A service represents a component in your system — an API server, a background worker, a database, a message queue. You can browse your discovered services at /knowledge/services.
Firetiger discovers services from your telemetry and maintains a profile of each one, including:
- A description of what the service does and how it fits into your architecture
- The telemetry patterns it emits — log attributes, metric names, trace spans
- Correlation IDs used to track requests through or across the service (e.g.,
request_id,trace_id,batch_id) - Dependencies on other services
- Known error patterns and expected anomalies (so agents don’t raise false alarms on, say, expected timeout errors)
- Tags for environment, region, version, and other metadata
When an agent investigates an issue, it uses service definitions to understand the architecture around the problem — what services are involved, how they communicate, and what telemetry to look for.
Flows
A flow describes an end-to-end process that spans multiple services — something like “user authentication,” “order processing,” or “data ingestion pipeline.” You can browse your flows at /knowledge/flows.
Where services describe individual components, flows describe how those components work together to accomplish something.
Each flow contains:
- A set of key identifiers — the correlation IDs that tie telemetry together across the flow (e.g.,
user_id,order_id,session_id) - A sequence of steps, each documenting which services are involved, what telemetry signals to expect, and how to query for the relevant data
- Operational notes — deployment quirks, timing variations, seasonal behaviors, and other real-world context
Flows are what let agents reason about cross-service behavior. When investigating a latency spike in your checkout process, an agent can look up the “checkout” flow to find the services involved, the correlation IDs to thread through, and example queries that have been useful in the past.
Firetiger maintains a curated set of flows (typically a few dozen) and actively consolidates or removes stale ones to keep the set focused and useful.
Customers
If your system serves multiple customers or tenants, Firetiger can track them as first-class knowledge. You can browse your customers at /knowledge/customers.
A customer profile includes:
- How to identify the customer in telemetry — which fields, which tables, what extraction patterns
- A workload summary describing the customer’s usage patterns and volume
- An operational runbook with customer-specific investigation guidance
This lets agents quickly scope queries to a specific customer when investigating issues, and understand whether a customer’s behavior is normal for them.
Notes
Notes are Firetiger’s general-purpose memory, organized by domain. You can browse them at /knowledge/notes.
They accumulate insights that don’t fit neatly into services, flows, or customer profiles — things like common debugging techniques, system-wide operational patterns, or recurring themes across investigations.
Notes are the primary way knowledge persists between agent sessions. When an agent discovers something useful during an investigation, it records the finding. Background agents periodically review these findings and incorporate the durable ones into the shared notes.
Known Issues
Known issues are documented problems that Firetiger is tracking. Each has a title, detailed context, and a status: active, resolved, or muted. They can be linked to specific services, objectives, and external tickets.
When an investigation detects a pattern matching a known issue, the agent can reference it rather than re-diagnosing from scratch. When an issue is resolved, agents verify the fix by checking telemetry for evidence that the problem has stopped. See Issues for more detail.
How knowledge is built
Firetiger runs a set of background researcher agents that periodically discover and maintain knowledge. These don’t count against your agent usage.
- A service researcher investigates telemetry to discover and document services, their dependencies, and their telemetry patterns
- A flow researcher discovers end-to-end processes and maintains the curated set of flows
- A customer researcher identifies top customers and their workload characteristics
- A synthesis agent reviews all recent agent sessions to extract durable insights — user corrections, consensus patterns across multiple investigations, and repeated mistakes that indicate a knowledge gap
Knowledge also grows organically during regular investigations. When an agent discovers something new about your systems, it records the finding. The synthesis agent picks it up on its next pass and incorporates it into the shared knowledge base.
User corrections always take precedence over automatically discovered patterns. If you correct an agent during an investigation — “that’s not an error, those timeout logs are expected” — that correction is preserved and propagated so no agent makes the same mistake again.
Firetiger.md
Firetiger.md is a human-authored markdown document where you can provide foundational context about your organization that doesn’t need to be discovered from telemetry. Every agent reads it at the start of every session.
This is a good place to put things like:
- What your company does (“We’re an authentication provider”)
- High-level architecture (“We run three main services: API, Worker, and Scheduler”)
- Business context (“Our peak traffic is during US business hours”)
- Naming conventions (“We call our internal customers ‘tenants’”)
- Operational preferences (“Always check the audit log before escalating access issues”)
You can edit Firetiger.md at /knowledge/firetiger. It’s intentionally simple — just a markdown file — so it’s easy to keep up to date.
Knowledge and privacy
Knowledge is scoped to your organization. It’s never shared across organizations, and agents in one organization cannot see another organization’s knowledge.
Automatically discovered knowledge is derived solely from your own telemetry and agent interactions. Human-authored content in Firetiger.md and user corrections during investigations are marked as such and given priority over automatic discoveries, so they’re never silently overwritten by an agent.