Error monitoring for AI agents
When an agent's tool throws, a model call is refused or an MCP tool answers with an error, Condux files it as a grouped issue that names what failed, ready for your alert rules. Point your OpenTelemetry trace exporter at Condux, and the prompts and tool arguments on its spans are dropped on arrival.
AI agent error monitoring means catching the moment an agent fails rather than replaying every step it took. Condux reads the OpenTelemetry traces your agent framework already emits, keeps only the spans that ended in an error and files each failure as an issue you can triage, assign and alert on beside the rest of your errors.
What gets caught
- Tools that fail
A tool that raises, or an MCP tool that answers a call with an error, becomes an issue named after the tool.
- Model calls that fail
A rate limit, a rejected key or a provider outage becomes an issue too, filed as a warning when the instrumentation marks the span as a model call.
- Agent runs that fail
When a run ends in an error and no step beneath it failed, the run itself is the issue, and its page names the agent.
- No double counting
When a failing tool also marks the agent span above it as failed and both arrive in the same export, Condux reports the tool rather than counting the failure twice.
Grouped the way you would group them
Issues are keyed on the error type, the operation and the tool, model or agent name, never on the error text. A tool that times out all day with a different message each time is one issue with an exact count, and its page shows the tool, model, provider and agent the failed span names.
Prompts are dropped, not stored
- No content stored
Prompts, completions, system instructions and tool arguments are dropped on arrival. A span's attributes become tags only from a fixed list that names the operation.
- Scrubbed error text
The error message is kept, and goes through the same PII scrubber as every other event.
- Run it yourself
Condux runs inside your own network from Docker Compose or a Helm chart, so the failures it records are stored there and nowhere else. The traces endpoint is on the hosted service now and reaches the self hosted release with the next version.
Pay for failures, not for spans
Only a failed span becomes an event. Spans that succeed are accepted and dropped without touching your monthly event quota, so a busy agent that rarely fails costs a handful of events to watch.
Works with the instrumentation you already run
The first three were run with their real instrumentation against a stand in model, and Condux's ingest tests replay what they sent.
- OpenAI Agents SDK
Through the OpenTelemetry contrib instrumentation: failed tools, failed model calls and the agent around them.
- OpenAI client
Through the OpenTelemetry contrib instrumentation or OpenLLMetry: a refused or failed chat completion, with the model and the error type.
- MCP
The MCP Python SDK (version 2.3) traces its own tool calls, so a tool that answers with an error arrives as a failed span.
- Anything on OpenTelemetry
Any OTLP/HTTP trace exporter can send to Condux. A span with an error status becomes an issue, and GenAI attributes, where the span has them, add the model, tool and agent.
Point your exporter at Condux
OTEL_EXPORTER_OTLP_TRACES_PROTOCOL=http/protobufOTEL_EXPORTER_OTLP_TRACES_ENDPOINT=https://ingest.condux.ai/api/<project>/v1/tracesOTEL_EXPORTER_OTLP_TRACES_HEADERS=x-condux-auth=<key>
When the bug is in your code
When the cause sits outside your code, such as a refused provider call or a tool given bad input, the issue is how you find it and track it. When a failure carries a JavaScript stack trace that points into your repository, the Conductor can draft the fix as a pull request your team reviews, the same as for any other error.
Frequently asked questions
Is Condux an LLM tracing or observability tool?
No. Condux stores no traces, no run timeline and no evaluations. It watches for failures and turns each one into an issue you can triage, assign and alert on, next to the rest of your application's errors. Keep a tracing tool if you need to replay whole runs.
Do I need a Condux SDK?
No. Point your OpenTelemetry trace exporter at your project's ingest URL and send the DSN key as the x-condux-auth header. Set the protocol to HTTP, because some OpenTelemetry distributions default to gRPC.
Are my prompts sent to Condux?
Your exporter may send them, since some instrumentations capture message content by default, but Condux drops those span attributes on arrival and never stores them. The error message is kept and scrubbed, so a provider error that quotes your input keeps that quote. To keep content off the wire as well, turn content capture off in your instrumentation.
Will a provider outage page me?
Only if you ask it to. A failed call that its instrumentation marks as a model call is filed as a warning, so an alert rule for warnings tells you and one for errors does not fire on that call. If the agent run above it also fails and arrives in a separate export, the run is filed as an error. Automatic fixes start only from an error whose stack trace points into your code.