Agent traces need a data budget as well as a debugging budget
Agent traces can copy business data into a second system. Choose payloads, access and retention deliberately, reserving full capture for bounded diagnostics.
By 
Paul. AI and agentic engineering
Trace capture should be designed as an application data flow. Decide which payloads are needed, who can inspect them and when they should disappear before debugging convenience creates a second archive of business content. Full capture can be justified for a bounded investigation in an isolated diagnostic environment. It should not become the production default merely because a tracing system can display everything.
Looking back from November 2026, OpenAI's 11 March 2025 launch announcement introduced the Agents SDK alongside integrated tools for inspecting workflow execution. The Python repository's v0.0.2 release, dated 11 March, labels itself the initial release. Those sources establish the launch context. Current controls need separate documentation rather than being projected back onto that first release.
A trace is another destination for application information
Consider an illustrative assistant that drafts a reply from a customer message and an internal account lookup. A trace might help explain why the assistant selected a tool or why a handoff happened. If the captured material includes the message, lookup result and generated reply, it also contains a second copy of data originally handled for the customer interaction.
That copy has its own audience. A developer diagnosing an execution problem may not need the entire account record. A support colleague may need to correlate an incident without reading the user's message. The application should distinguish those purposes rather than treating everyone who helps operate the service as entitled to every captured field.
Retention creates another distinction. The interaction may be complete while the trace remains searchable. Deleting the original record does not establish that diagnostic copies have disappeared. A retention decision needs to name every destination that receives trace data, including custom exporters. This is an operational design argument, not a claim about a particular account's configured retention or a legal compliance certification.
Choose evidence by the question it answers
Start with the question an operator expects to investigate. If the problem is which tool ran, a tool category and outcome may suffice. If the problem is a slow stage, timings and linkage identifiers may answer it. If the problem is an incorrect interpretation of a message, content may be relevant, but that does not make all surrounding records relevant too.
A proposed production trace can begin with selected structural information and add content only where there is an identified purpose. Correlation identifiers deserve review as well: a convenient customer name embedded in a workflow label can disclose information even when the large payload fields are absent. Metadata is still data.
Sampling and payload selection answer different questions. Sampling fewer complete traces reduces how often data is captured, but it does not change what an individual sampled trace reveals. Reducing payloads can limit that exposure while preserving broad operational coverage. A team should decide both rather than using a sampling percentage as a substitute for inspecting fields.
The cost budget also includes attention. A large archive is useful only if someone can locate relevant evidence and interpret it. Assign the investigation question and the person expected to answer it. Otherwise detailed capture can increase storage and exposure without creating a practical debugging path.
Current controls require current reading
The current Python SDK tracing documentation, consulted in November 2026, says tracing is enabled by default and describes global and per-run disabling. It documents RunConfig.trace_include_sensitive_data, whose default is true, for controlling sensitive input/output capture. This is current reference behavior, not evidence that every detail existed in March 2025.
The documentation also distinguishes adding a trace processor from replacing the processors. Adding one leaves the default exporter in place. It warns that a redaction processor followed by a separate exporter does not establish a failure-safe redaction boundary: other observers may still receive data if processing fails. An application needing controlled export should keep redaction and delivery in the same owned path and replace default processors appropriately.
Those controls are useful implementation inputs, but they do not configure an organization's entire access and retention policy. A deployment should verify its installed SDK version, exporters and effective settings, then review what actually reaches each destination. This article makes no API requests and claims no observed behavior from a running agent application.
Full payloads can answer a bounded diagnostic need
The strongest objection is that structural traces can miss exactly the evidence needed to explain an incorrect answer. When the error depends on wording or an unexpected tool result, timings alone will not show the cause. Prohibiting all content capture would make some investigations unnecessarily difficult.
A bounded isolated investigation can address that need. Define the question first, use synthetic or appropriately authorized minimized material, restrict access and set an end to the capture window. Decide how diagnostic copies will be removed. Full payload capture belongs only inside that described scenario; it is not a standing instruction to copy production customer interactions into another environment.
Isolation also needs a concrete meaning. A different project name does not by itself separate credentials, export destinations or access. Record those boundaries and who checks them. If the necessary content cannot be used within the approved conditions, narrow the investigation or find another source of evidence instead of quietly extending capture.
Make the trace contract part of delivery
For custom software development, request a short trace contract with the workflow design. It should identify the purpose of captured fields, recipients, access owner and retention decision, plus the procedure for a temporary diagnostic exception. Keep that contract connected to the code that selects and exports data.
The launch made execution inspection a visible part of agent development. The durable engineering decision is to preserve enough evidence to explain a failure without accumulating business content by accident. Decide the data budget alongside the debugging budget, and revisit both when a new tool or exporter changes the flow.