Production visibility

Observability: traces, citations, and run history

Quantlix records the execution path for AI requests so you can debug production behavior without guessing: what ran, what was blocked, what reached the provider, which sources were used, and where time or cost went.

Run history

Every execution with status, request ID, deployment/workflow, model/provider, latency, cost estimate, and error state.

Traces

A timeline of gateway, workflow, retrieval, model, agent, function, policy, and citation events.

Node outputs

Workflow node inputs and outputs, including MCP results, redaction summaries, model requests, agent steps, and function responses.

Citations

Retrieved chunks, source names, document IDs, scores, and citation metadata for RAG and answer_with_citations flows.

Errors

Provider failures, policy blocks, validation issues, timeouts, retries, and fallback behavior.

Set up useful run history

  1. Run traffic through a Quantlix deployment or workflow instead of calling the provider directly.
  2. Use stable request IDs from your app so production incidents can be searched later.
  3. Keep prompt_field, result_field, and node names meaningful so traces are readable.
  4. For RAG, use retrieval or answer_with_citations so citations and retrieval events are recorded.
  5. For agents and tools, configure function names clearly so agent_steps explain what happened.
  6. Review Observability after test runs before sending production traffic.

Fields to inspect first

trace_id

Correlates spans and node executions for one request path.

request_id

Use this to connect your app logs to Quantlix run history.

status

Shows running, completed, failed, blocked, or waiting approval states.

latency_ms

Helps identify slow provider calls, retrieval, tools, or agent loops.

cost_estimate

Shows compute, token, retrieval, and total estimated cost where available.

model_request

The provider payload after workflow transforms, redaction, and policy decisions.

agent_steps

Each native tool-calling iteration, requested tool, function result, and final answer.

citations

Document/chunk evidence used for grounded answers.

Debugging playbooks

A workflow failed

  1. Open Dashboard -> Observability and search by run ID, request ID, workflow, or deployment.
  2. Check the failed node and error category first: validation, policy block, provider error, timeout, or tool failure.
  3. Inspect the node input and output payloads around the failure.
  4. If retry or fallback ran, compare retry_count and fallback_node_id behavior.

Claude or another model did not receive expected data

  1. Open the workflow run and find the model node.
  2. Inspect model_request.messages or agent_request.messages.
  3. Compare that payload with upstream mcp_input, retrieval, transform, or redact_text outputs.
  4. Fix the prompt_field if the model is reading the wrong field.

A RAG answer has weak or missing citations

  1. Inspect retrieval candidates, scores, source_name, source_url, and chunk metadata.
  2. Check top_k, min_score, filters, and rerank output.
  3. Confirm answer_with_citations received retrieval.candidates.
  4. Add eval questions once you have a stable set of expected answers.

A privacy or policy issue was reported

  1. Check enforcement events and policy decisions for the request.
  2. Inspect redaction_summary before the model or agent node.
  3. Open model_request.messages or agent_request.messages to prove what reached the provider.
  4. Export audit evidence if the incident needs compliance review.

An agent or tool call is slow

  1. Open agent_steps and compare each model/tool iteration.
  2. Check function_request and function_response for slow external endpoints.
  3. Review max_iterations, timeout_ms, retry policy, and budget gates.
  4. Move expensive tools behind approval, router, or condition nodes if needed.

What observability does not replace

Observability shows what happened. Boundary enforcement decides what is allowed to happen. Use traces with schema validation, guardrails, budgets, redaction, and evals for production control.

Observability — Quantlix Docs — Quantlix