Examples 1 to 3 are real runs from the Blits.ai test environment, shortened and anonymized, with log excerpts as the platform recorded them. Example 4 shows per tool approval and is illustrative.

Where do these logs come from?

Every workflow run stores its tool calls with arguments, results, duration and a failed flag, plus iterations, attempts and validation results. Conversations write a trace per turn with tool decisions, guardrail checks, quality scores, regenerations and provider fallbacks.

Can we get these logs out of the platform?

Yes. Run data downloads from the platform, and the decision log exports as JSON or streams over OpenTelemetry to your own SIEM or observability stack.

Does a person have to step in when something fails?

No. In the first three examples the platform recovers or protects the customer by itself. A person only steps in where you require it, as with the refund in the fourth example.

Agent run examples

Real runs from our test environment, step by step, as the platform logged them: a workflow that finds another route when a file is missing, a guardrail check that switches provider, and a quality gate that keeps a weak answer away from the customer.

Examples 1 to 3 are real runs from the Blits.ai test environment, shortened and anonymized: assistant names, documents and conversation content are removed. Example 4 is illustrative.

Real run, anonymized

1. A workflow finds another route when a file is missing

A workflow has to produce a customer report as a PDF. The file it was told to use does not exist. Run of 12 October 2026.

TriggertriggeredBy: "manual"
A user starts the workflow. Its task: build a customer report as a PDF from the customer data file.
Errorfile_ingest → failed: true
The agent asks for the file customer_report.json. The tool returns "File not found" after 595 ms and the call is marked failed.
Agent decision
The error goes back to the agent as the tool result. Instead of stopping, the agent looks for another document with customer data that is already in the platform.
Tool callfile_ingest → totalRows: 5000
It opens a spreadsheet with one sheet of 5,000 customer rows and reads the columns: name, gender, country, age, date and ID.
Tool callgenerate_scope_of_work → pdf
The agent builds the report and generates a PDF of 66 KB.
Resultstatus: "completed"
Run completed: 4 iterations, 1 attempt, 28.4 seconds, no person involved. The agent's own summary says the source file was missing and the report was built from an alternative source.

Excerpt from the log

"status": "completed", "iterations": 4, "attempts": 1, "durationMs": 28380,
"toolsUsed": [
  { "name": "file_ingest", "failed": true, "durationMs": 595,
    "result": { "error": "File customer_report.json not found" } },
  { "name": "file_ingest", "durationMs": 1599,
    "result": { "type": "excel", "sheetCount": 1, "totalRows": 5000 } },
  { "name": "generate_scope_of_work", "durationMs": 4073,
    "result": { "success": true, "fileName": "customer_report_2026-10-12.pdf", "sizeBytes": 66348 } }
]

Real run, anonymized

2. A guardrail check switches provider

A card advisor assistant in a bank test environment answers a customer question. The model that runs the input guardrail fails. Conversation turn of 6 October 2026.

Message
A customer asks a question about cards.
Agent decisionresolvedToolCalls: 0
The agent reviews the tools it has and decides it can answer without calling one.
Errorgemini-3.1-flash-lite
The input guardrail check runs on Gemini 3.1 Flash Lite, which fails.
Fallbackprovider_fallback → gpt-4.1
The check moves to GPT 4.1 at OpenAI and completes. The switch is recorded in the trace with both model names.
Resultstatus: "success"
The turn ends with status success. The customer gets a normal answer and never sees the failure.

Excerpt from the log

{ "traceType": "policy_check", "requiresExecution": false, "resolvedToolRoles": [] }
{ "traceType": "latency", "stage": "chain_total", "usedTools": false }
{ "traceType": "provider_fallback", "stage": "input",
  "from": "gemini-3.1-flash-lite", "toProvider": "OpenAI", "to": "gpt-4.1" }
status: "success"

Real run, anonymized

3. A quality gate keeps a weak answer away from the customer

A test assistant receives a vague one word message. The platform tries three times to produce a useful answer, then blocks it. Conversation turn of 19 September 2026.

Message
The user sends a vague message.
Guardrailenforce_rag_retry
The agent plans an answer without consulting the knowledge base. The platform requires grounding for this assistant and makes it plan again with the knowledge base search.
Tool callcustom-rag-search
The knowledge base search runs and the agent writes an answer.
Guardrailquality: 30 / 100 → regenerate
The quality check scores the answer 30 out of 100: it does not answer the question and asks for clarification. The grader itself runs on a fallback model after its primary model fails.
Agent decisionquality: 30 → regenerate
The agent writes a new answer with the grader's reason as instruction. Score 30 again, so it tries once more.
Guardrailquality: 40 → max_regenerations_exhausted
The third answer scores 40. The maximum number of regenerations is reached and the answer is rejected.
Resultstatus: "blocked"
The output guardrail blocks the answer. The customer gets the assistant's configured fallback message instead of a weak or wrong answer.

Excerpt from the log

{ "traceType": "enforce_rag_retry", "availableExecutionTools": ["custom-rag-search"] }
{ "traceType": "provider_fallback", "stage": "quality", "from": "gpt-5-pro", "to": "gpt-4.1" }
{ "traceType": "quality_check_evaluated", "attempt": 0, "score": 30, "action": "regenerate" }
{ "traceType": "quality_check_regenerated", "attempt": 1, "previousScore": 30 }
{ "traceType": "quality_check_evaluated", "attempt": 1, "score": 30, "action": "regenerate" }
{ "traceType": "quality_check_regenerated", "attempt": 2, "previousScore": 30 }
{ "traceType": "quality_check_evaluated", "attempt": 2, "score": 40, "action": "regenerate" }
{ "traceType": "quality_check_rejected", "finalScore": 40, "attempts": 3,
  "reason": "max_regenerations_exhausted" }
output_guardrails_triggered

Illustrative

4. A refund waits for approval

A customer reports a double charge. Refunds move money, so the refund tool requires approval by default.

Message
Customer: "I was charged twice for the same order yesterday."
Tool callget_transactions
The agent reads the customer's transactions and finds two identical charges of 189 AED.
Approvalrefund_transaction: "requires approval"
The agent calls the refund tool. The tool requires approval, so it does not run yet.
Message
The agent tells the customer the refund is being reviewed and that they will hear back in this conversation.
Approvalapproved
An employee approves the refund in the platform 6 minutes later. Name and time are logged.
Tool callrefund_transaction → confirmed
The refund tool runs and the payment provider confirms the refund.
Result
The agent confirms the refund to the customer in the same conversation.

Agent run examples: FAQ

How the platform works

How Blits.ai agents work

Error handling and recovery

Security and governance

Reliability and SLA

Integration standards

Features

Release notes

Want to see it on your own systems?

We run a working session on your use case, with your data and the models you choose.

Plan a call