MENU
AI agents can now buy You.com APIs on their own. An agent that needs search or research reaches You.com directly, pays with a delegated credit card, for example Visa or Mastercard, inside limits a person set in advance, receives a working API key, and carries on with the task. Nobody provisions the key by hand. Nobody pauses the run to go find a credential.
That sentence is the easy part. The interesting part is what the agent is buying.
You.com provides the leading web search APIs for AI. Many search APIs hand an agent a pile of documents and leave the reasoning to the model. The higher tiers of the You.com APIs do the reasoning first and return a synthesized answer with every claim traced to a source, which is why its customers tend to be people who have to show their work.
Five APIs sit behind a single key.
The research APIs run across up to 400 sources at once, 500 or more on the enterprise tier including internal and licensed premium data, and return cited reports where every claim links back to where it came from. The infrastructure carries SOC 2 certification and zero-data-retention options, which matters a great deal to the buyers it was built for.
The customers reflect that. Global advisory firm APCO uses it to connect internal expertise with external research when preparing client communications. WestCap came in as a design partner, shaping the research APIs around a real investment process. Wort & Bild Verlag, Germany's largest health media publisher, was in the early cohort. Consultants, financial analysts, researchers, people whose output gets audited.
The Finance Research API is the sharpest expression of it: agentic research over licensed data including S&P Global. You.com reports a score of 87.29% on FinSearchComp, an open-source expert-level benchmark for financial search and reasoning built with 70 financial experts and published at ICLR 2026, placing it more than fourteen points clear of the field.
You.com does not sell one thing at one price. It sells a range, and the range is wide:
You.com published rates. Effort tier is selected by the caller at request time.
This is the situation delegation was built for. When a call costs half a cent, a spending limit is paperwork. Nobody was ever going to lose money on a runaway web search. When a call costs fifty cents and produces a cited report that a portfolio manager will act on, the limit stops being an administrative detail and becomes the thing that makes the arrangement possible at all.
Consider what is actually being authorized. You are letting software decide, without asking first, how much of your money a given question is worth. An agent deciding that a question deserves exhaustive treatment is making a spending decision, not only a quality decision. Almost nobody signs off on that in the abstract. They sign off on a bounded version of it: this much, for this long, scoped to this key, and no further.
So the boundary is not a constraint bolted onto the capability. It is the precondition for anyone permitting the capability in the first place. Get the safeguards right and the autonomy becomes something a risk committee can approve. Leave them out and the whole thing stays a demo.
For this buyer, the payment instrument is not an implementation detail.
A compliance team at an advisory firm does not want a novel settlement rail. They want the transaction to appear where every other transaction appears. Card delegation means the agent's spending shows up in the corporate card statement, under the existing merchant controls, inside the existing spend policy, in the existing reporting, settled through the payment service providers they already run, like Stripe, for example. Nothing new to audit, nothing new to explain to a regulator, and no treasury conversation about holding a balance in something unfamiliar.
The limits are set by a person, before the agent runs: an amount, a duration, and optionally a scope tied to one API key. The agent operates inside them and cannot widen them. It never sees a card number, never creates an account, never enters a password. It presents an instrument that was already bounded.
That is a meaningfully smaller grant of authority than the API key most teams hand an agent today, which typically carries no spending limit at all.
Here is an example of how that flow looks in practice.
payment-signature header.When credits run out, the API returns 402 and the agent repeats from step 4. No human is in the loop for the second purchase, or the twentieth, until the delegation is spent or expires.
Step 3 is the one most services skip. A payment path an agent cannot find is a payment path that does not exist, so You.com published the route in the file agents actually read. Their llms.txt carries a line naming Nevermined as an option for purchasing a key, and every docs page is retrievable as clean Markdown by appending .md to its URL. There is also an MCP server at you.com/docs/_mcp/server for coding agents. Discovery, not just settlement.
Full documentation: You.com integration guide. See the You.com API docs for how to exercise each endpoint.
This runs on the cards you already carry. A standard credit card, for example Visa or Mastercard, through Stripe or whichever payment service provider you use today. What card delegation adds is a set of boundaries applied before the agent ever runs:
listDelegations(): amount spent, transaction count, current status.You keep visibility through the infrastructure you already operate. The agent works inside a boundary you defined.
The failure this removes is specific. An agent halfway through a task determines it needs a source it cannot reach, and the run ends there. Not because the reasoning failed, but because a credential was missing. Every scheduled job, every overnight batch, every long-horizon task inherits that fragility.
With provisioning handled by the agent, a research workflow can start without a key already in place, escalate to a deeper tier when a question turns out to be harder than expected, and keep running across nights and weekends when nobody is available to buy anything. The credential stops being something you stage in advance and becomes something the task acquires as it needs it.
Most proposals for letting agents transact ask a company to adopt something new: a wallet, a balance, a token, a rail nobody in finance has approved. That request usually dies in review, and reasonably so, because it introduces an unfamiliar surface for a benefit nobody has yet demonstrated.
This asks for none of that. The card is issued by your bank. The processor is the one you already use. The controls are the controls your policy already specifies. The charge lands in the statement your team already reconciles. What is new is the boundary in front of it.
For a regulated buyer there is a second point worth drawing out. Because the delegation is created before the run and cannot be widened by the agent, the authorization is a human act with a timestamp, an amount and a scope. That is a far more defensible artifact than an API key handed over with no limit and no expiry.
You.com joins a small group of services that can accept payment directly from an agent. That group is worth understanding from the merchant's side, because the problem it solves is an acceptance problem, not a demand problem.
Agents have wanted to buy for a while. Ask any developer running a research pipeline how often the work stops because a key ran dry. What was missing was a way to take the money: a merchant could not distinguish an agent that wanted to pay from a scraper, and had no mechanism to accept payment from software acting for a person. Those are now the same rails the merchant already accepts, with a delegation standing in for the human's authorization.
What makes You.com an interesting second data point rather than a repeat of the first is the price range. Proving this works for a five dollar search top-up is one thing. Proving it works when a single call costs fifty cents and the buyer is a compliance-bound advisory firm is a different and harder thing.
The pattern underneath is small and repeatable:
Every step of that already runs in production. What changes as more services adopt it is the shape of what an agent can be asked to do. A task no longer has to be scoped to the credentials it was handed at the start. It can be scoped to a budget instead, which is a much more natural way to describe work.
And the buyer being described here is genuinely new. Not a person using software to buy, but software buying on a person's behalf, inside limits that person set. Merchants who can accept from that buyer will reach demand that currently gives up and goes away.
Be deliberate about effort tiers. An agent with a $50 delegation and permission to call Finance Research at exhaustive has a hundred calls before it stops. The same delegation is ten thousand web searches. Size the delegation against the tier the agent is actually allowed to request, not against the cheapest thing it could do.
Keep delegations short to start. An hour is a reasonable default for a single task. Widen the window once you have watched a few runs and know what the work actually costs, rather than provisioning for the worst case on day one. Least privilege applies to time as much as to amount.
Prefer a delegation a human created. An agent can create one programmatically when no operator is reachable, but then the agent is choosing the card and setting its own limit. That is a fallback, not a default.
If you are building on You.com:
If you sell an API and want agents to be able to buy it, talk to us. The merchant-side work is smaller than most teams expect, and publishing your terms in llms.txt costs an afternoon.
You.com joins a quickly growing list of merchants accepting payment directly from agents, and it is the one where the price of a single call is high enough that the boundary does real work. That progression matters more than any single integration. The open question was never whether an agent could complete a five dollar purchase. It was whether anyone responsible for a budget would let it, once the amounts stopped being trivial.
The answer, so far, is yes, provided the authorization is human, bounded, and visible in systems the company already trusts.
As agents take on longer and more consequential work, the services they need will get more expensive, not less. Licensed data, specialized computation, domain expertise, premium indices. The constraint on that future is not whether an agent can transact. It is whether the people accountable for the spending can see it, bound it, and stop it. That is the part worth building carefully, and it is the part we are building.
No. This settles on a standard credit card, for example Visa or Mastercard, through the payment service provider you already use.
In governance terms it is the same thing, which is the point. A delegation is a bounded grant against a card you already own: an amount, a duration, and optionally a scope tied to one API key. The difference from handing over a card number is that the agent never sees one. It presents an authorization that was already limited, and it cannot widen it.
No. The delegation is created with a fixed amount and duration. The agent spends inside it and stops when it is exhausted. Raising it is a human action.
Two levers, both outside the agent's reach. The delegation expires on its own at the duration you set, which is why a short duration is the right default for a single task. And because the instrument is a card, your existing card controls apply to the payment method itself. Nothing the agent can do extends either one.
The same person who would be accountable for any delegated spend, and the record is clearer than most. The authorization is a dated human act with an amount and a scope attached, made before the run. The exposure is capped at that amount by construction, and because settlement is on a card, the usual dispute and chargeback routes are available.
Nothing in the payment layer, because that is a decision in your agent's own logic and it should be an explicit one. What the payment layer guarantees is that the total is bounded no matter what the agent decides.
Two places. listDelegations() reports amount spent, transaction count and status per delegation. And because this is a card, the charge appears in your normal card reporting alongside everything else.
You.com returns 402. The agent mints a fresh token against the same plan and delegation, posts it to the purchase endpoint, and continues with another $5 of credits on the same key. No human is involved unless the delegation itself is spent or expired.
Yes, and it is the common case. The second purchase tops up the key it already holds and returns toppedUp: true.
It uses standard card delegation, so your existing controls, spending policies and reporting all apply. The authorization is a human action with an amount, a duration and a scope, recorded before the agent runs.
The amount is a property of the plan You.com published. The card-delegation scheme itself does not require a fixed price, so a merchant serving a live 402 can name any amount and the agent will settle it.
It requires a merchant-side integration, which is smaller than most teams expect. Get in touch and we will walk through it.
You.com builds the leading web search APIs for AI, including Web Search, Contents, Answer, Research and Finance Research APIs. The research APIs can ingest hundreds of sources for consultants, financial analysts and researchers in regulated industries, with SOC 2 certification and zero-data-retention options.
Nevermined builds payment infrastructure for AI agents. Its card-delegation protocol lets an agent transact on a standard credit card inside limits a human sets in advance, so autonomous spending runs through the card controls, policies and reporting a company already has.
Ready to let an agent buy its own research? Start with You.com + Nevermined
See Nevermined
in Action
Real-time payments, flexible pricing, and outcome-based monetization—all in one platform.
