DEV Community: Amit

Search Is a Pipeline, Not a Tool

Amit — Sun, 13 Sep 2026 08:53:21 +0000

TL;DR

Search for agents has five distinct stages: discovery, extraction, verification, synthesis, and monitoring or state.
A successful search call proves only that discovery returned candidates. It says nothing about page freshness, factual support, answer quality, or whether a monitoring loop will run again.
The evidence set contains 153 direct cases across four provider deep dives. Each stage needs its own contract, evidence, and failure handling.
RSS can be a cheap discovery source for recent news, but it does not replace extraction or verification.
The unresolved problem is confidence transfer: evidence can weaken between stages even when every individual API call succeeds.

Search for agents is a pipeline, not a tool. Discovery finds candidates. Extraction turns pages into usable evidence. Verification checks whether that evidence supports the claim. Synthesis produces the answer. Monitoring and state decide whether the work can continue, repeat, or recover.

Collapsing those stages behind one web_search button makes the architecture look simple. It also makes failures harder to see. A request can return HTTP 200, five plausible links, and a polished answer while still failing the actual job.

The evidence set contains 153 direct cases across four provider deep dives: 41 Exa Search, Contents, and Answer cases; 35 Parallel search, extraction, response, chat, task, and entity cases; 30 Perplexity search, agent, Sonar, and embedding cases; and 47 AgentCore Web Search retrieval cases. Separate MCP and lifecycle checks extend the evidence for transport, continuation, cancellation, and cleanup.

The five-stage architecture

Stage	Job	Output	Failure that a 200 response can hide
Discovery	Find likely sources	Ranked URLs, titles, snippets, dates	Narrow coverage, weak ranking, missing dates
Extraction	Retrieve useful page content	Text, sections, highlights, metadata	Stale cache, truncated content, rendering gaps
Verification	Test evidence against the question	Supported claims and rejected claims	Plausible but unsupported facts
Synthesis	Build the answer or research artifact	Cited prose or structured output	Tool enabled but never invoked, citation drift
Monitoring and state	Repeat, continue, cancel, and recover	Run IDs, events, checkpoints, terminal state	Orphaned work, missed changes, unverified delivery

These are different jobs. They also have different economics. Discovery is often priced per query. Extraction can be priced per page. Synthesis adds model and tool costs. Monitoring introduces schedules, webhooks, retained state, and cleanup.

That distinction changes how an agent should be built and tested.

Discovery is candidate generation

Discovery answers one question: where should the agent look?

A dedicated search API is one answer. A managed connector is another. For narrow recent-news work, a structured public feed such as Google News RSS can also provide a useful candidate stream. The cheap pattern is straightforward:

RSS or search query
  -> candidate URLs
  -> relevance and recency filter
  -> extraction from the strongest sources

RSS remains one inexpensive example, not a substitute for broad web search. It is useful when the job is recent, public, and headline-oriented. It is weak for technical documentation, long-tail pages, exact site retrieval, and any task that needs dependable coverage semantics.

AgentCore Web Search returned exactly the requested 1, 5, and 25 results and honored 40 out of 40 tested domain and date constraints. That establishes a strong discovery contract for those cases. Its managed Web Search connector returns ranked snippets and source metadata, but it does not fetch arbitrary URLs. Discovery succeeded; the next stage still needed another component.

Extraction is where the page becomes evidence

A result snippet is not the page. Extraction follows a known URL, retrieves content, and shapes it for the agent's context window.

Both Exa Contents and Parallel Extract handled HTML, longer text, and multi-page cases in the bounded tests. Exa also returned highlights, summaries, subpages, links, and image links across the bounded cases. Parallel exposed freshness policies and shared sessions.

A same-URL extraction check produced two successful, nonempty responses and one stale copy. The full result belongs in Part 4; the architectural point is that schema validation and freshness validation are different stages.

This is why extraction needs its own evidence record:

requested URL
retrieved URL
retrieval timestamp
content timestamp, when available
cache or freshness policy
content hash
extracted text

Without that record, the agent cannot explain whether a contradiction came from search ranking, cached page content, or later reasoning.

Verification is a separate computation

Verification asks whether the extracted evidence supports the answer. It does not ask whether the API returned citations or whether the prose sounds confident.

The saved-output reviews contain complete, partial, and incorrect answers even when transport and schema checks pass. Part 4 carries the provider counts and fact pattern. The pipeline contract only needs the conclusion: generated answers require a different test from search results.

A practical verification stage should preserve three sets:

Claims the evidence directly supports
Claims the evidence contradicts
Claims for which the evidence is incomplete

That third set matters. A search pipeline should be able to stop with “not established” instead of converting missing support into fluent prose.

Synthesis must prove that the tool ran

Synthesis is where search results become a response, report, table, or structured object. Modern agent products combine models with web search, URL fetch, finance or people search, code execution, and other tools. Perplexity's Agent API and Exa's Agent API are examples of that broader surface.

Tool availability is not tool use. The evidence set includes a successful agent response where an enabled specialized tool did not run. That failure mode is examined in Part 4.

That creates another contract boundary. A synthesis run should retain:

which tools were offered;
which tools were invoked;
the arguments and result identifiers;
the evidence attached to each final claim;
token, tool, and provider-reported cost where available.

A polished answer without an invocation trace is not proof that grounding happened.

Monitoring turns search into a system

A one-time answer ends after synthesis. A research system needs continuation, schedules, change detection, cancellation, and recovery.

Parallel's Monitor API exposes event-stream and snapshot lifecycles. Exa's Monitor API requires a public HTTPS webhook. Those product differences determine what state, delivery, and cleanup evidence the pipeline must retain; Part 4 records the tested outcomes and remaining delivery gap.

This stage is where search acquires state. The minimum durable record is no longer a query and response. It includes a run ID, schedule, cursor or previous-run link, event history, terminal status, retry policy, and cleanup result.

A monitor that was accepted but never delivered an event is not working monitoring. A background run without a retained identifier is not recoverable state. A cancellation request without a terminal read-back is not confirmed cleanup.

The pipeline contract

The clean architecture is a chain of explicit artifacts:

Question
  -> discovery manifest
  -> extracted evidence packet
  -> verification ledger
  -> synthesized answer
  -> state and monitoring record

Each arrow is a contract. Each artifact can be inspected without rerunning the whole system. Each stage can change providers without forcing the rest of the pipeline to adopt the same vendor.

That modularity also makes cost control clearer. Cheap discovery can shortlist candidates before paid extraction. Verification can run only on claims that affect the answer. A research agent can use deeper synthesis selectively. Monitoring can schedule only the queries whose changes matter.

The point is not to assemble the largest stack. It is to know which stage owns each promise.

What's still missing

The evidence measures contracts, bounded behavior, latency samples, saved-output quality, and lifecycle cleanup. It does not measure how confidence degrades across the entire pipeline.

A discovery stage can miss the best source. Extraction can return stale content. Verification can overlook a contradiction. Synthesis can cite the right page for the wrong sentence. Monitoring can rerun the same weak query perfectly on schedule.

The open thread is how to score that transfer of confidence from one stage to the next. What metric can distinguish discovery diversity that improves the final answer from diversity that adds latency, cost, and more evidence for the verifier to reconcile?

Part 3 of the Search for Agents series.
← Part 2: What Actually Differs Across Search APIs Built for Agents · Part 1: Search for Agents Is Becoming Its Own Market · Part 4: A 200 Response Does Not Prove Search Worked →

A 200 Response Does Not Prove Search Worked

Amit — Sun, 13 Sep 2026 08:52:45 +0000

TL;DR

HTTP 200 proves that a server accepted a request and returned a response. It does not prove that the requested filter was applied, the evidence was current, the expected tool ran, the answer was supported, the job stopped, or the cost was zero.
The evidence set contains 153 standardized or direct cases across AgentCore Web Search, Exa, Parallel, and Perplexity. Separate MCP and lifecycle work tests tool discovery, monitoring, webhooks, background runs, cancellation, and cleanup. This is an execution inventory, not a universal quality ranking.
A successful page fetch contains stale PostgreSQL release data. A successful Perplexity Agent API call with People Search enabled records no invocation; an explicit people-search prompt records one. Successful generated answers introduce an unsupported 501 Not Implemented claim into the fact pattern being tested.
One seeming AgentCore filter gap belongs to the local adapter and connector version, not the service. The failure sits in the evaluation path.
Unknown cost is not free usage. Missing billing metadata stays unknown until a defensible rate or invoice establishes it.

HTTP success is transport evidence. Search quality requires evidence beyond transport.

That distinction sounds obvious until an evaluation counts every 2xx response as a pass. Agent-search products combine retrieval, page extraction, models, tools, background jobs, monitors, and remote MCP servers. Each layer can return a technically successful response while failing the reason it was called.

The evaluation contract therefore needs six separate proofs:

Layer	What success establishes	What it still does not establish
Transport	The endpoint responded and the client parsed it	The requested behavior occurred
Contract	Parameters, schema, and limits behave as specified	The returned evidence is correct
Evidence	Sources support the required facts and time window	The agent uses the intended tool
Tool invocation	The expected search, fetch, finance, or people tool runs	The final answer uses its output correctly
Lifecycle	Runs reach a terminal state and disposable state is cleaned up	The spend estimate matches the bill
Cost	Usage has a stated basis: provider-reported, list-price estimate, invoice, or unknown	The product is the best choice

A single green status cannot collapse these layers into one result.

153 cases, without a 153-cell leaderboard

The direct execution count across the provider-specific suites is 153:

Provider suite	Standardized or direct cases
Amazon Bedrock AgentCore Web Search	47
Exa Search, Contents, and Answer	41
Parallel Search, Extract, Responses, Chat, Task, and Entity Search	35
Perplexity Search, Agent API, Sonar, and Embeddings	30
Total	153

Those cases do not form one interchangeable benchmark. AgentCore contributes 47 retrieval cases. Exa contributes 41 cases across search, extraction, and generated answers. Parallel and Perplexity cover broader product surfaces. The suites establish which contracts and failure modes receive direct evidence.

MCP sessions, deep-research runs, task groups, monitors, webhook verification, background cancellation, and other lifecycle controls remain separate. Combining them into the 153 would inflate the number without making the comparison more useful.

The retrieval lane uses 30 fixed questions, four providers, and 1,200 results. It measures retrieved evidence under fixed conditions. It does not establish a universal answer-quality winner.

A successful fetch can return stale evidence

The page-fetch control sends the same four URLs through two extraction products. Every request succeeds. Every returned URL matches. Every body is nonempty and stays within the configured character cap.

One result demonstrates stale evidence.

For the PostgreSQL versioning page, one fetched copy reports PostgreSQL 18.4 and 17.10. The other reports 18.6 and 17.11, matching the official page in the frozen reference check. The stale response has valid text, a valid URL, and a successful status.

Transport: pass. Content: fail.

This changes the minimum test for page fetch. Nonempty text is only a structural assertion. Freshness-sensitive extraction also needs a dated reference fact, a live-source comparison, or a cache-control experiment. A fetch product can satisfy its API contract while returning evidence that no longer satisfies the user's question.

Enabling a tool does not prove the tool ran

Agent APIs add another gap between configuration and execution. Perplexity documents that tools must be configured in the request, and the model decides when to invoke them from the prompt and instructions.

That distinction appears in the People Search case. A request enables People Search and completes successfully, but its usage record shows no People Search invocation. The prompt is a plausible people-research request, yet the model answers without the specialized tool.

The explicit control names the people-search task. Its usage record contains one search_people invocation, matching the People Search usage field documented by Perplexity.

Both requests completed. Only one proved the intended capability.

Tool evaluations need three assertions:

The tool is present in the request or discovered through MCP.
The response records that the tool was invoked.
The output contains evidence produced by that invocation.

Tool availability is configuration evidence. Tool-call telemetry is execution evidence.

Generated answers can succeed and add unsupported facts

Generated-answer endpoints expose another kind of false positive. The response can be fluent, cited, and structurally valid while adding a claim that its cited source does not support for the tested operation.

The frozen question asks about Amazon S3 conditional writes using If-None-Match and If-Match. The official conditional-write reference documents 200 OK, 412 Precondition Failed, and concurrent-delete cases that produce 409 Conflict or 404 Not Found.

Across the saved Perplexity configurations, 13 comparable answers have frozen grades against that reference: eight complete and five incorrect. Four incorrect configurations add 501 Not Implemented to the tested write behavior. Parallel's saved Chat review contains three incorrect answers out of five, with unsupported 204 No Content or 501 Not Implemented claims added to the same fact pattern.

There is a nearby S3 policy page where 501 is valid for a different operation: CopyObject requests using those conditional headers. That is exactly why citation presence is insufficient. A true statement from a related page can become a false answer when moved to the wrong operation.

This is one frozen fact pattern. It does not rank either provider's general accuracy. It proves a narrower point: a successful generated answer needs claim-level checking against the operation, scope, and source text.

Capability exists at three layers

A vendor feature is usable only when three current layers agree: the vendor documents it, the active endpoint exposes it, and the adapter forwards it.

The AgentCore connector-version reference identifies request-level domain and published-date filters as a version 1.2.0 capability. The active target exposes that schema, the adapter forwards the filter object, and the fixed suite returns 40 of 40 compliant constrained results.

