How to Monitor AI Agents: Logs, Traces, Evals, and Human Approvals

An AI agent can finish without throwing an error and still fail the business.

It can call the wrong tool, rely on weak evidence, take an inefficient path, expose sensitive context, or produce an answer that looks polished but does not solve the task. Traditional application monitoring is necessary, but it is not enough.

Production agents need four connected control layers: logs, traces, evaluations, and human approvals.

Logs, traces, evals, and approvals do different jobs

Control	Question it answers	Example
Logs	What happened?	Run started, CRM tool returned 429, retry succeeded
Traces	How did the agent reach the result?	Model chose search, inspected three records, then drafted a response
Evaluations	Was the result good?	Answer was grounded, complete, policy-compliant, and useful
Human approvals	Should this action be allowed now?	Manager reviews a refund before the agent submits it

These controls overlap, but one cannot substitute for another. A trace can show exactly how an agent produced a poor answer. It does not tell you what “poor” means until an evaluation defines the standard. An approval can prevent one bad action. It does not reveal a gradual decline across thousands of low-risk runs.

Why normal uptime monitoring misses agent failures

Conventional software is often evaluated against explicit rules. A request returns the correct status, a calculation matches the expected value, or a database write succeeds.

Agent behavior is more variable. The same task can produce different paths and different wording while still being acceptable. That creates several failure classes:

• Technical failure: timeout, invalid response, unavailable tool, or authentication error.
• Process failure: skipped step, duplicate action, wrong handoff, or failure to stop.
• Quality failure: incomplete, irrelevant, unsupported, or misleading output.
• Policy failure: unauthorized action, sensitive-data exposure, or prohibited claim.
• Economic failure: excessive model usage, repeated tool calls, or a path that is too slow for its value.
• Silent failure: the run completes, but the business outcome is wrong.

The operating system must capture all six.

The minimum event record for every agent run

Every run should have a stable identifier that connects application logs, model traces, tool calls, approvals, and the final business record.

At minimum, capture:

• Run ID and parent workflow ID.
• Agent, prompt, policy, and model version.
• Start time, end time, and total latency.
• User or system that initiated the run.
• Task type and environment.
• Input reference, with sensitive values redacted or stored separately.
• Tools made available to the agent.
• Tools actually called, in order.
• Tool parameters and results, subject to privacy rules.
• Token or usage data when available.
• Final output and structured status.
• Retries, fallback paths, and errors.
• Human review outcome and corrections.
• Downstream business result when it becomes known.

Do not place secrets or unrestricted personal data into logs by default. The OpenTelemetry generative AI conventions explicitly treat prompt and response content as potentially sensitive. Instrumentation should make content capture an intentional policy decision.

Trace the full decision path

A trace represents one end-to-end task. Spans represent the work inside it: a model call, retrieval query, tool execution, handoff, guardrail, or approval.

A useful trace should let an operator answer:

1. What context did the agent receive?
2. Which instructions and policies were active?
3. Which tools could it access?
4. Why did it select this tool sequence?
5. What did each tool return?
6. Where did latency and cost accumulate?
7. What final action occurred?

The OpenAI Agents SDK tracing guide models traces around generations, tool calls, handoffs, guardrails, and custom events. LangSmith’s observability model similarly organizes work into projects, traces, runs, and threads, then attaches feedback, metadata, and tags.

The product matters less than the discipline. A trace should reconstruct the event without requiring the original builder to remember how the agent was supposed to behave.

Build evaluations before you scale traffic

An evaluation is a repeatable test of whether the system did the job well.

Start with a small set of representative examples drawn from real work. Include routine cases, edge cases, ambiguous requests, missing information, conflicting sources, and tasks the agent should refuse or escalate.

For each example, define what good looks like. Depending on the task, an evaluator might check:

• Correct final classification.
• Factual grounding in approved sources.
• Required fields present in structured output.
• No invented claims.
• Correct tool usage.
• Compliance with business policy.
• Appropriate escalation.
• Tone and clarity.
• Cost and latency within target.

Offline evaluations

Offline evals run against a controlled dataset before release. Use them when changing the model, prompt, retrieval strategy, available tools, or business rules.

They answer: did the proposed version improve or degrade performance on known tasks?

Keep the previous version as a baseline. A new model that improves average answer quality but doubles unsafe actions is not an upgrade.

Online evaluations

Online evals score real production runs after launch. They can evaluate every run or a sample, depending on volume and cost.

They answer: is the deployed system continuing to perform well on actual traffic?

Online evaluation is where novel failures appear. Production users ask questions the test set did not anticipate, tools change behavior, source data drifts, and business rules evolve.

The LangSmith evaluation documentation treats offline and online evaluation as a continuous loop. Offline testing supports development; production feedback generates new cases for the next test set.

Evaluate the trajectory, not only the answer

For a simple generation task, the final answer may be enough. For an agent, the route matters too.

An agent can arrive at a correct answer after using an unauthorized source, exposing data to the wrong tool, or making ten calls where two would have been enough. Evaluate:

• The final response.
• The sequence of tools and handoffs.
• Important individual steps.

LangSmith’s complex agent evaluation guide separates those three levels: final response, trajectory, and single-step evaluation.

