OpenAI Agents API Adds Long-Running Web Search: What Publishers Can Measure

OpenAI's Agents API can run persistent workflows with web search and other tools. Publishers still need separate evidence for fetching, citation and referral outcomes.

Direct answer: OpenAI’s Agents API gives developers a persistent runtime for workflows that can use web search, MCP servers and custom functions. That makes repeated publisher-monitoring tasks easier to build, but it does not turn every agent action into a page fetch, citation or referral.

Key Moments

Agents can keep working The API adds long-running sessions, context compaction, tool search and programmatic tool calls.
Web search is one available tool The launch does not say every agent run will fetch or cite a publisher page.
Three outcomes need three measurements Fetch activity, citation appearance and referral sessions should never be collapsed into one visibility metric.
Use repeated controls The downloadable ledger pairs prompts, source states, citations, logs and referrals with negative controls.

Publishers should measure those outcomes separately. A server-log event shows access, a cited URL shows selection, and an analytics session shows a visit. None proves the other two.

What the Agents API adds

OpenAI introduced the Agents API public beta on September 10, 2026. It supports long-running sessions, context compaction, tool search, programmatic tool calls, multi-agent patterns and built-in web search. Developers can use an OpenAI-managed sandbox, their own infrastructure or supported partners.

OpenAI says there is no separate Agents API fee beyond the models and tools used. Actual workflow cost still depends on tokens, searches, tool calls, duration and the developer’s own infrastructure.

The publisher opportunity is repeatable observation

A long-running workflow can rerun a stable prompt panel, store the response, extract cited domains, compare changes and notify an analyst only when a meaningful threshold is crossed. It can also combine public output with first-party checks, such as server logs or analytics exports, through controlled functions.

This can reduce collection work in an AI search measurement program. It does not remove the need to define the panel, preserve controls or review ambiguous citations.

Fetch, citation and referral are different events

Publisher evidence layers for an agent search workflow
Event	Best evidence	What it cannot prove
A system requested a page	Origin or edge server log	That the page was cited
A response named a page	Saved response and cited URL	That a user visited it
A visit reached the site	Analytics and request parameters	That the preceding answer used the page

Keep a shared run ID and timestamp across the three layers. Where a platform does not expose a common identifier, use narrow time windows and label the match as inferred rather than exact.

A publisher monitor needs a fixed question panel

Group questions by audience task, not by slight keyword variation.
Save the exact prompt, locale, account state and agent configuration.
Run a consistent set of brand, category and problem queries.
Capture every cited URL, not only your own domain.
Record whether the answer’s claim is supported by its cited page.
Check logs and referrals in the same observation window.
Repeat on a declared cadence and flag material changes.

A rotating collection of trendy prompts can produce interesting screenshots but no comparable time series. Stability is what turns monitoring into evidence.

Negative controls reveal false attribution

Include one page that is intentionally absent, one known competitor page, and one source-state change that you can reverse. If the workflow reports access to the absent page or attributes a referral without a matching request, the measurement layer needs correction.

For crawler-specific checks, follow the AI crawler log verification workflow. User agents and published crawler documentation can change, so save the raw request rather than only a normalized dashboard label.

Cost should be calculated per useful observation

A persistent agent may search several times, call tools and retain a long thread. Record model tokens, web-search calls, function calls, runtime and analyst review minutes. Divide total cost by the number of usable, verified observations, not by the number of prompts sent.

A cheap monitor that misses citation changes or generates false alerts costs editorial attention. An expensive one that checks every hour may be unnecessary when the observed surface changes weekly.

Retrieved pages are untrusted input

Web pages can contain instructions aimed at an automated agent. Keep retrieved text separate from system policy, restrict write-capable functions, validate arguments and require approval for external actions. A monitoring agent normally needs read-only access.

Do not give a public-web monitor unrestricted access to publishing credentials, customer records or analytics administration. The safest architecture moves only the minimum aggregated evidence into the workflow.

Download the publisher observation ledger

Download the Agents API observation CSV. It keeps prompt hash, configuration, source state, log match, cited URL, referral evidence, support review and a negative control in one row.

The EXAMPLE-REMOVE row is illustrative. It is not an observed OpenAI run and should be replaced before analysis.

What the launch does not establish

OpenAI’s announcement documents developer capabilities. It does not provide a publisher traffic study, guarantee that web search fetches every cited page, or define how often agent answers produce outbound visits. Those are research questions for a controlled panel.

The defensible conclusion is narrower: developers now have a more persistent environment for building the measurement loop. The quality of the evidence still depends on the test design.

Primary documentation

Keep learning

Continue this topic

Next in this topic