Checking only one layer can create a false product claim. Documentation alone does not prove account exposure. Endpoint discovery alone does not prove the client sends the field. A successful client request does not prove the provider honored the constraint.

A credible evaluation stores enough detail to locate the failing layer:

endpoint and connector version;
discovered tool schema;
exact request shape emitted by the adapter;
raw response shape;
client-side validation result.

Without that trail, a local omission becomes a product claim.

Long-running search needs a cleanup proof

Background research and monitors create state that outlives the request. Their success criteria include termination.

Exa Monitors require a public HTTPS webhook at the final destination; HTTP, localhost, private addresses, and redirecting URLs do not satisfy the delivery contract. A useful monitor test therefore needs more than successful creation. It needs signature verification, a triggered or scheduled run, delivery evidence, lifecycle updates, and deletion or another documented terminal cleanup action.

The Exa Monitor row remains not run because the evaluation has no approved public webhook. A create response without delivery evidence would not satisfy the monitor contract.

Parallel's event-stream and snapshot monitor evidence covers create, retrieve, update, and cancel. The terminal read-back shows both as cancelled. The Parallel cancellation contract describes cancellation as irreversible and exposes active and cancelled states. Its webhook guide adds signature verification, retry behavior, and duplicate-event handling to the production contract.

Cancellation deserves the same discipline. One Exa Agent case contains an accepted graceful-stop response alongside an active run with increasing usage. Explicit cancellation plus a terminal read-back establishes cleanup. The accepted stop response alone does not.

For stateful search, cleanup evidence is part of correctness:

create -> retain identifier -> poll -> verify output -> stop or cancel
       -> read terminal state -> confirm no active test runs remain

Losing the identifier or skipping the final read converts a successful request into an unmanaged job.

Unknown cost is not zero

Search evaluations often make one last status-code mistake: treating absent cost metadata as $0.

The Perplexity pricing model separates model tokens from tool invocations and reports request cost when that field is available. The official MCP calls in this evaluation return no usage record, so their cost basis is a public list-price estimate. One Deep Research response reports zero cost alongside substantial citation tokens, reasoning tokens, and searches; the evidence therefore carries both the provider-reported value and a separate conservative list-price estimate.

Exa has three accepted or attempted paths whose billing cannot be established from the returned evidence. Their cost remains unknown. Parallel's accounting separates standardized-run totals from lifecycle additions and stops at public rates rather than claiming invoice proof.

Every cost number needs a basis:

Provider-reported: returned by the API, not invoice-verified.
List-price estimate: computed from a dated public rate card and observed usage.
Invoice-verified: reconciled against billing data.
Unknown: no defensible basis.
Not incurred: a dry run that made no provider request.

Unknown and zero answer different questions.

The evaluation artifact is the product

The durable output of an agent-search test is not a pass count. It is a chain of evidence:

request manifest
  -> transport record
  -> contract checks
  -> source and claim review
  -> tool-call telemetry
  -> lifecycle ledger
  -> cost basis

That chain explains which layer passes, which layer fails, and whether the failure belongs to the vendor, the adapter, the model, the evidence, or the test itself.

The open thread is portability. Each provider exposes different usage fields, lifecycle states, citations, and tool-call traces. What is the smallest evidence contract an agent harness can require across all of them without discarding the details needed to explain a failure?

Part 4 of the Search for Agents series.
← Part 3: Search Is a Pipeline, Not a Tool · Part 2: What Actually Differs Across Search APIs Built for Agents · Part 1: Search for Agents Is Becoming Its Own Market

Search for Agents Is Becoming Its Own Market

Amit — Sat, 12 Sep 2026 18:09:26 +0000

TL;DR

I ran a head-to-head benchmark across four search APIs built for agents — Exa, Perplexity Search API, Parallel, and Amazon Bedrock AgentCore. There's no single winner: Exa leads on primary-source coverage, Perplexity on useful-result density, AgentCore on latency.
Tavily, a search-for-agents startup that had raised $25M total, got acquired by Nebius for $275M in February 2026 — a ~98x revenue multiple most "which search API is best" comparisons never mention.
No analyst firm tracks "search API for agents" as its own category yet. The closest proxy, Fact.MR's agentic tool-use/API-integration estimate, puts the whole adjacent category at $6.9B in 2026 — and that's every agent-tool-integration dollar, not search specifically.
"Search API for agents" is actually four different businesses wearing the same label: agent-native search, raw SERP scrapers, platform-bundled grounding, and enterprise/consumer search that isn't open-web at all.
Exa, Perplexity, and Parallel have all quietly built a second, much more expensive pricing tier for agent/task products on top of their raw search API — the market is redefining "search" as the cheap fraction of a bigger, per-task unit.

I benchmarked four search APIs built for AI agents — Exa, Perplexity's Search API, Parallel, and Amazon Bedrock AgentCore Web Search — across 30 research queries, live filters, page-fetch behavior, and a fixed-model review of 600 saved results. No provider won outright:

Provider	Useful results (/150)	Primary-source results (/150)	Full-facet coverage (/90)	Median latency	Est. cost, 30 searches
Exa	140	92	68	1.807s	$0.21
Perplexity Search	145	69	66	1.750s	$0.15
AgentCore Web Search	124	76	58	0.883s	$0.21
Parallel Basic	112	60	44	0.979s	$0.15

Exa returned the most primary-source evidence. Perplexity returned the most useful results at the lowest search cost. AgentCore was fastest by a wide margin — because it runs its own index instead of querying someone else's.

That result is the boring part. The interesting part showed up once I looked past the benchmark and into what's happening around these four vendors: funding rounds sized like infrastructure companies, a completed acquisition, and pricing tiers that don't map to the "$X per 1,000 queries" number any of them lead with.

The money says this is a real market now, not a feature

Line up the last two years of funding across the vendors in this space and the pattern is infrastructure-company money, not feature money:

Company	Latest disclosed raise	Valuation	Date
Perplexity	in talks for new round	>$30B (proposed)	Aug 2026
Exa	$250M Series C	$2.2B	May 2026
Parallel	$100M Series B	$2B	Apr 2026
Tavily	acquired, not raised	$275M acquisition	Feb 2026

Exa's Series C came eight months after an $85M Series B. Parallel — founded by Parag Agrawal — raised two $100M rounds five months apart. Perplexity's valuation ladder went from $520M in January 2024 to $22.6B in January 2026 before the reported Nvidia talks, on the back of annualized revenue that tripled from under $250M to over $750M in about seven months.

The clearest signal is Tavily. It was a two-year-old company that had raised only $25M total when Nebius acquired it for $275M in February 2026 — roughly a 98x multiple on 2025 revenue. Tavily's own founder framed the deal in exactly these terms: "agentic search is a multi-billion-dollar opportunity, and we believe the market is poised to grow exponentially as enterprises deploy autonomous AI systems." An AI-infrastructure company didn't buy a feature. It bought a search layer to bundle into its own cloud platform.

None of this shows up if you only compare list prices. It shows up when you ask who's writing the checks.

Nobody has drawn the category boundary yet

Here's what surprised me: there's no dollar figure for "search API for agents" as its own line item, anywhere. The closest analyst estimate, Fact.MR's agentic AI tool-use and API-integration market, sizes the whole category — every agent tool call, not search specifically — at $6.9B in 2026, growing to $39.6B by 2036. Two different firms publish an "AI Search Engine market" estimate under the same name and disagree by more than 3x on the ten-year number, and neither one is measuring the developer-facing infrastructure layer this post is about — both are sized around consumer and enterprise AI search products.

That gap matters more than it looks. When a category has no agreed boundary, every vendor gets to draw its own — which is exactly what's happening in the next section.

It's four different businesses, not one

Line up Exa, Tavily, Perplexity Search, Parallel, SerpAPI, Bing Grounding, and Google's Search grounding side by side and they stop looking like competitors. They're four different products that all get called "search API":

Shape	Examples	Billing unit	What you get
Agent-native search	Exa, Perplexity Search, Parallel, Tavily	Per developer-issued call	Cleaned, ranked context sized for a prompt window
Raw SERP scraper	SerpAPI	Per developer-issued call	Unprocessed results-page JSON
Platform-bundled grounding	Bing Grounding, Google Search grounding	Per model-triggered query	Grounding as a feature inside a bigger AI platform
Adjacent, not comparable	Glean	Per seat	Answers from a private internal index, not the open web

Tavily's own docs describe the first row precisely: "the web layer for AI agents." It also has a named partnership as LangChain's recommended search tool — the strongest adoption signal I found for any single vendor. The second row is easy to mistake for the first until you read a direct comparison: "A SERP API returns the raw results-page JSON... An agent search API... returns a short list of already-cleaned, ranked context... They solve different problems and aren't interchangeable." SerpAPI isn't competing with Exa. It's a different tool that happens to share a category label. And Glean has nothing to do with the open web at all — it sits in the same sentence as Exa in a lot of vendor comparisons and shouldn't.

If you're picking a vendor by scanning a feature matrix, you're comparing across all four rows at once without realizing it.

The pricing model is splitting in two

The clearest evidence that this market is maturing is what's happening to price. Three of the four vendors I tested now sell raw search at one rate and an "agent" or "task" tier at a rate that isn't a small multiple — it's a different order of magnitude.

Parallel's Search API runs $1–5 per 1,000 calls. Its Task API runs $5 to $2,400 per 1,000 completed task runs, priced per finished run regardless of how much it did to get there. Perplexity's Agent API decouples further — flat per-tool-call fees on top of direct model token rates, with no markup on the model itself. Exa's own launch post for its Deep search endpoint states the thesis outright: "search and agents are converging... the best way to answer a complex query isn't a single search, it's an agent."

"Cost per completed task" is becoming the standard unit for this, not "cost per query." Artificial Analysis's Search API Index already reports cost per 1,000 benchmark tasks, split into search and model spend, as a named metric across its whole suite — not something invented for one vendor.

What's missing

My own benchmark is priced entirely in the old unit. Every number in it — $7 per 1,000 queries for AgentCore, $5 for Perplexity Search, $7 for Exa — measures cost per query. The vendors' own agent-tier products are priced per completed task, and I haven't run a controlled comparison in that unit. So the two most concrete numbers in this post — my own head-to-head benchmark and the market's newest pricing convention — are measuring two different things, and I don't yet have a bridge between them.

So what

If you're choosing a search API for an agent right now, the vendor comparison you actually need isn't "who scores highest." It's three separate questions: which of the four product shapes does this vendor actually sell, is the number on the pricing page a per-query or per-task rate, and does the pricing model match how many calls your agent will actually make. Get any one of those wrong and you're comparing a SERP scraper to an agent-native API, or a per-query estimate to a per-task bill.

The money already moved. Tavily sold for 98x revenue and Exa, Perplexity, and Parallel are all raising at multi-billion-dollar valuations on the same premise Tavily's founder stated directly — agents will make more search calls than any human ever did, and whoever owns that layer owns real infrastructure. The benchmark numbers tell you who's fastest today. The funding and pricing data tell you this stopped being a feature comparison months ago.

Part 1 of the Search for Agents series. Part 2: What actually differs, feature by feature →

What Actually Differs Across Search APIs Built for Agents

Amit — Sat, 12 Sep 2026 18:08:50 +0000

TL;DR

Raw search mode is the least interesting axis. Exa, Perplexity, Parallel, and AgentCore all return usable results for a basic query — the differences show up in filters, content budgets, page-fetch, and transport, not in whether search works.
Three of four providers had working domain and date filters when I tested them; the fourth's gap was in my own adapter, not the vendor, and closed within a day once I found it.
Page-fetch is where "same data" stops being true: fetching the same PostgreSQL release page through two providers returned two different version numbers, because one provider's cached copy was stale.
MCP as a transport is uneven across vendors — one ships an authenticated remote MCP server with real billing, one is a documentation-only claim I never connected, and one is the same Gateway path the raw API already uses.
None of this shows up in a vendor's own docs page. It only shows up once you run the same 30 queries through all four and compare what came back.

Every vendor's search-API docs page reads the same: send a query, get ranked results, ground your agent. Run the same 30 queries through four of them — Exa, Perplexity Search API, Parallel, and Amazon Bedrock AgentCore Web Search — and the docs page stops being the interesting part. What actually differs is filters, content budgets, page-fetch behavior, and transport.

Raw search: all four work, at different prices

Provider	Modes available	Base price (per 1,000, first 10 results)
Parallel	Basic, Fast, Advanced, Turbo	Fast/Turbo $1; Basic/Advanced $5
Exa	Auto, Fast, Instant	$7
Perplexity Search	Search API (separate from Sonar and Agent API)	$5, no separate token fee
AgentCore Web Search	Native mode through Gateway	$7 queries + $0.005 per 1,000 Gateway invocations

All four returned successful results across ten queries per mode in my own test run. The pricing spread is real, but it's the smallest difference on this list.

Domain and date filters: three worked, one didn't — for a reason that had nothing to do with the vendor

Provider	Domain filter	Date filter
Exa	Live, 60/60 results compliant	Live, 40/40 results compliant, none missing
Perplexity Search	Live, 60/60 results compliant	Live, 38/38 results compliant, none missing
Parallel Basic	Live, 49/49 results compliant	Live, 20 compliant, 12 missing publication metadata
AgentCore Web Search	Live as of Sep 12, 6/6 smoke test, 20/20 compliant	Live as of Sep 12, 15/15 compliant