Human approval should be action-specific

“Human in the loop” is not a complete control design. The system needs an explicit approval contract.

Define:

• Which action pauses.
• Why it pauses.
• Who can approve it.
• What context the reviewer receives.
• Whether the reviewer can edit the action.
• How long the approval remains valid.
• What happens after rejection or timeout.
• How the decision is recorded.

Common approval points include:

• Sending an external message under a person’s name.
• Issuing a refund or changing financial records.
• Deleting or overwriting data.
• Changing access or permissions.
• Publishing content.
• Making claims about legal, medical, financial, or contractual matters.
• Taking action when confidence is below a defined threshold.

The reviewer should see the proposed action, relevant evidence, and the agent’s uncertainty. A generic “approve” button without context turns oversight into theater.

Use confidence carefully

A model saying it is confident does not prove the answer is correct. Confidence should come from observable signals where possible:

• Retrieval found authoritative sources.
• Required fields were present.
• Independent checks agreed.
• The output passed deterministic validation.
• Similar examples scored well in evaluations.
• The task fell within a known operating range.

Use uncertainty as one input to routing, not as a magical probability of correctness.

Alerts should point to action

An alert is useful only when someone knows what to do next.

Monitor at least:

• Failure rate by task and version.
• Approval rate and rejection reason.
• Human correction rate.
• Tool error and timeout rate.
• Repeated retries or loops.
• Latency percentiles.
• Usage and cost per successful task.
• Grounding or policy evaluation scores.
• Escalation volume.
• Downstream completion rate.

Set alerts around meaningful deviations, not every isolated error. A single third-party timeout may retry safely. A sudden increase in tool failures, empty retrieval results, or approval rejections deserves attention.

Every alert should name an owner, contain the run ID, link to the trace, and state the first diagnostic step.

Protect sensitive data in the observability layer

Logs and traces can become a second copy of sensitive business data. Treat the observability platform as part of the system’s security boundary.

Use these controls:

• Redact secrets, tokens, and sensitive fields before capture.
• Store references instead of full payloads when possible.
• Limit content capture by environment and task type.
• Apply role-based access and retention rules.
• Separate production and development projects.
• Review whether a vendor trains on or retains trace data.
• Include trace stores in deletion and incident-response procedures.

The OpenAI Agents SDK configuration guide provides controls for disabling tracing or excluding sensitive inputs and outputs. Whatever framework you use, make the policy explicit.

Version everything that can change behavior

Store the version of:

• System instructions and prompt templates.
• Model and inference settings.
• Tool schemas.
• Retrieval index or knowledge snapshot.
• Business policy.
• Evaluation dataset and graders.
• Application code.

Without versioning, a failure discovered today cannot be reliably reproduced tomorrow. A trace saying “the agent used the standard prompt” is not enough if the standard prompt changed five times.

Add stop conditions and a kill switch

Every agent needs limits. Examples include:

• Maximum tool calls.
• Maximum run time.
• Maximum cost or token usage.
• Maximum retries per tool.
• Allowed domains or records.
• Disallowed action combinations.
• Stop after repeated low-confidence results.

A kill switch should disable the agent’s consequential actions without taking down the rest of the business workflow. The system may continue to collect requests and route them to humans while the agent is paused.

A 30-day operating plan

Before launch

Create the first evaluation dataset, instrument traces, define approval points, test failure paths, redact sensitive values, and assign an owner.

Week one

Run in shadow mode or with conservative approvals. Compare agent output with what humans actually do. Review traces daily.

Weeks two and three

Turn repeated failure patterns into new eval cases. Improve retrieval, instructions, tool descriptions, and deterministic validation. Track cost per successful outcome.

Week four

Review whether any actions can safely receive more autonomy. Document known limitations, response procedures, and the next review date.

At Friday Labs, this is why “run and improve” is a separate part of the system lifecycle. Launch creates evidence. The system becomes reliable through measured operation, not optimistic assumptions.

Frequently asked questions

What is AI agent observability?

AI agent observability is the ability to inspect an agent’s inputs, model calls, tool calls, decisions, outputs, timing, cost, errors, and business outcome. It combines conventional monitoring with agent-specific traces and quality evaluations.

What is the difference between a log and a trace?

A log records an event. A trace connects the events that belong to one end-to-end task and shows their timing and relationships. Both are useful, but traces are better for reconstructing multi-step agent behavior.

How do you evaluate an AI agent?

Define a representative dataset and measurable criteria for the final answer, tool trajectory, policy compliance, and business outcome. Run those evaluations before release and continue sampling production runs after launch.

When should a human approve an agent action?

Require approval when an action is difficult to reverse, affects money or access, communicates externally with material consequences, or falls outside the agent’s tested operating range.

Should prompts and responses be stored in traces?

Only when the diagnostic value justifies the privacy risk. Redact sensitive data, restrict access, set retention rules, and use references or sampled capture where full content is unnecessary.

Sources and methodology

This guide draws on Friday Labs’ internal AI Audit operating principles and current primary documentation from OpenAI tracing, LangSmith observability, LangSmith evaluations, Anthropic’s agent evaluation guidance, and the OpenTelemetry generative AI semantic conventions.