> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vexlo.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Introduction

> What Vexlo records, the three processes that get it from your code to a reader, and where to go next.

Vexlo records how code actually ran: one execution graph per request, at function level,
carrying the real inputs, outputs, and errors each call saw. That is ground truth about a
production run rather than a reconstruction of one. People read it in a web UI, AI agents read
it through an MCP server, and both read the same `/v1` API underneath.

## What runs where

The Python SDK runs inside your own process, where you [mark](https://docs.vexlo.ai/sdk/mark-functions.md) the functions
you want recorded. A marked call appends its records to the SDK's in-process outbox and returns;
the SDK's writer thread writes them to a spool directory on that host. The relay daemon, one per
host, tails that directory and posts batches to the Vexlo server, so a process running the SDK
never blocks on network I/O to get a record captured. The server ingests those records, owns
storage, and serves them over the `/v1` API and the UI embedded in the same binary. Nothing reads
execution data any other way: the UI and the MCP server are both clients of that API.

## What it does not touch

Vexlo injects and modifies nothing on an outbound request, patches no HTTP client, and shares no
global state with anything else running in the process. Nothing a team already runs has to be
removed or reconfigured first.

Nothing is recorded until you mark it, and what is kept from a marked call is subject to the
service's [capture policy](https://docs.vexlo.ai/server/capture-policy.md). The scope stops there: execution data for
debugging code, reading it, and changing it. Dashboards, alerting, and metrics are out.

## Where to go next

| Page | What it gives you |
| - | - |
| [Quickstart](https://docs.vexlo.ai/quickstart.md) | The server, a demo service, and the relay daemon on one machine, then a trace read back over the API. |
| [The problem](https://docs.vexlo.ai/concepts/the-problem.md) | Why recorded signals run out at incident time, for people and for agents. |
| [Logs, spans, and execution graphs](https://docs.vexlo.ai/concepts/logs-spans-execution-graphs.md) | What each one records, and the question each one answers. |
| [The execution graph](https://docs.vexlo.ai/concepts/execution-graph.md) | The primitive, the words for it, and one real trace in full. |
| [Use cases](https://docs.vexlo.ai/concepts/use-cases.md) | Six questions and what you read to answer each. |
| [Glossary](https://docs.vexlo.ai/glossary.md) | One term per concept, with the synonyms this site does not use. |


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.