AgentCore's row looked like a missing vendor feature the day I first tested it. It wasn't. AWS shipped runtime domain and date filtering for Web Search as connector version 1.2.0 three weeks before I ran that test — my own Gateway target was still pinned to 1.1.0, and my adapter only forwarded query text and result count. A version-only update to the target and a small client change closed it the next day. Parallel's 12 missing dates are a different kind of gap: the filter works, but publication metadata is sometimes absent from what the API returns, which the filter can't fix.

Content budgets: same idea, three different units

Every provider lets you cap how much text comes back per result, and every provider uses a different unit for it. Parallel takes a flat character limit per result. Exa separates "highlights" from full page text and caps the latter with an optional text.maxCharacters parameter, documented in its API reference. Perplexity sets a per-page token limit that multiplies by requested result count into a total budget, per its Search quickstart. AgentCore's content shape isn't configurable in the exposed connector at all — you get its native snippet format or nothing.

None of these numbers are comparable directly. "2,000 characters" and "500 tokens per page" aren't the same currency, and a side-by-side comparison that treats them as interchangeable is measuring the wrong thing.

Page-fetch: this is where "the same data" stops being true

Parallel Extract ($1 per 1,000 URLs) and Exa Contents ($1 per 1,000 pages) both fetch a specific URL and return its text, capped at 10,000 characters. I fetched the same four URLs through both. Every fetch succeeded and returned nonempty text — and one of those four URLs still returned two different answers.

The URL was a PostgreSQL release page. Exa's fetched copy showed version 18.4. Parallel's fetched copy — and the live page itself — showed 18.6. Same URL, same provider category, one stale cache. Neither provider's fetch failed by any check I ran; the page text was there, nonempty, under the character cap. The content was wrong in one case, and nothing in the API response flagged that.

MCP transport: three different stories under one protocol name

"Supports MCP" turns out to mean three different things:

Parallel ships an official remote search MCP server with an anonymous, server-managed tier and an authenticated tier with its own billing. I connected and searched through the anonymous tier; the authenticated tier's cost is a separate, unestablished number.
AgentCore doesn't have a second MCP option — the Gateway's MCP endpoint is the API. There's no raw-HTTP alternative to compare it against.
Exa documents a hosted MCP server with search, fetch, and advanced-search tools. I never connected it. Its rate or free-tier billing is not something I can state, because I have no live evidence for it — only the documentation page.

Three vendors, three answers to "does this have an MCP option," and none of the three answers is comparable to the others without saying which kind of MCP you mean.

What's missing

Brave Search and Brave's LLM Context API remain a placeholder in my own testing — I have pricing from Brave's documentation but no live search evidence, and no filter behavior established either way. The generated-answer and managed-research products each vendor also sells — Perplexity's Agent API, Parallel's Task API, Exa's Deep and Agent modes — are a different comparison with a different pricing unit, and nothing in this post's numbers transfers to them. And every live-tested row above is a snapshot: it's accurate as of when I ran it, not a permanent fact about the vendor, which is exactly what the AgentCore filter row already proved once.

So what

If you're picking between these four for an agent, the mode you choose and the price per 1,000 queries are the least differentiating facts on the page. The differences that actually change what you can build are whether a filter parameter is honored server-side or dropped, whether the content budget unit matches how much your prompt window can afford, and whether a fetched page is actually current. Test those four things against your own queries before trusting a vendor's feature-availability page — including this one, which is a snapshot from a specific week, not a permanent spec.

Part 2 of the Search for Agents series.
← Part 1: Search for agents is becoming its own market

Open Weights Catch the Last Frontier, Not the Moving One

Amit — Sun, 06 Sep 2026 03:38:42 +0000

Open-weight models are not a fixed number of months behind proprietary models. They move on several clocks at once.

Across 19 dated model snapshots from May 25 through September 6, 2026, I found open-weight leaders reaching an earlier proprietary benchmark frontier in 24 to 58 days on coding, intelligence, and agentic scores. But they did not erase the live gap. Proprietary leaders advanced during the same window.

That distinction changes the answer. Open weights are catching the last frontier quickly. Catching the moving frontier remains a different problem.

TL;DR

In a same-methodology comparison, open-weight leaders reached within 1% of an earlier proprietary frontier in 28 days for coding and 58 days for aggregate intelligence; an open agentic leader exceeded a 24-day-old proprietary score.
The live proprietary frontier still finished 2.7% to 5.4% ahead of the open leader on those same dimensions.
External research points in the same direction: the aggregate lag has compressed from roughly a year in older benchmark history to about four months in early 2026, but no single lag applies across coding, agents, long context, or multimodal work.
Benchmark catch-up is not product catch-up. Serving, tools, recovery loops, safety controls, and operations remain part of the system.

The question needs two clocks

Most catch-up claims compare a new open model with an older proprietary model. That is a valid diffusion measure: how long did it take an open release to reproduce a capability that was previously closed?

It is not the same as asking whether the best open model now matches the best proprietary model.

I used two clocks:

Prior-frontier catch-up: the first date an explicitly classified open-weight leader reached at least 99% of an earlier proprietary leader's score.
Live-frontier distance: the open leader's score relative to the proprietary leader available at the end of the comparison window.

I applied those clocks only inside methodology-compatible snapshots. The model dataset changed from methodology v4.1 to v4.2 in September, so I did not connect raw scores across that boundary. Open-weight status comes from a canonical, source-linked registry rather than a hosting-provider label. The analysis also fails if any top-25 model in a measured dimension lacks a verified classification.

The clean comparable window runs from June 21 through August 18.

The model names and scores below come from the dated snapshots behind the site's language model analysis.

Dimension	Earlier proprietary frontier	Open-weight catch-up	Time	Open score versus live frontier
Intelligence	Claude Fable 5: 59.9 on Jun 21	Kimi K3: 59.7 on Aug 18	58 days	94.6%
Coding	Claude Fable 5: 76.5 on Jun 21	Kimi K3: 76.2 on Jul 19	28 days	97.3%
Agentic	Claude Opus 5: 55.3 on Jul 25	Qwen3.8 2.4T A95B: 57.1 on Aug 18	24 days	96.5%

The gray baseline is the earlier proprietary score. Green is the open-weight leader by August 18. Orange is the live proprietary leader at the end of the same v4.1 window.

Coding closed fastest. Kimi K3 reached 99.6% of the June coding frontier in four weeks. Agentic performance moved faster still: Qwen3.8 exceeded a 24-day-old proprietary score, although the live proprietary leader had already moved another 3.7% higher. Aggregate intelligence took almost two months and retained the widest live gap.

This is the moving-frontier effect in data. A model can catch up and remain behind at the same time.

The September snapshot does not show universal parity

The September 6 snapshot uses methodology v4.2, so its raw scores should not be compared with the earlier series. It can still show the open-versus-proprietary distance within that single snapshot.

Dimension	Open-weight leader	Proprietary leader	Open as share of proprietary
Intelligence	50.2	56.8	88.4%
Coding	76.2	81.6	93.4%
Agentic	53.6	58.2	92.1%

Math is absent from this table for a reason. The current source contains no usable math-index observations. Older rows would create the appearance of a current ranking from stale data, so the honest result is unavailable, not zero and not parity.

The same caution applies to hosted speed. The fastest explicitly classified open endpoint in the snapshot produced roughly one-fifth the tokens per second of the fastest proprietary endpoint. That measures a provider's serving stack, hardware allocation, batching, and load as much as it measures a model. It is an operational result, not an inherent property of downloadable weights.

The economic frontier tells a different story. Nine of the 14 intelligence-price Pareto points in the September snapshot are verified open-weight models; five are proprietary. Open weights can become rational deployment choices before they become the highest-scoring models. That is why capability ranking and economic ranking are separate questions.

The longer record says the gap is compressing

The broader research record supports a shrinking lag, but not one universal number.

Epoch AI's historical open-model study examined benchmark catch-up through September 2024. Individual observations ranged from 5 to 22 months, with a mean near 13 months. Its combined benchmark-and-training-compute estimate placed open models about 14 months behind.

A newer Epoch Capabilities Index analysis estimated an average open-versus-closed lag of about four months from January through May 2026. Requiring the open model to strictly exceed the earlier closed model's point estimate extended the estimate to six months.

Those results do not conflict with the 24–58 day windows in my snapshots. They answer different questions:

Epoch measures an aggregate frontier across a longer history and multiple capability tests.
My shorter result tracks the fastest explicitly classified open leader in each dimension during one active release window.
A 99% threshold detects practical score proximity earlier than strict exceedance.

The historical direction is still clear. The diffusion window has compressed from roughly a year to months, and sometimes to weeks on a narrow benchmark. The remaining distance is jagged rather than uniform.

Stanford's 2026 AI Index illustrates that movement through human-preference scores. It reports the open-versus-closed Arena gap narrowing from 15.2% in May 2023 to 0.5% in August 2024, then reopening to 3.4% by March 2026. Catch-up did not end the race. A later proprietary release widened the gap again.

Each capability moves on a different clock

Coding is the fastest visible catch-up

Coding has structured tasks, executable outputs, and strong feedback loops. That makes it easier to generate training signals and verify improvement. It also makes benchmark proximity more credible than in subjective tasks.

But a coding score still does not establish application reliability. One 2026 study comparing benchmark rank with an end-to-end application task found that SWE-bench position did not predict which model produced the best working application in its experiment. Repository navigation, environment setup, tool use, and error recovery can reorder the models.

Agentic scores are close; agent systems are not interchangeable

Agent benchmarks depend on the harness around the model: tool descriptions, prompt templates, parsers, turn limits, state handling, and retry logic. Artificial Analysis gives agentic evaluations a large share of its intelligence methodology, but that still measures a configured evaluation system rather than a bare checkpoint.

The deployment requirements make the distinction concrete. The Qwen3.8 model card specifies serving engines, templates, and tool parsers. The Mistral Large 3 model card describes a reference configuration built around eight H100 or B200 GPUs. By contrast, the GPT-OSS-120B card targets a single 80 GB GPU.

Weight access gives control. It does not make every checkpoint equally simple to operate.

Long context and multimodality do not have a stable lag yet

Advertised context length is an input limit, not a measure of reliable reasoning across that input. Long-context tests vary by document structure, retrieval pattern, distractors, answer location, and output demands. I found no credible public estimate that converts those differences into one open-versus-proprietary catch-up duration.

Multimodal results are similarly benchmark-specific. The Stanford AI Index shows open models close on some image and video evaluations while retaining wider gaps on others. Combining those into a single time lag would imply a precision the evidence does not support.

Efficiency can arrive before capability parity

Open weights change the economics even when the benchmark leader remains proprietary. Builders can quantize, fine-tune, place inference near data, choose the serving stack, and trade throughput against quality.

Epoch's historical analysis found examples of open models matching older closed-model benchmark performance with materially less training compute. A separate analysis of inference price-performance trends found rapid annual improvement on open-weight Pareto frontiers. That advantage does not make self-hosting free: accelerators, engineering, capacity management, observability, and safety still belong in the total cost.

Catch-up is a vector, not a date

The useful model has three clocks:

Clock	What catches up	What it misses
Benchmark diffusion	A checkpoint reproduces an older score	The frontier may have moved
System diffusion	Tools, serving, monitoring, and recovery become dependable	Product quality is hard to reduce to one index
Economic diffusion	The workload becomes cheaper or controllable enough to deploy	Lower cost does not guarantee frontier capability

This explains why people can look at the same market and reach opposite conclusions. One sees near-parity coding scores. Another sees a proprietary agent product that works with less assembly. A third sees an open model that is cheaper, customizable, and sufficient for the workload. All three observations can be true.

The fair comparison is checkpoint against checkpoint or complete system against complete system. Comparing an open checkpoint with a finished proprietary agent product credits one side for its platform while charging the other for components that have not been assembled.

What the data still cannot answer

The snapshot record is useful but incomplete.

The dataset contains 19 usable language snapshots over a little more than three months. That is enough to observe a release cycle, not enough to establish a permanent trend.
The September registry classifies 408 of 643 catalog rows. The unclassified tail remains outside open-versus-proprietary calculations, while every top-25 model used by this analysis has verified status and a public evidence source.
The September methodology change breaks raw-score continuity with the summer series.
The current source has no usable math-index observations.
The dataset does not measure production reliability, safety operations, data residency, customization effort, or the engineering cost of self-hosting.

The conclusion has to remain inside those boundaries.

So what

Do not wait for a declaration that open weights have universally caught up. It will never arrive, because capability does not move as one unit.

Evaluate the dimension your workload consumes. Coding may be within weeks of a prior frontier. Agentic benchmark scores may be close while system reliability remains far apart. Economic value may already favor open deployment even when the highest composite score remains proprietary.

The operating question is not, "Are open models at the frontier?" It is, "Has the open stack crossed the capability, reliability, and cost thresholds for this workload?"

The open thread is whether the live capability gap now trends toward zero, or whether proprietary labs keep reopening it by turning checkpoints into more complete systems faster than the open ecosystem can assemble them.

The Gateway Controls the Request. The Router Chooses the Model.

Amit — Tue, 01 Sep 2026 13:41:26 +0000

TL;DR

