# GlassFlow documentation

> GlassFlow is a managed observability platform for AI agents: an
> OpenTelemetry-native tracing SDK plus trace analytics, cost tracking,
> a console, and an MCP server for querying your telemetry.

Every page below is fetchable as raw markdown at the listed .md URL.
A single-file version (without the generated API reference) is at https://docs.glassflow.ai/llms-full.txt.

## Docs

- [GlassFlow® documentation](https://docs.glassflow.ai/index.md): GlassFlow is the observability and context layer for teams running AI agents in production. Two products sit under the GlassFlow umbrella. Pick one to get started.
- [Rius](https://docs.glassflow.ai/rius.md): _Agent observability: every LLM call, tool invocation, and agent step, traced end to end._
- [Quickstart](https://docs.glassflow.ai/rius/quickstart.md): From nothing to a visible trace in one sitting. Rius needs three things: an account, an API key, and two lines of instrumentation.
- [Guides](https://docs.glassflow.ai/rius/guides.md): Task-oriented walkthroughs. Where the SDK and interoperability sections document one surface at a time, a guide cuts across them to get a specific job done end to end.
- [Multi-tenant agent observability: one workspace per customer](https://docs.glassflow.ai/rius/guides/multi-tenant-observability.md): You build agents and sell them: an agent product, an agency running agents per client, a platform with agent features. Each of your customers needs their telemetry isolated from every other customer's, and you need to see cost and health per customer. With Rius, you do that by treating each customer as its own workspace: the security and observability boundary for multi-tenant deployments. This guide is the opinionated way to set that up.
- [Migrate from Langfuse to Rius](https://docs.glassflow.ai/rius/guides/migrate-from-langfuse.md): Langfuse and Rius are both OpenTelemetry-based, which makes migrating from Langfuse mostly a routing change: your traces are already spans, and in many setups Rius can receive them without touching your instrumentation. This guide maps the concepts, walks the two migration paths, and ends with a cutover checklist. Run both backends in parallel during the evaluation; nothing here requires a hard switch.
- [Concepts](https://docs.glassflow.ai/rius/concepts.md): The Rius data model in one page: what a trace is, what spans and generations are made of, and which parts the platform computes for you.
- [SDK](https://docs.glassflow.ai/rius/sdk.md): The Rius SDK is OpenTelemetry-native tracing for AI agents: non-blocking by design, privacy-aware at export time, and speaking the OpenTelemetry GenAI conventions.
- [Installation and configuration](https://docs.glassflow.ai/rius/sdk/installation.md): The Rius SDK for Python is published as `glassflow-rius` and imported as `rius`; it requires Python 3.10 or newer. The TypeScript SDK is published as `@glassflow-ai/rius` and requires Node 18 or newer.
- [Tracing your code](https://docs.glassflow.ai/rius/sdk/tracing.md): The Rius SDK gives you three levels of control: `observe` for whole functions, generic spans for arbitrary steps, and generations for LLM calls.
- [Integrations](https://docs.glassflow.ai/rius/sdk/integrations.md): Rius integrates with the client libraries, agent frameworks, and protocols agents are built on: model calls arrive as generations with tokens and cost, and run structure arrives from the framework's own spans or a thin layer of `observe` wrappers. Each integration's page covers setup, what lands in the trace, and the blind spots.
- [OpenAI](https://docs.glassflow.ai/rius/sdk/integrations/openai.md): Trace every OpenAI client call with Rius without touching your call sites.
- [Anthropic](https://docs.glassflow.ai/rius/sdk/integrations/anthropic.md): Trace every Anthropic client call with Rius without touching your call sites.
- [LangChain](https://docs.glassflow.ai/rius/sdk/integrations/langchain.md): Trace LangChain (and LangGraph) runs with Rius: chains, tools, retrievers, and model calls arrive as a nested trace mirroring your graph.
- [LlamaIndex](https://docs.glassflow.ai/rius/sdk/integrations/llama-index.md): Trace LlamaIndex pipelines with Rius: query engines, retrievers, embeddings, and the model calls inside them.
- [LiteLLM](https://docs.glassflow.ai/rius/sdk/integrations/litellm.md): Trace calls routed through LiteLLM with Rius: one integration covers every provider behind the router.
- [MCP](https://docs.glassflow.ai/rius/sdk/integrations/mcp.md): Trace your agent's outgoing MCP tool calls with Rius, and connect them to the server's own traces where the protocol allows it.
- [Vercel AI SDK](https://docs.glassflow.ai/rius/sdk/integrations/vercel-ai.md): Enrich the spans the Vercel AI SDK already emits so its model calls arrive in Rius as generations, with prompts, responses, models, and token usage.
- [OpenAI Agents SDK](https://docs.glassflow.ai/rius/sdk/integrations/openai-agents.md): Trace agents built with the OpenAI Agents SDK with Rius: every model call the framework makes arrives as a generation with tokens and cost, and a thin layer of `observe` wrappers gives the run and its tools their shape. This guide covers the Python SDK; the runnable example behind it lives in agent-observability-examples.
- [Pydantic AI](https://docs.glassflow.ai/rius/sdk/integrations/pydantic-ai.md): Trace agents built with Pydantic AI with Rius: the framework is OpenTelemetry-native and emits its own spans for agent runs, model requests, and tool calls, so the whole structure arrives with no wrappers at all. This guide covers the Python framework; the runnable example behind it lives in agent-observability-examples.
- [CrewAI](https://docs.glassflow.ai/rius/sdk/integrations/crewai.md): Trace crews built with CrewAI with Rius: the model calls the framework makes arrive as generations with tokens and cost, and `observe` wrappers give the run and its tools their shape. This guide covers the Python framework; the runnable example behind it lives in agent-observability-examples.
- [AutoGen](https://docs.glassflow.ai/rius/sdk/integrations/autogen.md): Trace agents built with AutoGen (AgentChat) with Rius: the framework emits its own OpenTelemetry spans for agents and tools, and the `openai` integration adds the generations with tokens and cost. This guide covers the Python framework; the runnable example behind it lives in agent-observability-examples.
- [Claude Agent SDK](https://docs.glassflow.ai/rius/sdk/integrations/claude-agent-sdk.md): Trace agents built with the Claude Agent SDK with Rius. This framework is different from the others on this page's siblings: it drives the Claude Code runtime in a separate process, so no model client runs in your process and auto-instrumentation has nothing to hook. Coverage is manual, and still gives you per-task traces with tokens and cost. The runnable example behind this guide lives in agent-observability-examples.
- [Advanced features](https://docs.glassflow.ai/rius/sdk/advanced.md): Volume and privacy controls for production deployments of the Rius SDK: head sampling to reduce trace volume, and two independent controls over what content leaves your process. All of them are `init()` arguments; none require code changes in your agent.
- [Reliability](https://docs.glassflow.ai/rius/sdk/reliability.md): The design promise of the Rius SDK: tracing never blocks and never breaks your application. This page explains the machinery behind that and the knobs you can tune.
- [Troubleshooting](https://docs.glassflow.ai/rius/sdk/troubleshooting.md): Symptoms first, causes second. Everything here assumes the Rius SDK (`glassflow-rius`) 0.6.0 or newer.
- [Python reference](https://docs.glassflow.ai/rius/sdk/reference/python.md): Generated from the `glassflow-rius` 0.12.0 docstrings, covering the Python SDK's public API surface module by module. Wording fixes happen upstream in the SDK repository, never here.
- [TypeScript reference](https://docs.glassflow.ai/rius/sdk/reference/typescript.md): Generated from the `@glassflow-ai/rius` 0.3.1 type declarations, covering the TypeScript SDK's public API surface. Wording fixes happen upstream in the SDK repository, never here.
- [Platform](https://docs.glassflow.ai/rius/platform.md): Working with the Rius console at eu.console.rius-glassflow.com, task by task:
- [Exploring traces](https://docs.glassflow.ai/rius/platform/exploring-traces.md): Every run your Rius agents produce, from the list view down to a single span's attributes.
- [Monitoring live agents](https://docs.glassflow.ai/rius/platform/agents.md): The Agents view answers a question traces alone cannot: is the agent process alive right now? Every instrumented process with the heartbeat enabled reports in, and Rius classifies each instance by liveness:
- [Monitoring usage and cost](https://docs.glassflow.ai/rius/platform/monitoring.md): Home is the Rius workspace's scoreboard: how your agents did this period, in volume, cost, tokens, and errors.
- [Settings](https://docs.glassflow.ai/rius/platform/settings.md): Everything under the console's Settings page, one section per tab: the workspace itself, its API keys, the organization and its members, and the shared views that leave it.
- [MCP](https://docs.glassflow.ai/rius/mcp.md): Connect Claude, Cursor, and other AI clients to Rius and query your agent's traces from where you already work. Ask "what was my agents' error rate yesterday?" in plain language, and your client answers from your real telemetry: trace lists, cost and token summaries, and full span waterfalls.
- [Tool reference](https://docs.glassflow.ai/rius/mcp/tools.md): Every tool the Rius MCP server exposes, with arguments and example invocations. All tools return Markdown, which your client renders as tables and summaries. Everything is read-only with one exception, `create_api_key`, which is admin-gated.
- [Example workflows](https://docs.glassflow.ai/rius/mcp/workflows.md): Three investigation patterns you can run entirely from your AI client once the Rius MCP server is connected. Each starts from a plain-language prompt; the tool sequence shows what your client does with it.
- [Interoperability](https://docs.glassflow.ai/rius/interoperability.md): Rius is convention-native OpenTelemetry: you can send traces without the SDK, from OpenLLMetry, OpenInference, vanilla OTel SDKs, or any OTLP-speaking collector.
- [Span attribute reference](https://docs.glassflow.ai/rius/interoperability/attributes.md): The wire format Rius reads. If you emit spans from anything other than the SDKs (a vanilla OpenTelemetry SDK, a collector pipeline, another language), this page tells you which attributes to set so your traces get the same analytics as SDK-emitted ones.
- [Vanilla OpenTelemetry SDKs](https://docs.glassflow.ai/rius/interoperability/otel-sdks.md): Any language with an OpenTelemetry SDK can send traces to Rius today: the ingest endpoint is standard OTLP/HTTP. This is the path for languages without a native SDK (everything except Python and TypeScript).
- [OpenLLMetry](https://docs.glassflow.ai/rius/interoperability/openllmetry.md): If your application is already instrumented with OpenLLMetry (Traceloop's SDK), point its exporter at Rius and your existing traces flow in; no re-instrumentation needed.
- [OpenInference](https://docs.glassflow.ai/rius/interoperability/openinference.md): OpenInference instrumentors (the ones behind Arize Phoenix) work with Rius directly: they emit standard OpenTelemetry spans, so they only need an OTLP exporter pointed at the ingest endpoint.
- [OpenTelemetry Collector](https://docs.glassflow.ai/rius/interoperability/collector.md): Route traces to Rius through an OpenTelemetry Collector when you want a single egress point, local buffering, or to fan the same traces out to more than one backend.
- [Introduction](https://docs.glassflow.ai/tares.md): Tares is the open-source platform for always-on AI agents. Chat agents wait for a prompt. Tares agents wait for an event: every event from your systems lands on one timeline per thing, a trigger wakes an agent the moment it matters, and the finding it writes back is there for the next reader.
- [Quickstart](https://docs.glassflow.ai/tares/quickstart.md): If you are a coding assistant, start with AI resources.
- [Concepts](https://docs.glassflow.ai/tares/concepts.md): Everything in Tares hangs off one pipeline. Sources ingest events from your systems; the labels on each event say which entity it belongs to. A read returns one entity's events across all sources, merged in time order. A view saves a narrowed read; a trigger watches a view and, when its condition trips, emits a dispatch to subscribed agents; an agent can write a finding back onto the entity's timeline.
- [Projects](https://docs.glassflow.ai/tares/projects.md): A project is what you set up and look after in Tares: a named set of sources, views, triggers, agents and, where needed, MCP servers, with one page. Every object in a project is an ordinary Tares object on its normal page (Sources, Triggers, Tares agents, MCP servers); the project page is the combined view of them.
- [Deployment](https://docs.glassflow.ai/tares/deployment.md): Tares is a single process writing to a single DuckDB file. There is no external database or broker to run. DuckDB is single-writer, so a deployment is exactly one `taresd` and one data volume. Do not run multiple replicas against the same data.
- [Connectors](https://docs.glassflow.ai/tares/connectors.md): A connector defines how a source gets events into Tares. These are the supported connectors:
- [Prometheus alerts: `prometheus_alerts`](https://docs.glassflow.ai/tares/connectors/prometheus-alerts.md): Polls Prometheus's own `/api/v1/alerts`, the alerts its alerting rules have already fired. One event per active alert, keyed by a label, plus a `resolved` event when it clears. No Alertmanager and no PromQL: Prometheus decides what's an alert; Tares correlates it and can dispatch it to an agent.
- [Docker logs: `docker_logs`](https://docs.glassflow.ai/tares/connectors/docker-logs.md): Tails a running container's logs, one event per line, all lines by default, with optional `match`/`drop` regex filters. Supports discovery, and the dedicated `discover_docker` tool scans the whole local Docker environment for candidate containers.
- [Claude Code sessions: `claude_code`](https://docs.glassflow.ai/tares/connectors/claude-code.md): Ingests Claude Code session transcripts into the data plane, one event per message, keyed by `session`, with `project`, `branch`, and `model` as labels and token-usage fields. Sub-agents roll up into the same source. Your agent sessions become a queryable source like any other: correlate what the agent did with what your systems did, and let the agent read back its own history.
- [Alertmanager: `alertmanager`](https://docs.glassflow.ai/tares/connectors/alertmanager.md): A push receiver for Alertmanager: point a `webhook_configs.url` at this source's ingest endpoint and every alert Alertmanager routes becomes an event. Alertmanager has already evaluated, grouped, deduped and (with `send_resolved`) tracks firing→resolved. Tares just records what it pushes, and correlates it with your other sources.
- [GitHub commits: `github`](https://docs.glassflow.ai/tares/connectors/github.md): Polls a repo's commits (cursor by SHA), one event per commit, keyed by `repo`, with `author` and `branch` as labels. Supports discovery: given a `repo`, it validates access and finds the default branch.
- [Agent memory: `memory`](https://docs.glassflow.ai/tares/connectors/memory.md): The agent's own observations, written back via the MCP `remember` tool (or `POST /remember`). Joinable into views like any other source: what an agent concluded about `service=checkout` last week sits in the same timeline as the service's logs and deploys.
- [OpenTelemetry: `otlp`](https://docs.glassflow.ai/tares/connectors/otlp.md): Receives OTLP/HTTP logs, traces, and metrics at `POST /v1/{logs,traces,metrics}`. One source ingests every service: resource attributes (e.g. `service.name`) become labels, so everything an OTel SDK or Collector exports correlates by service with no per-service setup.
- [Postgres table: `postgres`](https://docs.glassflow.ai/tares/connectors/postgres.md): Polls a table incrementally, one event per new/changed row. The cursor tracks a monotonic column (an autoincrement `id`, or `updated_at`); an entity column (e.g. `tenant_id`) becomes the key via a `primary` label. Your application's source-of-truth data in the timeline. Supports discovery: given the connection URL it lists the tables it can see, then reads the chosen table's columns to propose the cursor and labels.
- [Prometheus: `prometheus`](https://docs.glassflow.ai/tares/connectors/prometheus.md): Ingests the Prometheus metrics you pick. Each series becomes a metric event on every poll tick, joinable with logs, deploys and alerts on the same key. You choose which metrics (by name, or by a label they carry) and Tares does the rest: there is no PromQL to write. The numeric value is stored as a number-typed `value` label, so triggers can aggregate it.
- [Reference documents: `reference`](https://docs.glassflow.ai/tares/connectors/reference.md): Documents (json / csv / md / txt) attached to an entity by their labels: project notes, schemas, runbooks. Unlike the event connectors this is declarative reference material, not a stream: it's always surfaced when correlating on that entity, regardless of the read time window. A runbook doesn't "age out" of a 15-minute read.
- [Vercel logs: `vercel`](https://docs.glassflow.ai/tares/connectors/vercel.md): Push source for Vercel logs: point a Vercel log drain (JSON) at the source's ingest endpoint. One event per log entry, keyed by `project`, with `environment` and `source` as labels. A single drain can carry multiple projects; they appear as distinct entities.
- [Inbound webhook: `webhook`](https://docs.glassflow.ai/tares/connectors/webhook.md): Push ingestion of arbitrary JSON (or NDJSON): producers POST to the source's ingest endpoint. The payload is stored lossless; declare labels to map payload fields into the envelope. The catch-all connector for anything that can send an HTTP request: CI systems, GitHub webhooks, cron jobs, your own services.
- [Connecting agents (MCP)](https://docs.glassflow.ai/tares/agents.md): Connect Claude Code, Codex, Cursor, or any MCP client to Tares and ask questions like *"what happened to api-server in the last 15 minutes?"*. The client discovers the Tares tools and answers from the correlated timeline: logs, metrics, alerts, and findings in one read.
- [AI resources](https://docs.glassflow.ai/tares/agents/ai-resources.md): This page is written for coding assistants (Claude Code, Codex, Cursor, or an agent of your own) that are asked to set up, configure, or explain Tares. Humans are welcome too.
- [Tares agents](https://docs.glassflow.ai/tares/tares-agents.md): A Tares agent is a prompt attached to a trigger. When the trigger fires, the agent is handed the correlated timeline for the affected entity, reads it (and can read a wider window or another entity), and writes its conclusion back into Tares as a finding on that entity's timeline.
- [Ask](https://docs.glassflow.ai/tares/ask.md): Ask is the assistant built into the console: type a question about your data and it investigates with the same read API everything else uses, showing each tool call as it works. Open it under Ask in the sidebar, or summon it from anywhere with ⌘K.
- [Guides](https://docs.glassflow.ai/tares/guides.md): End-to-end walkthroughs for common tasks. Each assumes a running instance (see the Quickstart) and links to the relevant reference where useful.
- [Build an AI SRE](https://docs.glassflow.ai/tares/guides/ai-sre.md): This guide builds an incident-response agent on Tares, end to end. By the last step you have a working AI SRE: when a service misbehaves, a trigger wakes an agent with one correlated timeline of metrics, logs, and alerts; the agent names the root cause and writes its conclusion back where the next investigation will find it. You also have an MCP client connected, so you can investigate the same evidence interactively.
- [Keep shared code context current](https://docs.glassflow.ai/tares/guides/shared-code-context.md): Many teams keep a repository of shared context: what each service does, its interfaces, its configuration, how the pieces depend on each other. It goes stale the week after it is written. This guide sets up a project from the Shared code context template: Tares watches commits across your code repositories, and when something lands an agent reads the change and updates the context pages that cover it, opening a pull request for review. By the last step the context repository is kept current by the commits themselves.
- [Challenge Claude Code with a second model](https://docs.glassflow.ai/tares/guides/challenger-workflow.md): One model writes the code, a second one argues with it. In a challenger session, Claude Code plans and builds as usual, and the OpenAI Codex CLI on the same laptop critiques the plan when Claude leaves plan mode and reviews every commit Claude makes. A blocking finding sends Claude back to fix and amend before it can move on. Tares is the record and the after-session brain: the Claude and Codex exchange lands on one timeline per session, and when the session ends a Tares agent writes the summary and proposes what the next session in that repo should remember.
- [The HTTP API in five minutes](https://docs.glassflow.ai/tares/guides/http-api.md): Everything the console and the MCP tools do goes through the daemon's HTTP API. This guide drives the whole loop with `curl`: create a source, feed it, read a correlated timeline, define a trigger, watch it fire, and write an observation back. No upstream systems required.
- [Watch with triggers](https://docs.glassflow.ai/tares/guides/triggers.md): A trigger evaluates a condition over a view as events arrive. When it fires, Tares pushes to any subscribed webhook, so an agent is woken with the relevant timeline instead of polling.
- [Self-host on a server](https://docs.glassflow.ai/tares/guides/self-host.md): Run a single-tenant Tares instance on a server: the daemon, the MCP server, and a reverse proxy (Caddy) that terminates TLS and serves one hostname. DuckDB is single-writer, so this is exactly one `taresd` and one volume.
- [CLI reference](https://docs.glassflow.ai/tares/cli.md): The `tares` package installs four entry points.
- [Release notes](https://docs.glassflow.ai/tares/release-notes.md): Notable changes to Tares, newest first. The project follows Semantic Versioning; earlier `0.0.x` history is in the git log.
- [Help](https://docs.glassflow.ai/tares/help.md): Stuck, found a bug, or want to talk through a use case? We're happy to help.