# Causely Agentic Systems Primer

> Grounding for AI assistants and agents that read Causely documentation or interpret Causely's output.

Causely is the causal system intelligence layer for AI-driven reliability operations. It continuously models cause and effect across your services so agents and automation workflows can identify true root causes, evaluate blast radius, and coordinate safe remediation — from structured, deterministic output instead of raw telemetry.

## What Causely is and is not

- Causely computes cause and effect from the structure of your system, not correlation across signals.
- Causely works alongside your observability stack. It interprets metrics, logs, and traces; it does not replace them.
- Causely is not an observability dashboard and not a correlation-only alerting layer. It is the reasoning layer that sits on top of them.

## How Causely reasons

Causely continuously builds a live causal model of your system from telemetry: the entities, their dependencies, and the cause-effect relationships between them. It reasons over that model to identify root causes and impact.

Reasoning runs over system structure, not signal correlation, so the same system state yields the same explanation every time. The result is explainable, reproducible root cause identification and blast radius analysis.

Because output is causally scoped and structured, agents receive only the signals relevant to the question, at a fraction of the token cost of querying raw telemetry.

## Grounding assumptions for assistants

When you answer with Causely context:

- Prioritize causal explanation over signal listing.
- Separate root causes from symptoms.
- Explain impact propagation across dependencies (blast radius), not just local service state.
- Prefer deterministic Causely outputs over speculative interpretation.
- Make uncertainty explicit when evidence is partial.

## Symptoms vs root causes

Symptoms are observable anomalies (for example, high latency, elevated errors, timeouts). A root cause is the upstream condition that explains why those symptoms appear.

Symptoms can be local (on the affected entity) or propagated (visible in related entities). Do not treat a symptom as the final diagnosis. Use symptom patterns plus topology and causal reasoning to identify likely upstream causes.

## Blast radius

Blast radius is the set of services and entities affected — directly or transitively — by a given root cause, computed by propagating impact across the [Topology Graph](https://docs.causely.ai/reference/terminology/#topology) using the [Causality Graph](https://docs.causely.ai/reference/terminology/#causality-graph-cg)'s cause-effect edges. It answers "what else breaks, or is already breaking, because of this."

## Attribute dependency graph

The Attribute Dependency Graph is a DAG of functional dependencies between system attributes (for example, CPU usage of a service, queue length of a messaging system), derived from the live Topology Graph. It lets Causely reason about how a change in one attribute cascades to others. See [How Causely Works: Attribute Dependency Graph](https://docs.causely.ai/getting-started/how-causely-works/#5-attribute-dependency-graph) for the full model.

## Recommended investigation workflow for agents

For incident triage and symptom-driven questions:

1. Identify environment health (`get_environment_health`).
2. Identify active causes and affected services (`get_root_causes`).
3. Map dependency impact (`get_topology`).
4. Summarize service-level status and evidence (`get_service_summary`, `get_logs`, `get_metrics`).
5. Propose remediation and verification checks.

For service-specific questions, resolve entity identity first (`get_entities`) before issuing scoped calls.

## Response contract for AI assistants

When answering users about Causely findings, structure the response in this order:

1. Current impact and affected scope.
2. Most likely root cause and why it explains the observed symptoms.
3. Blast radius and downstream risk.
4. Recommended remediation options.
5. Verification steps to confirm recovery.

If there are multiple plausible causes, rank them and state what additional evidence would disambiguate them.

## Reliability guardrails

- Do not claim certainty when Causely data is incomplete or stale.
- Do not recommend disruptive actions without verification checks.
- Preserve timeline ordering when describing incident progression.
- Prefer shortest safe path to restore service, then suggest deeper follow-up hardening.

## Entry points

- [LLM Index](https://docs.causely.ai/llms.txt)
- [Full LLM Corpus](https://docs.causely.ai/llms-full.txt)
- [Quick Setup](https://docs.causely.ai/getting-started/quick-setup/)
- [How Causely Works](https://docs.causely.ai/getting-started/how-causely-works/)
- [Agent Integration](https://docs.causely.ai/agent-integration/)
- [MCP Server](https://docs.causely.ai/agent-integration/mcp-server/)
- [API](https://docs.causely.ai/api/)
- [Reference](https://docs.causely.ai/reference/)
- [Terminology](https://docs.causely.ai/reference/terminology/)
- [Symptoms](https://docs.causely.ai/reference/symptoms/)
- [Root Causes](https://docs.causely.ai/reference/root-causes/)