Model choice is moving from application configuration into the request path. The model that answers can now depend on task difficulty, price, latency, capacity, policy, geography, and provider health.
A gateway and a router are not the same component. The gateway controls access and enforces policy. The router decides which model or model tier should handle the request.
Products blur the distinction because many AI gateways bundle proxying, governance, routing, retries, caching, and observability behind one endpoint.
The most detailed first-party router disclosures come from coding assistants. Independent production evaluations remain scarce, while vendor-published gateway deployments are easier to find.
The core value is not “always pick the best model.” It is “use the least expensive path that still satisfies this request.”

The gateway controls the request. The router chooses the model.

That distinction explains both the growth of model routers and the confusion around them.

Model selection used to happen when an application was designed. A team picked one provider, placed one model ID in configuration, and sent every request to it. That works while one model is the obvious default and each user action produces one model call.

Neither condition holds anymore.

Model catalogs now contain hundreds of general, reasoning, multimodal, open-weight, and specialized choices. Agent systems turn one user request into planning, classification, retrieval, tool selection, execution, verification, and synthesis calls. Provider capacity, latency, prices, and model availability keep changing underneath them.

The thesis: model choice is becoming a runtime decision.

The router is the mechanism that makes that decision. The gateway is the control boundary around it.

Five Components Are Hiding Behind One Endpoint

The market uses “AI gateway,” “model router,” “proxy,” and “load balancer” as if they were interchangeable. They are not.

Component	The decision it makes	Primary responsibility
API proxy	How does this request reach the upstream API?	Protocol translation and request forwarding
AI gateway	May this request pass, and under what controls?	Authentication, quotas, policy, logging, guardrails, budgets
Model router	Which model should answer this request?	Selection by task, quality, cost, latency, policy, or availability
Load balancer	Which eligible serving endpoint or replica of the selected model should execute it?	Health, queue, cache, and deployment selection
Inference platform	Where and how does the model run?	Model loading, accelerator allocation, batching, and token execution

The clean request path looks like this:

flowchart LR
    A[Application or agent] --> G[AI gateway]
    G --> P[API proxy or protocol adapter]
    P --> R[Model router]
    R --> L[Endpoint or replica selection]
    L --> I[Inference platform]

    G -.-> GP[Identity, quotas, policy, logs]
    R -.-> RP[Quality, cost, latency, capability]
    L -.-> LP[Health, load, region, cache state]
    I -.-> IP[Models, accelerators, batching]

The boundaries are architectural. Products are bundles.

LiteLLM combines an OpenAI-compatible proxy with budgets, rate limits, retries, fallbacks, and load balancing. Kong AI Gateway adds AI-specific traffic and governance functions to an API gateway, while its model-based routing pattern analyzes prompt complexity before choosing a provider. Envoy AI Gateway can connect to an Endpoint Picker that uses live serving metrics such as key-value cache state to choose an upstream target.

Those products can perform routing, but that does not make every gateway function a routing function.

Authentication and logging are gateway work. Caching is often implemented at the gateway or serving layer. Choosing a cheaper model for a simple request is router work. Choosing one healthy replica of that model is load-balancer work.

A single endpoint can hide all five responsibilities.

Why Routing Is Growing Now

The first driver is not model count by itself. It is model divergence.

Models differ in reasoning depth, context window, tool use, modality, latency, price, safety behavior, regional availability, and deployment options. A leaderboard can order them on one score. A production request arrives with several constraints at once.

The second driver is economic. The RouteLLM research studied routing between stronger, expensive models and weaker, cheaper ones. On MT-Bench, one configuration retained 95% of GPT-4 quality with an estimated 3.66× cost saving. The result does not transfer automatically to every workload, but it proves the mechanism: many requests do not need the most expensive eligible model.

This is the runtime extension of the right model for the right job. That earlier pattern assigns model tiers to known pipeline steps. A router makes the assignment while traffic is moving. The Pareto frontier creates the rational candidate list; the router turns that list into policy.

The third driver is agents.

Anthropic’s agent architecture guidance describes workflows built from routing, parallelization, orchestrator-worker patterns, and evaluator loops. Each pattern creates model calls with different requirements. The classifier does not need the same model as the final reviewer. A tool-selection step does not need the same reasoning budget as an ambiguous architecture decision.

Routing one chatbot turn saves once. Routing an agent loop can save at every stage.

The fourth driver is infrastructure volatility. A request may need a different route because a provider is throttled, a region is congested, a model is unavailable, or data must remain inside an approved geography. Cloudflare AI Gateway exposes conditional model selection, quotas, retries, and fallbacks as a versioned route. Amazon Bedrock Intelligent Prompt Routing predicts response quality within a model family and routes through one serverless endpoint. Microsoft Foundry Model Router selects among underlying models while applying the deployment’s regional and policy constraints.

“Pick the smartest model” is not enough. The runtime question is:

Which eligible model path can satisfy this request at the required quality, cost, latency, and policy boundary?

How Routers Are Actually Being Used

The most detailed first-party implementation disclosures come from coding assistants.

Cursor Router uses the current turn, recent conversation state, task category, tool calls, and production performance data to choose a model. It is learned complexity- and task-based model routing rather than only a static fallback list.

GitHub Copilot Auto routes based on request complexity, real-time model availability, user plan, and administrator policy. The selected model remains visible, and the available pool changes over time.

These products have the right workload shape for routing. Coding sessions contain quick questions, repository searches, edits, debugging, long-context reviews, and autonomous tool loops. Sending every step to one model leaves either quality or money on the table.

Outside coding tools, vendor-published deployment examples skew toward gateway-centered routing:

Deployment	What the control layer does	Router or gateway value?
SiteGPT on Portkey	Switches among 13+ production models and handles rate limits; Portkey reports that SiteGPT processed six billion tokens	Both: model flexibility plus gateway reliability
Fontys ICT	Enforces access, budgets, and processing-location rules across commercial, EU-hosted, and self-hosted models	Primarily gateway and policy routing
RightBlogger on Cloudflare	Caches about 10% of model requests, cuts reported OpenAI cost by 10%, and provides request logs	Gateway value, not semantic model selection
Cloudflare dynamic routes	Chooses models using conditions, quotas, retries, and fallbacks without application-code changes	Rules-based routing inside a gateway

This split matters.

A product can create substantial value without predicting the best model for every prompt. Centralized logging, quotas, caching, provider failover, and policy enforcement solve production problems before a learned router enters the path.

The public evidence for standalone semantic routers used by named enterprise customers is thinner. There are many router papers, repositories, and vendor claims. There are fewer independent accounts showing a router’s decisions against live traffic, failures, tool calls, and business outcomes.

There is also a split inside the router category. Managed general-purpose routers learn broad task patterns across a predefined model pool. Product-specific routers can learn from one application’s traffic and evaluation signals. Cursor describes training against product traffic, while Amazon Bedrock states that its router cannot adapt from application-specific performance data. The feedback loop may become more defensible than the initial selection algorithm.

The Core Value Is Policy, Not Magic

The weak router pitch is “we always select the best model.”

There is no best model independent of the request, candidate pool, price snapshot, latency target, provider state, and evaluation method. A router cannot choose a model it was not configured to consider. It cannot optimize an outcome it does not measure.

The stronger value proposition is:

Move model selection out of application code and into a measured policy layer.

That creates value across the control layer:

Value	Primary owner
Spend frontier-model money only where it changes the outcome	Router
Match vision, long-context, reasoning, coding, or tool-heavy work to eligible models	Router
Retry or fail over when a provider, deployment, or region cannot serve the request	Gateway and load balancer
Restrict traffic by tenant, geography, sensitivity, budget, or approved provider	Gateway and policy engine
Change the model pool and selection policy without rewriting every application	Gateway contract plus router

The final point needs care. A stable gateway API reduces application coupling, but switching models is not free. Tool schemas, prompts, safety behavior, token accounting, and session state can differ. A router can reduce provider lock-in while creating router-specific configuration and operational dependencies.

Benchmarks Are Catching Up to the Products

Router evaluation is becoming a field of its own.

RouterBench assembled more than 405,000 stored inference outcomes. That makes routing policies inexpensive to replay, but it cannot reproduce live provider latency, outages, throttling, or model updates.

RouterArena uses 8,400 queries across nine domains and 44 categories. It evaluates answer accuracy, cost, routing optimality, robustness, and routing latency. Its central finding is more useful than any single leaderboard position: no router leads across every metric.

The vLLM “When to Reason” study shows what a bounded routing claim looks like. On MMLU-Pro, selectively enabling reasoning improved accuracy by 10.2 percentage points while cutting latency by 47.1% and token use by 48.5%. That is evidence for deciding when reasoning is useful on that benchmark. It is not evidence that one router will select the best coding model, preserve a tool loop, or recover from a provider outage.

A router needs to beat more than “send everything to the premium model.”

The useful baseline set is:

Baseline	What it proves
Best fixed model	The quality ceiling for the candidate pool
Cheapest fixed model	The cost floor
Random routing	Whether selection adds intelligence
Deterministic rules	Whether a learned router beats simple categories or thresholds
Learned router	The proposed policy
Oracle router	The theoretical ceiling after seeing every model’s result

Then measure quality, cost per successful task, end-to-end latency, failure recovery, policy violations, and decision trace completeness.

One blended score can hide the result that matters. A router may rank higher because it is cheaper while producing worse answers. Another may improve quality but add too much latency to sit in an interactive request path. The complete cost-quality-latency frontier is the product.

The selector itself also has a cost. Kong’s model-based routing example invokes a model to classify prompt complexity before selecting the downstream provider. That extra call adds tokens, latency, and another failure point. Router evaluation needs to include the selector’s cost and failure behavior, not only the savings after selection.

What Is Still Missing

The router market has more implementations than production evidence.

Single-turn benchmarks do not capture active tool loops, provider-specific state, prompt caching, or conversation continuity. A router can make the correct task-level choice and still break the application by switching models halfway through a workflow.

Resilience claims also need failure injection. A fallback feature is not the same as a measured recovery path. The evidence should show recovery time, duplicate requests, lost tool results, extra cost, and whether the final answer still satisfies the task.

Routing transparency remains uneven. Some products expose the selected model and reason. Others return one virtual model name while hiding the path. That abstraction is convenient until a quality regression, cost spike, safety refusal, or provider change needs an explanation.

Session-aware routing for agent and tool workflows needs continuity state or affinity, not classification alone. It must know when a session can move, when it is pinned to a provider, and which state cannot travel safely.

So What

The model router is not replacing the AI gateway. It is becoming the decision engine inside or behind it.

The gateway owns the boundary: identity, policy, quotas, logs, and the stable application contract. The router owns the choice: which eligible model path should answer this request. The load balancer owns the final placement. The inference platform owns execution.

That separation turns a crowded product landscape into a clearer architecture.

The market is growing because the decision moved. Model selection is no longer a configuration line written once. It is a policy evaluated continuously against changing requests, models, prices, capacity, and constraints.

The open thread is whether independent model routers become a durable product category. Gateways, coding platforms, cloud providers, and inference engines are all absorbing routing functions. The routing algorithm may matter enormously while the standalone router disappears into the control plane.

The Agentic DevSecOps Stack Is Taking Shape

Amit — Sun, 30 Aug 2026 19:06:14 +0000

TL;DR

Agentic DevSecOps is not converging on one autonomous engineer. It is forming a chain of specialized agents across code, security, release, production operations, and agent protection.
A product’s native advantage follows where its evidence already lives: repositories, telemetry, delivery pipelines, security findings, or the cloud control plane.
“Agent” hides three different action boundaries: copilots suggest, investigators conclude, and executors change systems. The production blast radius determines how much autonomy a product can safely expose.
Product launches are moving faster than independent evaluation. Public benchmarks can test the underlying work, but they do not yet establish which commercial agent performs best.
MCP and A2A connect agents. They do not solve evidence portability, identity propagation, approval, or chain of custody.

The future of DevSecOps is not one autonomous engineer. It is a governed chain of agents that investigate, act, challenge, and verify one another.

The pieces are already visible. Coding agents create branches and pull requests. Security agents review designs, inspect code, and attack running applications. Release agents evaluate changes and stop bad deployments. SRE agents investigate production failures. A newer class of security product watches the agents, tools, and protocols themselves.

What does not exist yet is a settled architecture connecting all of this work. The market has agents at nearly every stage of software delivery, but no shared contract for passing evidence, authority, and accountability from one stage to the next.

That missing contract matters more than another model.

Six Systems of Record Are Creating Six Agent Classes

The clearest way to understand this market is not by vendor category. It is by the system where each agent begins its work.

Representative products as of August 2026:

Starting point	Agent class	Representative products	Native advantage
Repository and CI/CD	Coding agents	GitHub Copilot coding agent, GitLab Duo Agent Platform	Branches, tests, commits, pull requests
Telemetry and incidents	SRE agents	AWS DevOps Agent, Datadog Bits, Dynatrace Intelligence, Azure SRE Agent, PagerDuty SRE Agent	Logs, traces, topology, incidents, operational history
Delivery pipeline	Release agents	AWS DevOps Agent release management, Harness Continuous Verification, LaunchDarkly Guardian	Change analysis, progressive exposure, deployment verification, rollback
Application-security evidence	AppSec agents	AWS Security Agent, XBOW, Wiz Code, Snyk, GitHub Copilot Autofix	Findings, reachability, exploit evidence, remediation
Agent runtime and tool layer	AI-security agents	Prisma AIRS, Orca AI-SPM	Agent discovery, posture, runtime controls, MCP and tool visibility
Cloud and security control plane	Cloud and SOC agents	GuardDuty investigations, Microsoft Security Copilot agents, Google Security Operations, CrowdStrike Charlotte AI	Identity, configuration, infrastructure, threat intelligence

