# Ace documentation

> Ace is an AI incident response team for your production systems. It investigates incidents across your infrastructure, telemetry and code, proposes fixes under your approval policy, verifies recovery and remembers what it learned.

Source: https://tryace.dev/docs

Ace is an AI incident response team. When something breaks in production, Ace opens an incident, investigates it across the tools you connect and explains the root cause with the evidence for and against it. It then proposes a fix, such as a pull request, a rollback or a Kubernetes restart, which runs under your approval policy. After the fix ships, Ace checks that the original alert recovered and remembers what worked for next time.

## How it fits together

1. An alert from your monitoring tools, an Ace HTTP check, a metric watch or an early warning opens an incident on the affected [workload](https://tryace.dev/docs/concepts/how-ace-works), so an alert storm on one workload becomes a single incident.
2. The investigation reads the metrics, logs, traces, cloud resources, recent deploys and code connected to that workload, and pulls similar past incidents from [memory](https://tryace.dev/docs/concepts/memory).
3. You get a root cause in the incident's Slack thread and on the incident page, with a confidence level, the evidence for and against it, and what's still unknown.
4. Ace proposes a fix as a pull request, a rollback or an operation, and by default a person approves each change. Changes run automatically only where Ace has [earned autonomy](https://tryace.dev/docs/concepts/actions-and-approvals#earned-autonomy) under your action policy, and your [operating rules](https://tryace.dev/docs/concepts/operating-rules) set how your team wants the work done.
5. Once the fix is deployed, verification watches the original alert until it's healthy. If the problem comes back, the incident reopens.

Investigation is read-only. Ace changes a system only if you gave it a credential that can write there and an admin turned on actions for it, and even then code and infrastructure changes need approval unless your policy lets Ace act on its own.

Updates that only change what your team sees in a monitoring tool, such as an annotation or a downtime on the monitor that paged, run on their own once you allow them. Each one can be undone. See [Actions and approvals](https://tryace.dev/docs/concepts/actions-and-approvals).

## Where to start

  - [Quickstart](https://tryace.dev/docs/quickstart): From a new workspace to your first investigation.
  - [How memory works](https://tryace.dev/docs/concepts/memory): What Ace remembers, how it recalls it, and how it fades.
  - [Integrations](https://tryace.dev/docs/integrations): What Ace reads and can change in each tool, and how to connect it.
  - [Ace MCP server](https://tryace.dev/docs/mcp): Give coding agents read-only incident context.
  - [Actions and approvals](https://tryace.dev/docs/concepts/actions-and-approvals): What Ace can change, and who approves it.
  - [Security and data](https://tryace.dev/docs/security/security-and-data): What Ace reads and keeps, and how it's protected.

## If you're an AI agent, start here

Read [`/llms.txt`](https://tryace.dev/llms.txt) first, since it lists every page in these docs with a one-line summary. To fetch a page as Markdown, add `.md` to its URL, for example [`/docs/concepts/memory.md`](https://tryace.dev/docs/concepts/memory.md), or send `Accept: text/markdown`. [`/llms-full.txt`](https://tryace.dev/llms-full.txt) has every page in one file.

To read Ace incidents, lessons and operating rules while you work on code, connect to the [Ace MCP server](https://tryace.dev/docs/mcp).

## Get help

Our SOC 2 Type II report, policies and subprocessors are in the [Trust Center](https://trust.vratix.com). For anything else, [book a call with our team](https://tryace.dev/book-demo).