Skip to main content

Observability

Yekar.AI records every model call and every tool call as it happens - the arguments, the result, the tokens, the cost and the identity it ran as. That record is the audit trail, and it is queryable from the product without any configuration.

If you already run an observability stack, you can have the same turns as traces.

OpenTelemetry export

Set OTEL_EXPORTER_OTLP_ENDPOINT and turns are exported as OTLP spans. That is the entire configuration.

The two processes report separately as yekar-api and yekar-worker. Keep them distinct in your backend: a turn is claimed in one process and served in the other, and a trace that cannot say which process a span came from cannot answer the question that made you open it.

The span tree

One span per settled turn, with one child per recorded call:

SpanOperationWhat it is
invoke_agent <agent name>invoke_agentThe turn
chat <model>chatOne model call, with its token counts
execute_tool <tool>execute_toolOne tool call

Times are the recorded ones, taken from the same rows the audit trail is built from - not re-measured at export. A span's duration is what actually happened, so a trace and an audit row can never tell you different stories about the same call.

Export is additive. It reads what the turn already wrote; nothing about the turn changes because a collector is configured, and an unreachable collector cannot affect a turn.

Where model calls can land

When a provider is unreachable, a turn can finish on a different model rather than failing. This runs only after same-model retries are spent, only for transient failures, and never after any text has reached the reader - replaying a reply on top of what someone already saw is worse than the error.

The fallback chain is a platform setting rather than a per-organization one, and its order is honoured exactly as configured. With no chain set, a turn that exhausts its retries fails honestly rather than answering on a model the agent did not ask for.

What you can see per agent

For the per-agent view - where answers came from, what was repaired mid-turn, and how each Setup revision compares - see Health.