The broader source set also includes New Relic Autopilot, Splunk AI SRE, Harness AI SRE, ServiceNow Problem Investigation Agent, and Deductive AI in operations; Pentera, GitLab Security Analyst Agent, Endor Labs AI Security Review, Semgrep Multimodal, Checkmarx One, and Veracode Fix in application security; and AWS Security Hub and Amazon Inspector in the cloud security control plane.

This explains why the current product map remains fragmented. Each vendor starts with a different evidence advantage.

Repository platforms know the change. Observability platforms know the production history. Delivery platforms know the rollout. Security platforms know the vulnerability and attack path. Cloud platforms know the identity and infrastructure state.

An agent can connect to all of those systems. That does not mean it understands each one with equal depth.

“Agent” Describes Three Different Action Boundaries

The product name tells you less than the permission boundary.

Class	What it does	Typical boundary
Copilot	Responds to a request and proposes an action	A human drives every meaningful step
Investigator	Collects evidence, tests hypotheses, and reaches a conclusion	A human approves the response
Executor	Changes code, attacks a target, runs a release, or modifies infrastructure	A branch, sandbox, target scope, policy, or approval gate limits the action

Coding agents can work on disposable branches. Security-testing agents can attack explicitly authorized targets. Release systems can stop or reverse a bounded rollout. Those environments give the agent a defined place to act and a recovery path when it is wrong.

Production operations are harder. A mistaken code patch can be rejected in review. A mistaken infrastructure action can make the incident worse. That is why many SRE products investigate and recommend broadly while constraining execution to approved runbooks or human-reviewed changes.

Autonomy does not increase evenly across the lifecycle. It expands where isolation and rollback are strongest.

The Architecture Is a Verification Chain, Not a Super-Agent

The useful end state looks less like one general agent and more like a separation-of-duties system.

Coding agent
    │ creates a change
    ▼
Security agent
    │ reviews code and tests exploitability
    ▼
Release agent
    │ evaluates risk and validates deployment
    ▼
Operations agent
    │ observes production and investigates failures
    ▼
Remediation agent
    │ proposes or implements the fix
    ▼
Independent revalidation

The agent creating a change should not be the only agent approving it. The agent reporting a successful remediation should not be the only system deciding whether the vulnerability or incident is gone.

That principle already appears in individual tools. Coding agents produce pull requests rather than silently replacing the main branch. Security products return findings with locations and remediation evidence. Release systems use guardrail metrics before increasing exposure. Operations agents assemble timelines and hypotheses before a production action.

The architectural pattern is stronger than any individual implementation: action, evidence, challenge, approval, and revalidation.

My earlier code-security experiment showed why this matters. An AI security review found a missing authorization check that pattern-based scanners missed. The result was useful because it included the vulnerable location, classification, and proposed fix. It still needed an independent decision about reachability and whether the remediation actually closed the path.

The same rule holds in operations. A trace can reveal a multi-agent failure that no individual agent log contains, but the trace must preserve one correlation identity across every hop. Without that shared identity, the lifecycle becomes a collection of locally plausible stories.

Vendors Remain Strongest Where Their Data Already Lives

AWS illustrates a broad single-provider approach by pairing an operational agent with an application-assurance agent.

That breadth does not establish one shared lifecycle. The public documentation reviewed in August 2026 did not establish shared memory, a common application graph, unified approvals, or automatic evidence handoffs between the two services.

The same distinction applies elsewhere:

GitHub and GitLab own the repository workflow, so their agents can move naturally from findings to branches and pull requests.
Datadog, Dynatrace, New Relic, Splunk, and PagerDuty own operational evidence accumulated over time.
Harness and LaunchDarkly control bounded release actions where a system can pause exposure or roll back.
Wiz, Snyk, Endor Labs, Semgrep, Checkmarx, and Veracode begin with security findings and remediation workflows.
ServiceNow begins with enterprise workflow, approvals, service ownership, and configuration records.
Prisma AIRS and Orca extend the security boundary to the agents and MCP-connected tools themselves.

No integration list settles this comparison. Connecting an agent to a data source proves access. It does not prove evidence depth, correct interpretation, or safe action.

AWS also illustrates why overlapping products do not necessarily perform the same job. CloudWatch investigations begins with telemetry, GuardDuty investigations begins with threat findings, Inspector begins with continuous scanning, and Security Agent begins with an application to review or test. These surfaces can encounter the same underlying incident while entering through different evidence.

The durable question is not which single surface replaces the others. It is whether findings can move between coding, security, release, and operations systems without losing identity, chronology, confidence, or remediation history.

Enterprise Readiness Is a Separate Capability Axis

Feature breadth does not determine usable autonomy. Data boundaries, identity, network access, permissions, audit evidence, scale limits, recovery, and cost controls determine where an agent can safely operate.

These questions apply to every product in the landscape:

Control	Question
Data boundary	Where are prompts, code, telemetry, and findings stored and processed?
Identity	Which principal acts, and does that identity survive delegation?
Network	Can the service reach private tools and targets without public exposure?
Permission	Can read, recommend, pull-request, sandbox-execute, and production-write access be separated?
Audit	Does the product preserve control-plane events, reasoning, tool actions, and test evidence?
Scale	What happens when concurrency, duration, or rate limits are reached?
Economics	Can a task be bounded by time, work units, or a hard cost ceiling?
Recovery	Can an operator cancel, retry, roll back, and independently revalidate the action?

These controls are not procurement details added after the technical decision. They define the usable autonomy of the product.

Product Capability Is Ahead of Independent Proof

Vendor pages describe features. They do not establish root-cause accuracy, vulnerability recall, false-positive rate, remediation correctness, or predictable cost.

Research benchmarks are beginning to make the underlying work measurable:

SREGym evaluates diagnosis and mitigation across live cloud-native reliability problems.
ITBench evaluates agents on real IT-automation environments spanning reliability, security, compliance, and cost work.
AIOpsLab covers detection, localization, root-cause analysis, and mitigation in microservice environments.
AutoPenBench evaluates autonomous and human-assisted penetration testing against vulnerable systems.
MCPSecBench tests attacks across MCP users, clients, transport, and servers.
ToolEmu tests agents using high-stakes tools in an emulated environment.

These benchmarks do not rank the commercial products in the market map. They expose the tasks those products eventually need to survive under repeatable conditions.

That is a meaningful difference. A product demonstration proves possibility. A benchmark establishes a repeatable test. A controlled comparison establishes relative performance. The source set behind this landscape contains many product demonstrations, a growing benchmark set, and almost no independent head-to-head commercial comparisons.

The useful comparison is not “which agent has more features?” It is the same controlled work across systems:

Give each SRE agent the same incident, telemetry, deployment history, and code.
Give each security agent the same vulnerable application and authorization boundary.
Measure evidence completeness, not only whether the final answer sounds plausible.
Re-run the proposed remediation with independent tests.
Record task duration, tool calls, human interventions, and actual cost.

That experiment would expose the difference between access and understanding. It would also reveal whether a product fails safely when telemetry is incomplete, instructions are malicious, or permissions are deliberately constrained.

The Agents Become Part of the Attack Surface

Agentic DevSecOps creates a second security problem: the systems protecting software can themselves be manipulated through the evidence they consume.

An operations agent reads logs, traces, resource tags, tickets, runbooks, and chat history. A coding agent reads repository instructions and pull-request comments. A security agent receives URLs, credentials, source code, and target configuration. An MCP-connected agent reads tool descriptions and responses supplied by another system.

Each input can contain instructions that were never meant to be trusted.

AWS DevOps Agent security guidance treats prompt injection in operational data as a risk. Independent work such as MCPSecBench broadens that threat model across MCP users, clients, transports, and servers.

The specialist market is forming around this layer too. Prisma AIRS extends security visibility to enterprise agents, MCP servers, plugins, and tool interactions. Orca AI-SPM approaches the problem from cloud posture and exposes security context through MCP-compatible workflows.

The threat model now includes:

Prompt injection hidden inside logs, tickets, code, or tool metadata.
A compromised remote agent returning malicious instructions as evidence.
A read-only investigation silently becoming a write-capable remediation.
Credentials escaping through a target URL, tool call, or generated report.
An agent using a valid permission for the wrong purpose.
Approval fatigue turning a human gate into a rubber stamp.
A successful action with no trustworthy record of who authorized it.

This changes the role of governance. A policy layer cannot sit outside the agent loop and inspect only the final result. It needs to control tool discovery, identity, network reach, permission escalation, action approval, and evidence retention while the work is happening.

What’s Missing Is a Portable Trust Layer

MCP gives agents a common way to access tools and context. A2A gives independently implemented agents a way to communicate and exchange tasks.

Neither protocol answers the full DevSecOps handoff problem:

Which identity authorized the action?
What evidence supported the conclusion?
Which source produced the finding?
What changed after remediation?
Did an independent system verify the result?
Can another vendor consume the evidence without flattening it into prose?

Existing standards cover pieces of that contract:

Standard	What it can carry
OpenTelemetry GenAI semantic conventions	Agent, model, retrieval, and tool-execution traces
SARIF	Static-analysis findings, code locations, flows, fixes, and tool metadata
OCSF	Normalized security events and findings
CycloneDX	Components, services, dependencies, and vulnerability context
CycloneDX VEX	Exploitability decisions and their justification
in-toto attestations	Signed provenance for actions, actors, and produced artifacts

A future evidence path could look like this:

OpenTelemetry execution trace
        ↓
SARIF or OCSF finding
        ↓
CycloneDX asset identity
        ↓
VEX exploitability decision
        ↓
in-toto signed attestation

That composition is possible today. It is not yet a standard lifecycle contract, and current product documentation does not show a complete implementation across coding, security, release, and operations agents.

This is the gap that determines whether the market becomes interoperable or collapses into closed suites.

So What

The model is no longer the whole system. The delivery architecture around the model decides what the agent can see, what it can change, and what counts as proof.

Five rules follow from the current landscape:

Bound every action. Branches, sandboxes, target scopes, approved runbooks, and staged rollouts turn autonomy into a controllable mechanism.
Preserve identity across handoffs. Every agent action needs a principal, correlation identifier, and authorization record.
Pass evidence, not narrative conclusions. Findings need locations, traces, exploit details, test results, and machine-readable provenance.
Separate creation from approval and revalidation. The agent that makes the change cannot be the only system declaring success.
Put time, concurrency, and cost limits around autonomous work. An agent loop is also a production workload.

Agentic DevSecOps is taking shape as a distributed control system for software delivery. Coding, security, release, and operations agents are becoming real product categories. The architecture connecting them remains unsettled.

The open thread is whether portable evidence allows specialized agents to remain independent—or whether the absence of that trust layer forces every organization into one vendor’s lifecycle suite.

Exploring the Voice AI Stack

Amit — Sun, 30 Aug 2026 19:05:38 +0000

The voice AI landscape becomes easier to understand when you map it as a stack.

I reached that conclusion after building one working voice-agent stack, then exploring the alternatives. LiveKit, Deepgram, ElevenLabs, and Vapi often appear in the same landscape, but each controls a different part of the system. One provides real-time media and an agent framework. Another began with speech recognition. Another became known for generated voices. Another packages orchestration, telephony, models, and operations.

The practical question is: Which layers do I want to own?

Why Voice AI Is Gaining Traction

Voice already has distribution. It runs through every telephone, browser, mobile device, car, and contact center. The new opportunity comes from changing what happens after someone starts speaking.

Customer service is an early market for voice AI because many customers still choose the phone when they need help. A 2025 Dynata survey of 1,000 US consumers commissioned by PolyAI found that 65% preferred a phone call as their primary way to contact retail and travel brands. In the same survey, 71% said they would speak with an intelligent voice assistant if it could accurately complete the task.

That last condition matters. A 2026 Gartner survey of 3,566 customers found that 87% expect companies using generative AI for customer service to provide access to a human agent. Customers want faster resolution while retaining a human escape hatch.

Three changes are expanding what voice systems can do:

The conversation is less scripted. Native audio models such as Amazon Nova 2 Sonic, OpenAI Realtime, and Gemini Live combine live audio, reasoning, interruptions, and tool use inside a persistent session.
The infrastructure is easier to assemble. LiveKit Agents and Pipecat provide programmable frameworks for media, models, and tools. Vapi, Retell, and the newer agent platforms from speech providers package more of that work into managed services.
Service organizations are increasing technology investment. Gartner predicts that more than half of customer-service organizations will double technology spending by 2028. Its October 2025 survey of 321 service leaders found that only 20% had reduced agent headcount because of AI. Investment is rising, but full labor replacement is not the current baseline.

The broader AI adoption curve adds momentum. McKinsey's 2025 global survey of 1,993 participants found that 88% reported regular AI use in at least one business function. Twenty-three percent reported scaling an agentic AI system, while another 39% were experimenting.

