The allegiance layer for AI agents

When an agent acts for you,
see whose side it was on.

Your agent just made a choice for you. Maybe it searched the whole market. Maybe it only searched the sellers who pay it. Stub is the receipt that lets you see which.

Identity

Proves the agent is who it says. Every serious agent has this already. It cannot tell you what the agent did with that trust.

vs

Allegiance

Proves whose side it was on. Whether a commission, a partner deal, or a placement fee shaped the answer you got.

The same task, two agents. Watch what identity can't tell you.
Maya asks: find me a flight to London
Your browser can't run the live signing demo. The reveal below is the real output.
Even Travel authenticated
idle
Nimbus Assistant authenticated
idle
An audit log would show two clean histories. Both agents did exactly what they said. The stub shows whose side each was on, because each had to declare it to issue one.
The object

A stub is a small signed record.

Eight fields. Signed once by the operator when the agent acts, witnessed by the registry every time it is checked.

stub · v0.1
{
  operator:      "Nimbus Assistant",      who runs the agent
  principal:     "2a1ba6c6…",             who it acted for, as a salted
                                          hash. no personal data
                                          reaches the registry
  requested:     "find me a flight",      what was asked
  done:          "booked one",            what actually happened
  value_moved:   "£280, 12% commission",  who got paid
  not_disclosed: [ "only partner airlines
                   were searched" ],       the field that shows
                                          whose side it was on
  issued_at:     "2026-07-20T…",
  signature:     Ed25519, operator key   forge this and you
                                          have signed a confession
}
How it works

Issue. Check. Resolve.

01 / ISSUE

The agent leaves a receipt

After it acts, your agent emits a signed stub: what it was asked, what it did, what value moved, and what it was not told. To issue a valid one, the operator has to declare the agent's mandate.

02 / CHECK

The person served can read it

The served party checks the stub without trusting the agent, the company that built it, or us. The check is witnessed by the registry with a signature the operator cannot forge.

03 / RESOLVE

It resolves on neutral ground

Stubs resolve at the registry, not the seller's own server. A receipt you verify on the seller's machine proves nothing. Neutrality is the product.

Why now

The volume, the rails, the money, and the precedent.

through 2025
13x
The volume arrived.

AI-referred orders on Shopify grew thirteenfold in a year, and more than half of those sessions land straight on a product page. The agent did not suggest a category. It named the product.

Shopify, 2026
January 2026
all
The rails are being laid.

Every major US card network is building agent payment rails. Mastercard has a live consumer product, Visa and Amex are piloting and shipping developer kits, and Google and Shopify put an open standard behind agent checkout.

Mastercard, Visa, Amex, Google, Shopify
March 2026
900M
Discovery is where the conflict sits.

OpenAI, with 900 million weekly users, pulled back from in-chat checkout to focus on product discovery instead. Discovery is the layer where an agent decides what you see. It is where paid influence lives, and today there is no way to audit it.

OpenAI, March 2026
What happens next
4 of 4
Disclosure always arrives.

Search results got labels in 2002. Drug company payments to doctors became a public database in 2010. Sponsored posts got tagged in 2016. Financial advisers have declared their conflicts for decades. Every channel that ever stood between a person and their money ended up having to say who was paying it, and not one of them volunteered. Agents are the newest channel, the money is already moving through it, and this is the first one where the agent decides rather than suggests.

FTC 2002 and 2013 · Sunshine Act 2010 · FTC endorsement rules
Quickstart · for builders

Ten minutes to prove you're on your users' side.

Your users are already asking whose side your agent is on. Today you can only tell them. Stub lets you show them. Three steps, once each, then one call per action. In JavaScript and Python.

1 Install
terminal
# one line
npm install @getstub/agent

One package. No config file. Works with any agent framework, because a stub is just the record of an action, not a wrapper around your loop.

2 Register once, and declare your mandate
setup.js
import { Stub, influenced } from '@getstub/agent'

const stub = new Stub({
  operator: 'Acme Shopping Agent',
  // this is the honest part. you say who
  // pays you and what you search.
  // policy level, approved once. which
  // conflict classes exist in your business.
  declared: {
    paid_by: 'the user, subscription',
    conflicts: ['commission']
  }
})
// keys are generated and registered for you.

The mandate is policy level and set once: who pays you, and which kinds of conflict exist in your business at all. It is the sentence your company can approve one time. What applied to each specific action travels on the stub itself, and your code fills that in.

3 Issue a stub after each action
agent.js
// your ranking code already knows when a
// boost or commission applied. pass it through.
const inf = []
if (pick.paid_placement) inf.push(influenced.placement(pick.seller))
if (pick.commission_pct) inf.push(influenced.commission(pick.commission_pct+'%'))

const receipt = await stub.issue({
  principal: user.id,   // hashed on your side, never leaves as itself
  requested: task.prompt,
  done: result.summary,
  value_moved: payment,
  not_disclosed: inf   // empty = nothing applied, and you signed that
})

// hand receipt.url to your user.
// they can check it. you're done.
show('Verify this action → ' + receipt.url)

One call per action. You get back a link your user can open to see what happened and whose side you were on. It resolves at the registry, not on your servers, so nobody has to take your word for it.

That's the whole integration. Be the first in your category who can show it, before it becomes the thing everyone is expected to have. See what your users see →
The Stub Mark

Issue receipts and you earn something you can show.

Field Notes: issuing receipts. Check this agent at the Stub registry.stubcheck

A live mark for your site, your docs, your README. Stub draws it from your own receipts, so you cannot set it and neither can we, and it goes quiet on its own if you stop issuing.

For the people your agent serves, it is the difference between your account of what happened and the record itself, resolving somewhere you do not control.

Nothing extra to install. It comes on when you have earned it. What the Mark means →

Recipes

Working code, for the stacks you actually build on.

Six runnable agents with Stub wired in at the line where the ranking happens. Clone one, run the tests, read the receipts it produces. They are references, not products in use, and each one says so.

Ready

Agentic Commerce Protocol

agentic commerce protocol

A shopping agent that ranks a catalogue, surfaces one product, and runs an ACP checkout. The receipt is issued at the choice, upstream of checkout, where placement fees and commission actually shape the answer.

17 tests · javascript
Ready

Raw tool-use loop

no framework · any provider

The lowest level version. A model, two tools, and a loop. Once you can see where the receipt goes here, you can place it in any framework, because every framework wraps this shape.

22 tests · javascript
Ready

MCP

@modelcontextprotocol/sdk

A read-only check server any agent can add, so the person being served can verify a receipt. Plus the operator pattern: your own MCP tools issuing receipts from your ranking code, where the flags live.

21 tests · javascript
Ready

LangChain

langchain 1.x · python

The same integration inside a framework agent. LangChain orchestrates the model and the tool calls. Your tool still does the ranking, so the receipt still comes from your code.

20 tests · python
Ready

Vercel AI SDK

ai sdk 7 · typescript

The biggest agent surface in JavaScript. The SDK runs the tool loop for you, and the receipt sits inside your tool, issued where the ranking happens.

21 tests · javascript
Ready

Insurance advice

outside commerce · python

An agent recommending a life policy, where the cheapest option is ranked last because it pays nothing. The gap costs the customer about a thousand pounds over the term. Same primitive, higher stakes.

17 tests · python
Why we publish these. A trust product should be checkable, including by the people asked to adopt it. Every recipe ships with tests you can run yourself, against registry logic running on your own machine, so you are not taking our word for how it behaves. All six run offline with no API key. All six on GitHub →
When to issue a stub

Issue where your neutrality is on the line.

A stub is not a log line. It marks a finished action a person would want to hold your agent accountable for. Put one at the moments where your agent chose, and something a commission or a partner deal could have swayed. Not on every tool call.

One question decides it:
If this went wrong, would the person want a receipt for it?
Yes means issue. No means skip. That single test does most of the work.
issue the completed, consequential act
  • Booked the flight, placed the order, sent the payment
  • Recommended one option as best, where you could have favored a payer
  • Chose this seller, route, or product over the alternatives
  • Took an action the person is now committed to
skip the steps along the way
  • Called a search or pricing API
  • Read a page, fetched a result, ranked candidates internally
  • Any intermediate step the user would never ask about
  • Anything issued once per second is almost certainly wrong
In practice

What this asks of you, and what we hold.

Two questions every builder asks before integrating.

Where do the disclosures come from?

Your ranking code already knows when a boost, a commission, or a partner filter applied, because it applied them. The stub reads the same flags at the same line and passes them through. That is why it scales: your system already tracks a million commercial relationships, or the ranking could not work at all.

The mandate you declare at registration stays small on purpose. Who pays you, and which conflict classes exist in your business. The sentence a company approves once. What applied to a specific action travels on the stub, filled by code.

What happens to my users' data?

Nothing personal reaches us. You pass your internal user id, the client hashes it on your side with a salt only you hold, and the registry rejects anything that is not an opaque digest.

stays on your side
  • user.id, the real one
  • the salt
  • the mapping between them
reaches the registry
  • 2a1ba6c6…
  • nothing else about the person

If a user asks to be forgotten, drop their mapping to the salt and every digest of theirs becomes permanently meaningless, while the record stays append only. Keep free text about the action, not the person; the client warns you in development if something looks like an email or a phone number.

On our side the list is short. No cookies, no analytics on this site, and no contact form collecting details into a database. Write to us and it is an ordinary email, held in an inbox like any other, deleted on request.

One limit, stated plainly

Stub carries the influence your system computes: the boosts, commissions, and filters that exist as flags in code. If a model absorbed a bias that no flag anywhere records, a receipt cannot surface it, and we are not going to pretend otherwise.

Check a stub · the resolver

See what your users see.

This is the resolver. Paste a stub ID and it verifies the signature, shows what the agent did and whose side it was on, and records the check. The receipt lives at the registry, where the operator cannot edit it after the fact, and that independence is the reason it is worth reading at all.

try a real one:
The directory · live

Everyone currently issuing.

Operators appear here by issuing. Their mandate is on the record, every stub they sign is checkable, and there is no other way onto this list.

0 stubs issued through the registry
Operators marked example were created by Stub to show how the directory reads. They are always flagged, and once real operators join they will be retired.
🎉 Field Notes fieldnotes.getstub.dev →

An agent we built. It reads new work on AI agents and trust, selects three things worth your time, and publishes two editions daily. Every edition carries a receipt you can check, and proves production readiness.

Morning edition ranks on source. Evening edition ranks on what people are discussing.

Read Field Notes
Pricing

Free while we are early. Priced with the people who use it.

Nobody has priced a receipt registry for agents before, including us. Until real operators run real volume through it, any number we put here would be a guess, so we are keeping it simple while we learn what this is worth.

Today
Free
Everything. Issue, check, resolve, the directory, the witness. Up to 1,000 stubs a month while we are early, generous enough to launch on.
npm install @getstub/agent
pip install getstub
shape it with us
Design partners
First ten
Ten seats, for operators shipping real agent traffic. You get a direct line to us, the registry shaped around your use case, and founding pricing locked in before a rate card exists for everyone else. When the ten are taken, this tier closes.
hello@getstub.dev
Later
Usage
Above the free tier, you will pay per stub. Metering is already live in the registry.
metered per operator

No card required. No sales call.

Changelog

What has shipped.

Every change we ship, dated and public.

changelog
core2026-08-12the alert palette no longer touches disclosure. amber was marking what an operator disclosed, which read as a warning about them rather than a fact about the record. disclosure is neutral everywhere now, and amber survives only where something is wrong with a record: an invalid signature, or influence outside the declared mandate
web2026-08-12the check page states what the operator disclosed instead of announcing they served someone else. same records, without the verdict
npm2026-08-09one identity now works from either client: getstub 0.2.1 reads a keypair exported by @getstub/agent, so moving between python and javascript no longer means abandoning your history
core2026-08-09the six reference integrations run against the live registry every day and issue real receipts, so the badge on the repo goes quiet if any of them break
npm2026-08-07@getstub/agent 0.3.0 and getstub 0.2.0 hand you the mark, and tell you once when you have earned it
core2026-08-07the stub mark is live: a badge drawn by the registry from your own receipts, earned by issuing across days, and nobody can set their own
api2026-08-07every operator now has a public page at getstub.dev/o/, with the mandate they declared and the record recomputed on the spot
sec2026-08-07badges are drawn per request and served as inert images, so a copied one resolves as unknown on whoever displays it
core2026-07-31removed the contact form based on user feedback, write to hello@getstub.dev instead; we now hold no user contact info in a database
core2026-07-31hardened the registry against data loss, with the record backed up off-site
npm2026-07-30getstub 0.1.1 for python sends a user agent, so calls are no longer blocked before reaching the registry
npm2026-07-30@getstub/agent 0.2.2 runs on edge runtimes, no node built-ins on the signing path
core2026-07-30all six recipes now run against the live registry on the free tier, with an identity you keep
core2026-07-30field notes is live, the first agent issuing through the registry, two editions a day
sec2026-07-30every stub now records the key that signed it, so rotating a key never invalidates past receipts
npm2026-07-30@getstub/agent 0.2.2, key rotation without losing your operator id or your history
npm2026-07-30disclosure kinds now cover structural influence: engagement weighting, source primacy, access and language scope
core2026-07-27six recipes complete, 118 tests, all runnable offline
core2026-07-27recipe outside commerce: insurance advice, where the cheapest policy ranks last
core2026-07-27recipes for the vercel ai sdk and langchain in python
web2026-07-27quickstart now shows javascript or python, your pick
pypi2026-07-27python client published, getstub 0.1.0, signatures verify across both languages
web2026-07-26recipes: reference integrations for the stacks builders use
core2026-07-26stub over mcp: a public check server, and the operator issuing pattern
core2026-07-26second recipe, raw tool-use loop, 22 tests
core2026-07-26first recipe, agentic commerce protocol, 17 tests
web2026-07-25site copy pass, terms overlay, favicon and share image
api2026-07-24directory readable in a browser, favicon on every registry page
api2026-07-24money reads as money on receipts
core2026-07-24example data reseeded under the privacy model
sec2026-07-22principals must be salted hashes, raw identifiers rejected
npm2026-07-22@getstub/agent 0.1.2, influence helpers, disclosures pass through from ranking code
core2026-07-22structured disclosures, rendered with their kind on receipts
core2026-07-22mandate required at registration
npm2026-07-21published @getstub/agent
api2026-07-21api.getstub.dev live
web2026-07-20this site reads from the live registry
sec2026-07-20security review, fixes shipped with regression tests
api2026-07-20hosted registry live
core2026-07-18schema v0.1
core2026-07-18issue, check, resolve working end to end
Contact

Talk to us.

A question, an integration you are planning, something broken, or you want to be one of the first ten. Write to us and you will get a reply from a person.

hello@getstub.dev

Design partner conversations, integration questions, or anything we can improve or add to our roadmap. We read everything.