# Latitude product reference ## Summary Latitude is an open-source, MIT-licensed platform for monitoring and improving production AI agents. It captures production agent telemetry, helps teams discover recurring failures, turns those failures into tracked signals, dispatches a customer-controlled coding agent with the relevant evidence, and verifies fixes using production-derived tests and continued monitoring. Latitude Data S.L. develops and operates the project. ## Intended users Latitude is designed for teams that operate AI agents or AI-enabled product features in production. Primary users include: - AI engineers - Software engineers responsible for AI features - Teams adding agent observability for the first time - Teams scaling an AI feature beyond an initial implementation - Teams investigating multi-step, tool-using, or multi-turn agent behavior - Teams that need managed cloud deployment or a self-hosted observability stack Common use cases include: - Tracing LLM calls, tool calls, retrieval steps, and custom operations - Reviewing full multi-turn agent sessions - Searching production traffic by meaning, exact text, and metadata - Discovering recurring user goals, outcomes, friction, and capability gaps - Monitoring tool usage, errors, latency, tokens, and cost - Grouping repeated failures into signals with examples, impact, trends, and lifecycle states - Converting production failures into evaluations and regression datasets - Alerting when a failure appears, escalates, or returns - Dispatching a coding agent to investigate a production failure and open a pull request - Giving AI agents controlled access to observability data through MCP ## Product loop ```text Observe -> Understand -> Fix -> Verify ``` ### Observe Latitude receives telemetry from an AI application. A span represents one captured operation, such as an LLM call, tool call, retrieval step, HTTP request, or custom operation. Related spans form a trace. Related traces can be grouped into a session representing a multi-turn conversation or workflow. Captured data can include: - Inputs and outputs - Provider and model - Tool inputs, outputs, and errors - Token usage and estimated cost - Duration and time to first token - Error status - Users and session identifiers - Tags, metadata, environments, and releases Supported ingestion paths include: - TypeScript and JavaScript through `@latitude-data/telemetry` - Python through `latitude-telemetry` - Other languages and existing observability pipelines through OpenTelemetry and OTLP Latitude does not sample traces at ingestion. Search, filtering, and manual review remain available across ingested and retained traces. ### Understand Latitude turns production traffic into patterns that a team can investigate and track. #### Search Search combines: - Semantic search by meaning - Exact-text search - Metadata and telemetry filters - Saved searches for reusable cohorts #### Behaviors Behaviors group sessions according to a question about the traffic. The default Topics behavior groups conversations by subject. Additional definitions can group sessions by user goal, outcome, friction reason, assistant approach, capability gap, or another question. Each behavior can expose groups, session counts, trends, and outcome metrics. The same session population can be analyzed through multiple behavior definitions. #### Scores Scores are Latitude's common representation for automated and human verdicts. They can come from: - Human annotations - Built-in flaggers - Evaluations - Custom checks submitted through the API Scores connect trace review, analytics, signal discovery, and evaluation alignment. #### Flaggers Flaggers are built-in automatic annotators for common reliability and safety categories: - Empty responses - Tool-call errors - Output-schema validation failures - Low cache hit rate - Refusal - Laziness - Forgetting - Thrashing - User frustration - Jailbreaking - NSFW content Deterministic checks can run across eligible traffic. LLM-based flaggers use configurable analysis sampling and run on approximately 10 percent by default. This sampling occurs during downstream analysis. It does not remove traces from observability, search, filtering, or manual review. #### Signals A signal is a recurring behavior pattern, usually a failure, tracked across production traffic. Latitude can group similar failed scores into a signal with: - A name and description - Example traces and sessions - Occurrence and impact data - Affected users - Trends - Priority and assignment - Lifecycle state - Linked evaluations Teams can also define signals directly for known failures, policies, or quality checks. ### Fix A signal or incident can trigger Agent Dispatch. Agent Dispatch: 1. Detects a dispatch condition, such as a new, escalating, or regressed signal. 2. Assembles context containing the signal, sample traces, and a deep link to Latitude. 3. Wakes a configured coding agent or sends the payload to another destination. Supported destinations include Claude Code, Cursor, Linear, and webhooks. Latitude acts as the trigger, diagnostic system, and context provider. Agent Dispatch wakes the coding agent. The customer's coding agent runs in its own environment, uses its repository access and credentials, investigates through the Latitude MCP server, implements the smallest appropriate fix, adds a regression test when appropriate, runs project checks, and opens a pull request. Latitude does not edit application code or merge pull requests. A person reviews the pull request before merge. ### Verify Latitude supports verification through production-derived datasets, evaluations, monitors, and signal lifecycle tracking. Teams can: - Add failing production traces to a dataset - Record expected outputs - Replay dataset inputs against the agent - Run the signal's evaluations against new outputs - Gate CI on regression results - Continue evaluating matching production traffic - Resolve a signal after a fix - Detect and reopen the signal if the failure returns Monitors open incidents when configured conditions are met. System monitors track newly discovered, escalating, and regressed signals. User-defined monitors can watch saved searches and traffic metrics. Notifications can be delivered through email and Slack. ## Core product primitives | Primitive | Definition | | --- | --- | | Project | Workspace boundary for one agent, application, or AI feature | | Span | One captured operation inside an agent execution | | Trace | One interaction composed of spans | | Session | Related traces grouped into a conversation or workflow | | User | End user identified through telemetry | | Tool | Function exposed to or called by an agent | | Search | Semantic, exact-text, and filtered retrieval across traces | | Behavior | Grouping of sessions based on a defined question | | Annotation | Human feedback attached to production evidence | | Flagger | Built-in automatic annotator for a known failure category | | Score | Verdict produced by an annotation, flagger, evaluation, or custom check | | Signal | Named and lifecycle-managed recurring behavior pattern | | Evaluation | Automated detector that scores completed traffic | | Dataset | Collection of inputs, outputs, expected outputs, and metadata used for testing | | Monitor | Rule that watches a signal, saved search, or traffic metric and opens incidents | | Incident | Recorded occurrence of a monitor condition | | Agent Dispatch | Context handoff that wakes a coding agent or external workflow | | MCP server | Agent interface for reading and managing a Latitude workspace | ## MCP server Latitude provides a remote, OAuth-authenticated, streamable HTTP MCP server: ```text https://api.latitude.so/v1/mcp ``` The MCP server lets compatible agents read and manage Latitude resources, including projects, traces, spans, annotations, scores, searches, signals, datasets, monitors, users, and tools. The MCP provides observability data and workspace operations. Application code changes happen in the customer's repository through the customer's coding agent. Documentation: https://docs.latitude.so/getting-started/mcp.md ## Deployment and open-source posture ### Latitude Cloud Latitude Cloud is the managed service operated by Latitude Data S.L. It provides hosted ingestion, storage, search, signal discovery, managed inference, and product updates. Hosted customer data and Latitude-managed inference operate in AWS `eu-central-1` in Frankfurt, Germany. ### Self-hosted Latitude The complete platform is available under the MIT license. Self-hosted deployment options include: - A single production host using Docker Compose or Docker Swarm - Kubernetes using the Latitude Helm chart - Managed infrastructure through the Railway deployment template The self-hosted stack uses the same application images. It consists of web, API, ingestion, worker, and workflow services backed by Postgres with pgvector, ClickHouse, Redis, Temporal, and object storage. Self-hosting keeps production data within infrastructure controlled by the customer. Source: https://github.com/latitude-dev/latitude-llm ## Product boundaries - Latitude observes instrumented application and agent activity. - Latitude discovers and tracks patterns using telemetry, scores, annotations, flaggers, evaluations, and search. - Latitude can dispatch a coding agent with evidence and diagnostic context. - The dispatched coding agent runs in the customer's environment. - The coding agent changes application code, adds tests, runs checks, and opens a pull request. - Latitude records and monitors the production evidence used to evaluate whether the fix worked. - A person reviews and merges the pull request. - Trace visibility and search cover ingested and retained traces. - Evaluations and LLM-based flaggers can use configurable downstream sampling. - Latitude-managed inference boundaries apply to Latitude Cloud. An application can continue using its chosen model provider. ## Differentiators Latitude combines the production agent improvement workflow in one open-source system: 1. Agent-native telemetry captures multi-step execution, tool calls, and full sessions. 2. Semantic search and Behaviors expose patterns across real conversations. 3. Scores and Signals convert individual failures into named, prioritized, lifecycle-managed problems. 4. Evaluations and monitors continue checking those problems against production traffic. 5. Agent Dispatch hands the failure to the customer's existing coding agent with trace evidence and workspace access through MCP. 6. Production failures can become reusable regression datasets and CI checks. 7. The complete platform is MIT licensed and self-hostable. The architectural distinction in the fix stage is ownership of the coding agent. Latitude supplies the trigger, evidence, diagnostics, and verification layer. The customer's coding agent retains repository context and performs the code change. ## Canonical references - Product overview: https://docs.latitude.so/getting-started/introduction.md - Core concepts: https://docs.latitude.so/getting-started/concepts.md - Self-healing workflow: https://docs.latitude.so/getting-started/self-healing-agents.md - Agent Dispatch: https://docs.latitude.so/agent-dispatch/overview.md - MCP server: https://docs.latitude.so/getting-started/mcp.md - Deployment: https://docs.latitude.so/deployment/overview.md - Documentation index: https://docs.latitude.so/llms.txt