The economics still need careful measurement. Voice agents can answer concurrently, operate outside business hours, and absorb call spikes without matching staffing growth. That does not guarantee lower cost per completed task. Gartner predicts that generative AI cost per customer-service resolution could exceed $3 by 2030, higher than some offshore human-agent resolutions. Tool failures, retries, supervision, and human escalation belong in the calculation.

How Large Could the Market Become?

There is no single number for the voice AI market because researchers define the category differently.

Market definition	Starting estimate	Forecast	CAGR
AI voice agents	$2.5B in 2025	$35.2B in 2033	39.0%
AI voice agents, alternate estimate	$2.4B in 2024	$47.5B in 2034	34.8%
Conversational AI	Broader than voice	$41.4B in 2030	23.7% from 2025
Voice and speech recognition	$20.2B in 2023	$53.7B in 2030	14.6%
AI voice generators	$3.6B in 2023	$21.8B in 2030	29.5%

These figures overlap and should not be added together. Voice agents include orchestration and task completion. Conversational AI includes text assistants. Voice and speech recognition includes transcription, biometrics, automotive, and other uses. Voice generation includes synthesis, cloning, media, and agent speech.

The useful range is therefore directional. Two current estimates place the narrow voice-agent category near $2.4B to $2.5B in 2024-2025 and between $35B and $48B by 2033-2034. Adjacent speech and conversational markets are already larger, but they measure different revenue pools.

The 35% to 39% forecast growth rates explain the attention around the category. They remain analyst forecasts, not observed future revenue. The strongest evidence of traction today is the combination of an established voice channel, expanding enterprise AI use, and a stack that now supports open-ended conversation and tool execution.

The Stack Hidden Behind the Demo

A production voice agent is easier to understand when the animated waveform disappears.

Channel
Phone, browser, mobile app, contact center
        |
Real-time transport
WebRTC, WebSocket, SIP, RTP, PSTN
        |
Turn detection
Is the user pausing, or finished?
        |
Speech understanding
Streaming transcription or native audio
        |
Reasoning and action
Model, tools, retrieval, memory, workflows
        |
Speech generation
Streaming synthesis or native audio
        |
Operations
Hosting, tests, traces, analytics, governance

Products enter this stack from different starting points:

Starting point	What it primarily controls	Examples
Media infrastructure	Real-time audio, rooms, WebRTC, SIP	LiveKit, Daily
Agent framework	The flow of audio, model events, tools, and responses	Pipecat, LiveKit Agents
Speech recognition	Streaming transcription, endpointing, turn detection	Deepgram, AssemblyAI
Speech generation	Streaming voices, voice design, cloning	ElevenLabs, Cartesia
Native audio model	Audio understanding, reasoning, and audio generation in one session	Amazon Nova 2 Sonic, OpenAI Realtime, Gemini Live
Managed voice-agent platform	Telephony, orchestration, models, tools, tests, and operations	Vapi, Retell

A flat vendor comparison hides these boundaries. Use the table to identify which products belong in the same purchasing decision.

Three Architectures, Three Control Models

The stack can be assembled in three broad ways.

Chained

Audio -> speech-to-text -> text model -> text-to-speech -> audio

A chained system exposes each stage. The builder can choose Deepgram or AssemblyAI for recognition, a text model for reasoning, and ElevenLabs, Cartesia, or another speech model for the voice.

That separation buys control. Each component can be measured and replaced. The transcript creates an explicit audit trail. Pronunciation, moderation, model choice, and exact spoken wording can be handled at separate layers.

The cost is coordination. Every boundary adds buffering, network travel, credentials, failure handling, and another place to diagnose. Tone and hesitation can also be flattened into text before the reasoning model receives them.

Native Speech-to-Speech

Audio -> native real-time audio model -> audio

Amazon Nova 2 Sonic, OpenAI Realtime, and Gemini Live collapse speech understanding and generation into a persistent model session. These APIs can still emit transcripts and call tools, but text is no longer the only representation passed between understanding and speech.

This can preserve timing, tone, pacing, and interruption behavior. It also moves more control into one provider-specific session protocol. Voice choice, stage-by-stage diagnosis, and model portability become functions of that provider's interface.

Hybrid

Audio -> native audio understanding and reasoning -> specialist voice -> audio

A hybrid keeps speech-native input but sends the response through a separate speech generator. LiveKit documents this as a distinct pipeline, alongside chained and native real-time architectures.

The pattern matters when conversational understanding and brand voice have different owners. A native model can handle the live interaction while a specialist speech model controls voice identity, pronunciation, or language coverage.

Each architecture creates a different control model.

Every Layer Is Expanding Vertically

The voice AI landscape looks unstable because the product boundaries are moving.

Deepgram now offers a Voice Agent API on top of recognition, turn detection, and speech generation. AssemblyAI now documents stored voice agents, voices, tools, turn detection, and interruption handling alongside transcription.

ElevenLabs has expanded into ElevenAgents, including workflows, tools, knowledge, telephony, testing, and analytics. Cartesia Line similarly extends beyond speech generation into orchestration and deployment.

Infrastructure companies are moving upward too. LiveKit Agents combines its media layer with agent orchestration. Pipecat Cloud adds managed deployment, scaling, secrets, logs, and session APIs to the open-source framework.

Managed platforms are moving downward. Vapi exposes the underlying transcriber, model, and voice as configurable parts. Retell supports managed orchestration while also allowing custom telephony and custom model integrations.

The pattern is vertical convergence: each provider starts at one layer, then expands into adjacent layers to own more of the working system.

The result is several competing bundles with different escape hatches.

The Real Decision Is the Ownership Boundary

There are three practical places to draw the line.

Ownership boundary	The builder owns	The provider owns	Main tradeoff
Assemble the stack	Pipeline behavior, providers, deployment, observability	Individual model or transport services	Maximum control, maximum integration work
Use a framework	Agent logic, tools, model choices	Streaming primitives and possibly hosting	Replaceable components inside a framework contract
Buy a managed platform	Business workflow, prompts, tools, integrations	Telephony, orchestration, deployment, tests, monitoring	Fast path to production, larger platform dependency

The right amount of ownership depends on the application. A browser assistant with custom media behavior has different requirements from an outbound telephone agent that must transfer calls, detect voicemail, replay failures, and support an operations team.

The boundary should follow the part of the system that creates differentiation.

If the value is a proprietary conversation engine, keep orchestration and model choice replaceable. If the value is a business workflow, buying the media and telephony layers can remove undifferentiated work. If voice identity is central to the product, keep the speech-generation layer independent even when the rest of the agent is managed.

Measuring Latency Across the Full System

Latency is often presented as one number. A conversation experiences a chain:

Network transport and buffering.
Detecting that the user finished speaking.
Producing a useful transcript or audio representation.
Generating the first useful response.
Running tools or retrieval.
Producing the first audible speech.
Delivering that audio back to the user.

A "75 ms" speech-generation result and a "sub-one-second" voice response can both be accurate while measuring different intervals. Neither describes the full call.

Turn detection is a good example. Deepgram documents endpointing separately from transcription, while AssemblyAI combines acoustic and semantic turn signals. An aggressive endpoint responds quickly but can cut off a caller who pauses before a number or name. A conservative endpoint captures the thought but feels slower.

My own Nova 2 Sonic and LiveKit experiment exposed a larger measurement trap. Retrieval took roughly half a second. The model then took 55 to 90 seconds to turn about 1,500 characters of dense retrieved material into a spoken response. Optimizing the vector lookup would have targeted less than 1% of the delay.

The useful metric is the distribution from user stops speaking to first useful audible response, measured on the real channel with real tools.

What to Compare Instead

I would evaluate a voice-agent architecture on eight questions:

Channel: Does it need a browser, mobile app, telephone network, contact center, or multi-party room?
Turn-taking: How does it distinguish a pause from a completed thought?
Interruption: Does playback stop immediately and recover cleanly when the user speaks?
Tool reliability: Can it select the right tool, produce valid arguments, recover from failure, and confirm before writes?
Auditability: Are transcripts, model events, tool traces, recordings, and replays available?
Portability: Which models, transports, phone numbers, prompts, and evaluation sets can move elsewhere?
Operations: Who owns deployment, scaling, regression tests, monitoring, and failure diagnosis?
Economics: What is the cost per completed task, including retries and human escalation, rather than the advertised cost per minute?

This changes the research agenda. The useful experiment holds the workflow constant while comparing competing ownership boundaries:

LiveKit Agents versus Pipecat with the models held constant.
Native speech-to-speech versus a chained pipeline with the task held constant.
Vapi or Retell versus a framework-based implementation with the telephone workflow held constant.
Specialist speech components versus each provider's integrated agent platform.

Without those controls, a vendor comparison measures several architectural changes at once.

What Is Still Missing

I have validated one path: LiveKit transport and orchestration with Amazon Nova 2 Sonic, browser and telephone channels, tools, persistence, and knowledge retrieval. I have not run the same workflow through the other frameworks, managed platforms, native audio models, or integrated agent platforms described above.

That boundary matters. Public documentation can establish what a product exposes. It cannot establish interruption quality, tool reliability, operational clarity, or cost per successful outcome under the same conditions.

The next useful map should be a controlled comparison of ownership boundaries.

Understanding voice AI as a stack leaves one open question: which layer becomes the durable control point? It could be the model session, the media network, the orchestration framework, the telephone platform, or the evaluation system that tells operators why a call failed.

An Agent That Can Pay for Its Tools

Amit — Sat, 22 Aug 2026 06:29:43 +0000

If agents are going to act on the open internet, they will eventually hit a price tag.

That changes the design problem. Calling an API is easy compared with letting a non-human actor spend money without handing it private keys, unlimited budget, or a prompt-level spending rule it can be talked out of.

The thesis: payment is not a tool call. It is a governed financial action.

That means the payment path needs more than a model deciding "yes" or "no." It needs user consent, credential isolation, session budgets, policy checks, telemetry, and a narrow proof path that the model cannot bypass. The useful primitive is not "agent calls payment API." The useful primitive is "agent can pay for a bounded resource without owning the wallet."

I tested that pattern with Amazon Bedrock AgentCore Payments, Coinbase CDP, x402, Cedar policy enforcement, CloudWatch, and a Strands agent plugin. The result is strong enough to change the mental model, with one caveat: this is testnet evidence, and not every x402 endpoint accepted the same generated proof.

What The Payment Primitive Owns

The clean architecture separates four jobs:

Layer	Job
Paid resource	Returns HTTP `402` with price, token, network, and `payTo` address.
Agent/tool	Encounters `402`, extracts the payment requirement, and asks for proof.
Payment manager	Generates the x402 payment proof without exposing wallet secrets to the model.
Governance	Enforces user consent, session budget, policy allow/deny, and observability.

That split matters. If the model sees private keys, the design is already broken. If the spending limit is prompt text, the design is also broken. The payment boundary has to sit outside the model context.

In the experiment, the AgentCore side owned the payment manager, connector, instrument, session, and proof generation. Coinbase CDP owned the delegated wallet/signing path. x402 provided the HTTP 402 challenge and proof format. Cedar controlled whether the paid action was allowed before the payment path ran.

The key detail: the model never needed the payment credential. It only needed a tool response that said, effectively, "this resource costs X on Y network." The proof came from the payment infrastructure.

The First Proof: HTTP 402 To HTTP 200

The base flow worked.

The test created a payment manager, Coinbase CDP credential provider, connector, active payment instrument, and short-lived payment session. The session had a 0.10 USD budget and a 30 minute TTL. The wallet was funded with Base Sepolia testnet USDC, and WalletHub permission was granted for the app to pay from that wallet.

Then the tool called a paid endpoint. The endpoint returned HTTP 402 with an x402 version 2 payment requirement on Base Sepolia. AgentCore generated a PAYMENT-SIGNATURE proof through the ProcessPayment API. The retry against the AWS-documented endpoint returned HTTP 200.

That proves the core primitive: an agent-side tool can hit a paid resource, receive a price challenge, generate proof through infrastructure, and retry successfully without the model touching the wallet.

I also ran a controlled two-sided merchant test. Instead of paying a sample endpoint, I created a separate merchant wallet and ran a local x402 endpoint that advertised that wallet as payTo. The paid retry returned HTTP 200, the buyer wallet decreased, and the merchant wallet increased by 0.001 testnet USDC.

That second test matters because it proves both sides of the flow: the buyer can generate proof, and the merchant can receive value.

Budget Is Not A Prompt Instruction

The most important test was not whether a payment could succeed. It was whether a payment could be stopped.

I created a session with a 0.02 USD budget and used a local paid endpoint priced at 0.01 testnet USDC. AgentCore generated two payment proofs in the session. After those attempts, the session showed 0 USD available spend. The next same-session proof request failed with InsufficientBudget.

That is the right failure mode.

The agent did not need to remember the budget. The prompt did not need to say "please do not spend more than two cents." The model could be instructed to ignore limits and the infrastructure would still reject the over-budget payment.

This is the deeper point: financial constraints belong in mechanisms, not model behavior. Prompts are useful for intent. They are the wrong place to enforce spend.

Cedar Before Payment

Budgets answer "how much can this session spend?" They do not answer "who is allowed to invoke this paid action with these arguments?"

That is where policy belongs.

I reused a live AgentCore Gateway with a Cedar policy engine in enforce mode. A valid user token called a governed action with two amounts:

Request	Result
`45.0`	Allowed
`600.0`	Denied with JSON-RPC `-32002` before backend execution

