5 resources for checking what an AI agent actually did
Choose the documentation that fits the evidence missing from your workflow.
Suppose an assistant says it has added a customer record and prepared an internal follow-up. The record exists, but the follow-up has failed. Before repeating the whole request, someone needs to establish which part finished. That is a hypothetical question an owner and developer should be able to answer together.
These five maintainer resources address different parts of that problem. Use them to locate execution, inspect results and decide how to recover when only part of a task succeeds.
1. OpenAI Function calling: separate the request from execution
OpenAI's function calling guide shows the application receiving a tool call, executing code and returning the output to the model. This gives a developer a place to examine the hand-off when an assistant says it has done something.
For a calculation, ask the developer to show the requested arguments and the result returned by the implementation. In a disposable test, disable the implementation and inspect what reaches the next step. Decide what the application should report when execution cannot happen.
Start here when the team needs to understand its tool-calling loop. The examples use OpenAI's API. An execution result still needs to be checked against the task the person asked for; this guide does not establish that a customer record or message in another system is correct.
2. MCP Tools: inspect the interface and its errors
The Model Context Protocol Tools specification describes tool inputs and returned results. It distinguishes protocol errors from execution errors, including validation and business-logic failures reported through the tool result.
Choose a tool with a simple input you can check, such as a date range. Compare a valid request with a deliberately invalid one in a test environment. Ask which result tells the caller the operation failed and what the assistant is then allowed to tell the user.
This is useful when different clients and servers exchange tool calls. The linked specification is the 28 July 2026 revision; check the revision your implementation supports before copying an example. A valid input shape leaves the business responsible for deciding who may perform the action and what counts as success.
3. OpenAI Tracing: follow a run into its individual steps
OpenAI's Tracing guide explains how to inspect an Agents API session, open a turn and examine recorded steps. Those records include inputs, outputs, duration and status, and the guide describes exporting a trace.
Take a run whose final answer says the task is complete. Find the tool step that should support that statement and compare its recorded output with the answer. Keep a specific gap, such as a missing result or an error that the final answer did not explain, as something the developer can investigate.
Use this guide for the OpenAI Agents API workflow it documents. It does not describe every agent framework or prove that an external system contains the intended result. For a customer update, inspect the customer system as well as the trace.
4. LangGraph Persistence: identify which state was saved
The LangGraph Persistence guide separates checkpointers, which save a thread's graph state, from stores, which hold application-defined information across threads. That distinction helps a developer explain what the workflow remembers and where that information belongs.
For an interrupted test run, identify its thread and the state saved for it. Then list any changes already made outside the workflow. Before resuming, agree which of those changes needs a separate readback so the team can decide what to repeat.
This is a resource for teams using LangGraph, with code examples and further checkpointer and store documentation. Reading a saved workflow state answers a different question from inspecting the resulting customer record. Ask the developer to show how those two records are reconciled in the implementation you plan to use.
5. Microsoft: plan for partial completion
Microsoft's Compensating Transaction pattern examines operations whose completed steps need compensation after a later failure. It explains why recovery depends on business rules and may require manual intervention. Compensation can fail too, so the pattern discusses recording progress and designing repeatable recovery steps.
Use a hypothetical customer record followed by a failed internal notification. Write down which step completed, what evidence identifies it and which recovery would leave the business in an acceptable state. Ask who should decide whether to retry the notification, change the record or leave it in place for review.
This distributed-systems pattern includes Azure examples. It is useful when the team needs to discuss recovery beyond prompting. The source explicitly warns that compensation may not restore the original state; define the intended business outcome before choosing an undo operation.
Choose the resource from the question you cannot yet answer
Begin with the missing evidence in a specific workflow. The function-calling guide helps locate execution in the application. The MCP specification helps examine the interface. Tracing and persistence address the recorded steps and saved state. The compensation pattern helps frame recovery after work has already changed something.
Business instructions need attention alongside execution. The exercise in Your AI needs to know which decisions still apply examines whether an agent uses the arrangement that governs the current request. The AI builders guide provides a separate route to practitioners' original technical work.
If your team needs help deciding which work an agent should handle and what it may change, see AI advisory.
Sources
- OpenAI Function calling
- Model Context Protocol Tools
- OpenAI Tracing
- LangGraph Persistence
- Microsoft Compensating Transaction pattern
Sources checked on 19 October 2026.