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

Turns can be exported as OTLP spans to a collector you run. Export is configured per deployment by Yekar.AI rather than per organization - ask us to point it at your collector - and it needs nothing on your side beyond a reachable endpoint.

The span tree

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

Span	Operation	What it is
invoke_agent <agent name>	invoke_agent	The turn
chat <model>	chat	One model call, with its token counts
execute_tool <tool>	execute_tool	One 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.