During the denied-call window, the Payment Manager logs showed zero new Payment processed events and CloudWatch showed zero new SpendAmount datapoints.

That proves the first control: policy can stop the workflow before the payment path starts.

Then I hardened the shape. A runner first called Gateway/Cedar with a small amount. If Cedar allowed it, the runner invoked the real x402 payment path. If Cedar denied it, the runner did not attempt payment. The allowed branch generated payment proof; the denied branch made no payment attempt.

Finally, I moved the paid-fetch implementation itself behind Gateway as a Lambda target. Cedar allowed amount < 0.01, denied the over-limit branch, and the Lambda entered AgentCore Payments only after policy allow.

The Gateway-hosted run proves the full chain: Cedar allow, proof generation inside the Lambda, denial before Lambda/payment for the over-limit request, and a settled 200 on the allowed branch's retry.

The architecture is still the right one:

Gateway policy allow/deny -> paid tool execution -> AgentCore payment proof -> retry paid resource

The policy decision happens before money can move. The payment session budget still applies after policy allow. Those are separate controls, and they should stay separate.

Observability Is Part Of The Product

Payment systems without audit trails are demos.

AgentCore Payments publishes metrics into AWS/Bedrock-AgentCore — SpendAmount, OperationSuccess, OperationFailure, OperationLatency, ActiveSessions, PaymentTokenFetchSuccess, PaymentTokenFetchFailures — with SpendAmount carrying ProcessPayment datapoints per Coinbase connector and payment manager. Vended log delivery for the payment manager produces lifecycle events for session creation, instrument retrieval, and payment processing, all in your own CloudWatch log group.

Metrics and logs are one delivery pipeline. X-Ray span correlation is a second, entirely separate one, and it is easy to miss because nothing about ProcessPayment failing to appear in X-Ray looks like a missing configuration step — it just looks like empty search results. Log delivery uses logType=APPLICATION_LOGS pointed at a CWL (CloudWatch Logs) destination. Spans require their own delivery source with logType=TRACES, pointed at an XRAY destination:

aws logs put-delivery-source \
  --name "payments-traces-source" \
  --resource-arn "arn:aws:bedrock-agentcore:REGION:ACCOUNT:payment-manager/MANAGER-ID" \
  --log-type "TRACES"

aws logs put-delivery-destination \
  --name "payments-xray" \
  --delivery-destination-type "XRAY"

aws logs create-delivery \
  --delivery-source-name "payments-traces-source" \
  --delivery-destination-arn "arn:aws:logs:REGION:ACCOUNT:delivery-destination:payments-xray"

Configuring only the log pipeline — the natural first step, since it's what the getting-started docs walk you through — leaves X-Ray permanently empty with no error anywhere to point at the missing piece. I discovered this in July and confirmed it was not a platform gap in August: once the trace pipeline is wired up, Bedrock.AgentCore.Payments.ProcessPayment spans appear within a couple of minutes carrying the documented attributes: payments.spend_amount, payments.merchant, payments.payment_session_id, payments.payment_instrument_id, down to aws.request_id.

That last set of attributes is the actual payoff. Metrics tell you that spend happened; a span tells you which spend, tied to which session, which merchant, which request. For a platform where agents pay third parties on a customer's behalf, that's the mechanism for answering "which specific payment failed, for which customer, at which merchant, for how much" during an incident or a billing dispute — one X-Ray trace correlating the Gateway request, the Cedar decision, the Lambda execution, the ProcessPayment call, and the merchant settlement, without grepping across log groups by hand.

Agent-Native Payment Flow

The script path is useful for proof. The agent-native path is what product builders will care about.

I tested the Strands AgentCorePaymentsPlugin with the real http_request tool. The tool returned HTTP 402. The plugin detected it, called AgentCore Payments through PaymentManager.generate_payment_header, injected a PAYMENT-SIGNATURE header, and requested a retry.

The tool retried with the injected header and got back HTTP 200 — the plugin owns the entire handshake, proof generation through settled resource access, without the tool author writing any custom 402 handling.

Two Prerequisites That Will Block You Cold

Using Coinbase as a payment provider requires subscribing to "Coinbase Wallets for AgentCore Payments" in AWS Marketplace. Until that subscription is active, CreatePaymentConnector and every wallet operation reject with SubscriptionRequiredException. It's a real, metered charge — $0.005 per wallet operation, consolidated onto your AWS bill.

Separately, Coinbase CDP wallet permissions are wallet-scoped, time-bound grants: the end user picks 7, 30, 60, or 90 days when authorizing the agent to sign. ProcessPayment returns AccessDeniedException: Delegated signing grant is not active the moment it lapses. If a payment call starts failing with that specific error, check the grant's expiry before assuming anything else is wrong — it fails the exact same way whether the grant expired yesterday or was never issued.

Quick Create's Seatbelt

Quick Create provisions Coinbase credentials for you: authorize once via OAuth in the console, and AgentCore creates the payment credential provider on your behalf, no pasted API keys. Point it at a Coinbase project that already has a manually-created Wallet Secret, though, and it refuses outright: "This Coinbase project already has a Wallet Secret, so a new one can't be created automatically."

That's a safe-failure guardrail, not a bug — silently generating a second secret could orphan wallets already derived from the first. But Quick Create only completes its automatic path for a project that has never had a Wallet Secret generated, and the quick-start guides still document manual CDP key generation first. Follow the docs in order and you permanently lose access to Quick Create for that project; only a fresh Coinbase project gets the one-click path.

Three Bugs That Weren't AWS's

Moving the paid-fetch implementation behind Gateway as a Lambda target kept failing the same way at first: a proof generated, a retry rejected with an empty 402 body. The obvious suspects were a rate limit on the sandbox endpoint or an edge-cache hit. Both testable, both wrong — a plain script from a local machine worked fine against the identical endpoint.

Temporary CloudWatch logging inside the Lambda found the real story: ProcessPayment was returning a fully valid, signed proof, authorization and signature intact, on every call. The Lambda was throwing it away:

# what the Lambda was doing — wrong
payment = client.process_payment(...)
result = payment.get("processPayment", {})   # this key does not exist
proof = result.get("paymentOutput", {})       # -> always {}

# the boto3 response is flat, no wrapper
# {"processPaymentId": "...", "status": "PROOF_GENERATED",
#  "paymentOutput": {"cryptoX402": {"payload": {...signed...}}}}
proof = payment.get("paymentOutput", {})       # correct

The process_payment reference confirms it: processPaymentId, status, and paymentOutput are flat, top-level response fields, matching every AWS SDK example published for the API. The bad .get() call silently returned {}, so the retry always carried payload: null — which any x402-compliant merchant correctly rejects.

Two smaller bugs rode along with it: the deployed Lambda source was missing import os, crashing on every cold start behind a retry loop that swallowed the real traceback; and a policy-engine ID was hardcoded from an earlier public-sanitization pass instead of reading from the environment. None of the three were platform bugs. All three had been quietly filed under "the sandbox is flaky" until logging showed otherwise. "It's the network," "it's rate limiting," and "it's flaky" are all real phenomena — in a system with this many moving parts, any of them was plausible. None of them were the fix. Reading the actual response was.

What Is Still Missing

This experiment ran on testnet and does not prove mainnet charging, customer billing, tax handling, refund workflows, fraud handling, or production compliance. Those are different systems.

The core primitive (payment proof generation, session budgets, policy gating, observability) has been validated against GA and all endpoint retry tests have succeeded end-to-end with settled HTTP 200 responses. CloudWatch traces and X-Ray span correlation were reconfirmed as long as both delivery pipelines are wired — that was a configuration gap, not a platform gap.

Coinbase's x402 Bazaar — a curated MCP server exposing thousands of pay-per-use x402 endpoints — is reachable through Gateway. The open thread: I still haven't proven end-to-end agent discovery of a live Bazaar endpoint with a successful settled payment, only that the pieces wire. The blocks are technical (Gateway-to-Bazaar MCP compatibility) not architectural. The pattern itself is sound.

So What

The interesting part of agent payments is not that an agent can call a payment API.

The interesting part is that spending can be bounded by infrastructure, authorized by policy, observed through logs and metrics, and executed without putting wallet secrets into model context.

That is the pattern worth carrying forward:

Intent lives in the model.
Authority lives in policy.
Budget lives in the payment session.
Credentials live outside the model.
Evidence lives in telemetry.

An agent that can pay for its tools is not a wallet with a chat box. It is a governed actor with a narrow financial action path. That is the difference between a demo and something you can reason about.

MPP vs x402: Two Competing Answers to the Same HTTP 402

Amit — Sat, 22 Aug 2026 06:29:07 +0000

Two protocols answer HTTP's thirty-year-old, never-implemented 402 Payment Required status code, and Amazon Bedrock AgentCore Payments speaks both. x402 (Coinbase) and MPP (Stripe and Tempo) are direct competitors for the same job: an agent hits a paywalled resource and pays for it inline, no API key, no billing account set up in advance. They disagree about what "pay" is allowed to mean.

sequenceDiagram
    participant A as Agent
    participant M as Merchant
    participant AC as AgentCore Payments
    A->>M: GET /resource
    M-->>A: 402 Payment Required + challenge
    A->>AC: ProcessPayment(challenge)
    AC->>AC: check session budget, sign with wallet
    AC-->>A: signed proof / credential
    A->>M: retry + proof (x402: PAYMENT-SIGNATURE, MPP: Authorization)
    M-->>A: 200 OK

Both protocols follow that identical outer loop. Where they diverge is what each one chooses to standardize.

Same shape, different commitments

	x402	MPP
Settlement	On-chain only — stablecoins, primarily USDC on Base	Multi-rail — Tempo stablecoins, Stripe cards/ACH/BNPL via Shared Payment Tokens, Bitcoin via Lightning
Retry header	`PAYMENT-SIGNATURE` (v2) or `X-PAYMENT` (v1)	`Authorization: Payment <base64url-token>`
Pricing model	`exact` (fixed price) and `upto` (metered, settle-for-less-than-authorized)	Charge intent, plus a session primitive for high-frequency metered billing
Facilitator	Required — a third party verifies and settles the on-chain transfer	Framed as a formal HTTP auth scheme; some methods avoid a separate facilitator dependency
Transport	HTTP only	HTTP, plus an MCP transport binding — MCP tool servers can charge per tool call directly
Backing	Coinbase, fully open and permissionless	Stripe + Tempo, with Visa and Lightspark extending it to cards and Lightning

AgentCore's release notes describe x402's exact and upto schemes and MPP as three parallel options behind one ProcessPayment API — you pick paymentType (CRYPTO_X402 or MPP) per call, and the wallet, budget check, and signing path are identical underneath.

x402's `upto` scheme: pay for what you actually used

upto lets a merchant advertise a ceiling instead of a fixed price. The buyer's wallet authorizes a Permit2 allowance up to that ceiling, and the merchant settles for whatever was actually consumed — no larger than the ceiling, no second round trip. That's what makes per-token LLM inference or metered compute billable in a single request/response instead of a price negotiation.

I proved this by extending a local x402 merchant with UptoEvmScheme and a Settlement-Overrides response header carrying the real charge:

// merchant route: authorize up to a ceiling, settle for less
app.get("/metered-recap", (_req, res) => {
  res.setHeader(
    "Settlement-Overrides",
    JSON.stringify({ amount: "1000" }),  // actual metered charge
  );
  res.json({ status: "paid", settledUnits: "1000" });
});

# buyer: authorize a ceiling, let the merchant settle lower
payment = client.process_payment(
    ...,
    paymentType="CRYPTO_X402",
    paymentInput={"cryptoX402": {
        "version": "2",
        "payload": accept,
        "permit2AllowanceLimit": accept["amount"],  # the ceiling
    }},
)

ProcessPayment authorized a ceiling of 15000 base units on Base Sepolia testnet; the merchant declared an actual charge of 2000. Checking the wallet's on-chain balance immediately before and after confirmed it moved by exactly 2000, not 15000 — real settlement tracked real usage, not the authorization.

The gotcha: the ProcessPayment X-Ray span's payments.spend_amount attribute reads the ceiling, not the settled amount, because AgentCore signs the authorization before the merchant declares what it actually consumed. A spend dashboard built on that span attribute alone will overstate real spend for upto transactions — reconcile against actual settlement, not the span, to get the true number.

MPP: one interface, four rails behind it

MPP standardizes the challenge-response interface and lets the merchant advertise whichever payment methods it accepts — evm, tempo, solana, and through Stripe, card and fiat — inside one WWW-Authenticate: Payment header, per the mpp-specs IETF draft co-authored by Tempo and Stripe.

No live MPP-compatible merchant exists anywhere yet to round-trip against — not from AWS, not in Coinbase's Bazaar. To prove AgentCore's side of the handshake, I built the smallest thing that could: a synthetic, spec-compliant evm-method challenge.

WWW-Authenticate: Payment id="<unique-id>", realm="<realm>",
  method="evm", intent="charge",
  request="<base64url JSON: amount, currency, recipient, methodDetails.chainId>"

payment = client.process_payment(
    ...,
    paymentType="MPP",
    paymentInput={"mpp": {
        "version": "1",
        "wwwAuthenticateHeaders": [header_value],  # forwarded verbatim
    }},
)
credential = payment["paymentOutput"]["mpp"]["paymentCredential"]
# -> "Payment <base64url-token>", ready to attach as Authorization

Two checks confirmed AgentCore genuinely parsed the challenge rather than rubber-stamping it: the session's available budget dropped by exactly the amount declared in the request (0.02 → 0.019 USD for a $0.001 charge), and the returned credential was a well-formed, 1176-character token with the documented Payment prefix. That's genuine credential generation, matching the ProcessPayment response schema exactly. What it doesn't prove is settlement — there's nothing real to settle against yet.

When to reach for which

x402 when buyers already hold stablecoins and you want the simplest integration, a full on-chain audit trail, and sub-cent transaction costs — paywalled content, one-off compliance lookups, real-time market data.
MPP when your buyer population doesn't hold crypto, or you need card/ACH reach alongside stablecoins, or you're billing something metered and high-frequency where MPP's session primitive fits better than repeated 402 round trips.

AgentCore Payments doesn't make you choose between them. It abstracts the protocol behind one API, so the decision moves from "which protocol do I integrate" to "which protocol does this merchant accept" — which is the right place for that decision to live.

The open thread

Full settlement against a live MPP merchant hasn't been tested anywhere yet — no public merchant exists that accepts MPP payments through the complete cycle. I've proved that AgentCore can generate valid credentials and that budget tracking works, but settling a real charge against a real merchant and confirming the merchant received payment remains untested. This is a genuine gap, not a missing step in the documentation. Once live MPP merchants exist in production, the full picture — credential generation, settlement success, reconciliation — will be available to verify.

A Browser That Pays

Amit — Sat, 22 Aug 2026 06:28:32 +0000

Amazon Bedrock AgentCore names five official use cases for Payments: research, financial analysis, pay-per-inference, on-demand storage, and — quoted with a named customer — browser agents. Anchor Browser, a cloud browser-automation platform, integrated AgentCore Payments specifically to unlock paywalled web content for its customers' agentic workflows.

That combination — a real, isolated Browser Tool session driving through an actual 402 paywall — surfaces a protocol detail most payment paths never hit: a browser doesn't see what a script does.

The flow

sequenceDiagram
    participant B as AgentCore Browser (Playwright/CDP)
    participant S as Paywalled site
    participant AC as AgentCore Payments
    B->>S: navigate
    S-->>B: 402 + @x402/paywall HTML widget
    B->>B: read data-requirements DOM attribute
    B->>AC: ProcessPayment(challenge)
    AC-->>B: signed proof
    B->>S: re-navigate, proof injected via route interception
    S-->>B: 200 OK

The documented pattern uses Playwright connected to a managed Browser Tool session over Chrome DevTools Protocol, with Playwright's response interception catching a 402 mid-navigation:

from bedrock_agentcore.tools.browser_client import browser_session
from playwright.sync_api import sync_playwright

with browser_session(REGION) as client:
    ws_url, ws_headers = client.generate_ws_headers()
    with sync_playwright() as p:
        browser = p.chromium.connect_over_cdp(ws_url, headers=ws_headers)
        page = browser.contexts[0].new_page()
        response = page.goto(paid_url)   # 402 on first navigation

The wrinkle: two different 402s

Here's the part that isn't written down anywhere. A script's 402 comes back as JSON with a PAYMENT-REQUIRED header holding the base64-encoded challenge. Point a real browser (Chromium's Accept: text/html) at the same URL, and the server returns something else entirely: a human-facing @x402/paywall HTML page, no PAYMENT-REQUIRED header at all, with the identical challenge JSON embedded in a widget instead:

<div id="payment-widget"
     data-requirements='{"x402Version":2,"accepts":[{"scheme":"exact",
       "network":"eip155:84532","amount":"2000","payTo":"0x...","asset":"0x..."}]}'>
  <!-- Install @x402/paywall for full wallet integration -->
</div>

That's the standard @x402/paywall convention — the same challenge, rendered for a human wallet-connect UI, but just as readable by an automated browser:

raw = page.eval_on_selector(
    "#payment-widget", "el => el.getAttribute('data-requirements')",
)
requirement = json.loads(raw)

Once the challenge is read from the DOM instead of a header, everything downstream is identical: ProcessPayment generates a real proof, Playwright's route interception injects it into the retry, and the re-navigation settles to 200:

def add_payment_header(route, request):
    route.continue_(headers={**request.headers, **payment_headers})

page.route(paid_url, add_payment_header)
retry = page.goto(paid_url)   # 200

Why this matters

Every other payment path in AgentCore — a script, a Lambda, a backend service — talks to a merchant as a machine. Browser agents talk to the same merchant the way a human would. The target site was built for human traffic and gates agent access the same way it gates a browser without an active subscription. The paywall doesn't know or care that a script is driving the Chromium under the hood. It serves the human-facing challenge either way, and the agent has to be able to read it.

That's the actual shape of the "browser agents" use case: not a new payment mechanism, but the same ProcessPayment primitive plugged into a client that has to speak the paywall's native language — HTML and DOM, not headers and JSON — before it can pay at all.

For anyone building this: the gap isn't in AgentCore Payments. It's in knowing that the same endpoint returns different response shapes based on what User-Agent and Accept headers the request carries. A script gets the header-based challenge. A browser gets the widget. If you're working with the managed Browser Tool through a paywall, you need to handle both, or at minimum understand that the browser path requires DOM extraction instead of header parsing.

What's missing

Browsers drive the unscripted web — portals, JavaScript-rendered content, interaction-gated resources — but they're only half the story. Most of these paywalled portals still have API endpoints that prefer a script path, and the cleaner play, where available, is usually to find the native API. The real complexity emerges when a portal only surfaces data through the browser UI, forcing the agent to navigate like a user. Paywalls add another layer: they're not guarding the browser itself; they're guarding specific resources behind the browser. Understanding when a paywall applies to the browser path vs. the API path, and whether the managed Browser Tool or a native API fetch is the right reach, is the decision tree most projects face first.

The one thing AgentCore Payments doesn't clarify in the docs (and that teams building this pattern hit immediately) is exactly this: how to detect which challenge shape you're getting, and how the managed browser's isolation plays with credential caching across sessions. That's the open thread for the next builder who runs this live.

AgentCore Registry Is a Governed Catalog for Agent Interfaces

Amit — Sat, 22 Aug 2026 06:07:27 +0000

AgentCore Registry provides discovery for reusable agent interfaces, but the important behavior is not simple name resolution. The tested path was: create a registry, publish an A2A descriptor, move the record through approval, search approved records, resolve the Agent Card, and invoke the discovered agent.

That makes Registry a governed catalog for the agent graph. Hardcoded runtime ARNs are the visible pain. The deeper problem is uncontrolled reuse: which agents exist, which interface they expose, who approved them, and whether a caller is using the right version.

AWS Agent Registry gives that workflow a control plane: create a registry, publish a record, submit it for approval, approve it, then search only approved records. The record can describe an A2A agent, an MCP server, an agent skill, or a custom resource. The shape is intentionally catalog-first.

The thesis: agent discovery becomes a governance problem before it becomes a routing problem.

Hardcoded ARNs Are Only Part of the Problem

Hardcoded ARNs are easy to hate. They make demos brittle. They make account migration annoying. They make blue/green rollouts awkward. They also create the comforting illusion that the problem is only lookup.

It is not.

If a caller has a hardcoded ARN, at least it knows exactly what it is calling. A Registry-backed caller moves one level up: it asks for a capability, receives one or more approved records, resolves the interface, and invokes the selected agent. That adds power, but it also adds a new question:

Who gets to publish something discoverable?

That is where Registry differs from DNS. DNS does not ask whether a service is approved for reuse. Registry does. A record moves through lifecycle states before it becomes searchable. In our test, the A2A record moved from DRAFT to APPROVED before the search path could use it.

That lifecycle is the control point.

The Experiment

The verification ran two parallel paths: one against the preview API and one against the GA surface. Both proved the Registry-to-A2A integration path works end to end.

Test	Result	What It Proved
Preview: Create, approve, search, resolve	PASS	A live A2A Agent Card can be published as an approved Registry record and discovered by search.
Preview: Invoke through discovered card	PASS	A caller can resolve the Agent Card from a Registry record and invoke the discovered agent through A2A without hardcoding the runtime ARN.
GA: Control and discovery APIs	PASS	The GA Registry APIs (`agent-registry-control`, `agent-registry`) create, approve, list, retrieve, and delete records.
GA: Registry-to-A2A invocation	PASS	A caller retrieved an A2A Agent Card from a GA Registry record and invoked the agent through A2A, then cleaned up the record and Registry.

The target was a deployed A2A specialist agent exposed through an Agent Card:

Name: enterprise support escalation specialist
Protocol version: 0.3.0
Function: assess support tickets, return severity, owner, SLA, and next steps

The Registry record was created as an A2A descriptor. The test captured:

Registry status: READY
Record after create: DRAFT
Record after submit: APPROVED
Search by name: returned the approved record

Then the search script selected the A2A record, parsed the Agent Card returned in the descriptor, and invoked the agent through the resolved card URL. The caller did not hardcode the specialist's runtime ARN in the delegation path.

The test case was deliberately operational: an enterprise customer had a double charge and production API access failure during quarter-end close. The discovered specialist returned:

P2 severity, Named TAM owner, 12-hour SLA.

That response matters less than the path. The important part is that the caller found an approved agent record, resolved its interface, and delegated over A2A.

What the Evidence Supports

The preview validation and GA revalidation support a narrower and more precise statement:

Registry is the catalog layer where agent interfaces become approved assets.

That is more than runtime address lookup. It changes what teams design around.

If Registry were only ARN lookup, the natural question would be, "Why not use an environment variable?" For a single caller and a single callee, that is still a good answer. A static env var is simpler, cheaper, and easier to debug.

Registry becomes worth the extra lookup when the organization needs reuse with control:

Multiple callers need to discover the same agent.
A platform team wants to publish approved A2A agents or MCP servers.
Records need owners, versions, status, and audit history.
Callers search by capability instead of importing another team's configuration.
Agent interfaces are validated before they become reusable.

The Registry record is not only a pointer. It is metadata plus interface contract plus lifecycle state.

The Namespace Migration Is Part of the Contract

The migration is no longer future work. The current GA path uses the agent-registry-control client for lifecycle operations and the agent-registry client for discovery. This shift is not merely naming cleanup. It affects every script that creates, searches, or audits Registry resources, along with IAM policies, ARN formats, events, metrics, and quotas.

The two namespaces differ on every surface:

Surface	Preview Namespace	GA Namespace
CLI/API	`bedrock-agentcore`, `bedrock-agentcore-control`	`agent-registry-control`, `agent-registry`
IAM actions	`bedrock-agentcore:*`	`agent-registry:*`
ARNs	`arn:aws:bedrock-agentcore:...:registry/...`	`arn:aws:agent-registry:...`
Events/metrics	Bedrock AgentCore sources	Agent Registry sources

The practical rule: keep Registry client names, endpoint assumptions, and IAM action prefixes isolated in one layer. Do not scatter them through experiment code.

What the First Search Miss Showed

The first capability-style search did not return the record:

tier two escalation agent for enterprise billing tickets

The name search did:

enterprise support escalation specialist

That miss shows that catalog quality matters. Search is only as good as the record metadata, descriptor content, and query vocabulary. A Registry record with thin descriptions creates a weak discovery surface. A record with clear capability language gives the caller more to work with.

For production use, publishing an agent includes the same care as publishing an API:

crisp description
clear capability names
versioning
owner metadata
examples of when to use it
examples of when not to use it

Without that, Registry becomes a list of endpoints. With it, Registry becomes a catalog of approved agent capabilities.

What Registry Does Not Solve

Registry does not eliminate the rest of distributed-agent design.

It does not prove the agent is safe to call. Approval helps, but runtime behavior still needs observability and policy. It does not solve identity propagation across an A2A hop. The caller still needs the right permissions, and the callee still sees the authenticated caller according to the runtime auth model. It does not prevent delegation loops. Multi-agent systems still need hop budgets and loop controls.

It also does not remove the need to understand the interface. In our test, the caller resolved an A2A Agent Card and invoked the agent through that card. That worked because the callee exposed a real A2A surface. A plain HTTP runtime would need a custom record or another descriptor strategy.

This is the right boundary. Registry is not an orchestration layer. Its job is to make approved capabilities discoverable with enough metadata for a caller to decide what to do next.

So What

If you are building a multi-agent system, the question is not "How do agents find each other?"

The better question is: "Which agents are approved for reuse, and how does a caller know?"

For a small system, an environment variable is fine. For an agent graph that spans teams, accounts, or protocols, discovery needs governance. Registry gives that governance a place to live.

The next frontier is not lookup. It is trust: richer metadata, better search vocabulary, signed cards, policy-aware invocation, and clear ownership for every reusable agent capability.

That is where the agent graph starts to look less like a pile of runtimes and more like an operating model.

The open question I am holding: I have tested single-caller discovery paths. The multi-agent pattern — agents that invoke each other over A2A, each with its own identity and Registry record — is where the authorization model gets genuinely harder, and it is where I haven't yet wired the full lifecycle.

Part of a series working through Amazon Bedrock AgentCore by building on it. Start with The AgentCore Map, then Where AgentCore Sits in the Architecture. The mechanics behind Registry: AgentCore Runtime and Two Ways to Authorize an Agent Tool.