The Agent Economy Breaks at the Boundaries

Most conversations about the agent economy start with the agent.

What can it do? Which tools can it call? Can it shop, schedule, compare, negotiate, book, cancel, return, refund, file, submit, and generally attack the internet’s backlog of tiny chores?

Great questions.

Also incomplete.

Because the moment an agent shows up at a business and asks to do something real, the interesting question moves to the boundary.

Who is this agent?
Who is it acting for?
What is it allowed to do?
What is this business willing to allow?
What changes if the request succeeds?
What happens if the response disappears?
Where is the receipt?

That is where the agent economy gets less shiny and more useful.

It is also where I want Agent Native to go next.

TL;DR for a 10-Year-Old

Imagine you ask a robot helper to buy a birthday gift.

The store should not just say, “Sure, robot, take the money.”

It should check:

Is this really your helper?
Did you say it could buy something?
How much is it allowed to spend?
Does it need to ask you before paying?
Is it buying one gift or accidentally buying eight?
Can it show everyone what happened afterward?

That is the point of Agent Native.

It is not trying to let agents do whatever they want. It is trying to help businesses set rules for agents, let them do useful work, and keep proof when something important happens.

flowchart LR
    H[Human] --> A[Agent helper]
    A --> B{Business checks}
    B -->|Not allowed| N[No]
    B -->|Needs approval| C[Ask the human]
    B -->|Allowed| D[Do the action]
    C --> D
    D --> R[Receipt]

The First Version Was About Readiness

The first version of Agent Native asked a simple question:

Can an AI agent actually do business with you?

That became a passive scanner.

It looks at a public URL or local artifact and asks whether an agent can discover a machine-readable interface, understand the available capabilities, identify authentication and authorization requirements, distinguish reads from actions, find recovery signals, and preserve evidence.

Passive matters.

No login. No checkout. No form submission. No “we bought three test sofas to inspect your idempotency posture.” The internet has enough exciting failure modes already.

That first version is useful because many businesses are technically online but not legible to delegated software. They have pages humans can read and APIs developers can call, but they do not clearly explain what an outside agent can discover, request, or safely do.

The next question is larger:

What should happen when the agent wants to act?

That is not just a better scanner.

That is a business-side control problem.

Websites, APIs, and Agents Are Different Interfaces

The web already has several interface shapes.

People use websites.

Apps and services use APIs.

Agents sit awkwardly in between. They are software, but they are often acting for a person or organization in a dynamic way.

flowchart TD
    H[Human] --> W[Website]
    S[Software system] --> API[API]

    H2[Human] --> A[Delegated agent]
    A --> C[Business capability]
    C --> O[Outcome]
    O --> E[Evidence back to human]

That last line matters.

If I click a checkout button myself, the business can infer a lot from the interaction. I was logged in. I saw the price. I pressed the button. I got the confirmation.

If an agent acts for me, the business needs a more explicit contract.

It needs to know what the agent is, who it represents, what was delegated, what policy allows, what changed, and what evidence survives afterward.

“The API returned 200” is not enough.

Which is tragic, because 200 is such a tidy little number.

Protocols Help. They Do Not Replace Control.

The ecosystem is moving in the right direction.

MCP helps agents interact with tools and resources. A2A helps agents discover and coordinate with other agents. Commerce protocols are emerging too, including OpenAI’s Agentic Commerce Protocol, Shopify and Google’s Universal Commerce Protocol, Stripe’s Machine Payments Protocol, and Visa’s Trusted Agent Protocol.

Good.

But protocols mostly answer:

How do these systems communicate?

The business still has to answer:

Should this agent be allowed to do this thing,
for this person,
under this authority,
against this resource,
at this value,
right now?

That is the layer I care about.

Not “can an agent call something?”

Should the business allow it, and can the outcome be proven?

Agent Native Should Become a Participation Layer

I do not mean “agent native” as “every business needs to build a chatbot.”

Please, no. The world has enough chat windows quietly failing to answer pricing questions.

I mean something more specific:

An agent-native business exposes enough structured capability, authority, policy, recovery, and evidence information for agents to participate safely.

That word, participate, is doing a lot of work.

Different agents should get different access.

An unknown agent might be allowed to read public product information.

A verified consumer agent might be allowed to check availability or create a cart.

A partner agent might be allowed to start a return.

A company-owned agent might be allowed to do more, inside company controls.

That is not one readiness score. It is a participation policy.

Capability	Unknown Agent	Verified Consumer Agent	Partner Agent	Internal Agent
Search public catalog	Allow	Allow	Allow	Allow
Check availability	Limited	Allow	Allow	Allow
Get personal pricing	Deny	Scoped	Scoped	Allow
Create cart	Deny	Allow	Allow	Allow
Purchase	Deny	Human approval	Limited	Company policy
Refund	Deny	Human approval	Limited	Company policy
Access customer data	Deny	Scoped	Scoped	Scoped

This turns the question from:

Are we agent ready?

into:

How do we want agents to participate in our business?

That is a product question, a security question, an architecture question, and a strategy question. Naturally, it refuses to fit neatly into one department.

Identity Is Not Authority

This is the easiest mistake to make.

Suppose an incoming request is genuinely from a known agent provider.

Great.

We know who sent it.

We still do not know:

who the agent is acting for,
what that person authorized,
whether the authorization is still valid,
whether the requested action matches the grant,
whether the business permits that action,
whether the value, timing, and resource are inside policy.

The dangerous shortcut is:

trusted_agent = true

Very convenient.

Also how future incident reviews get their first paragraph.

The control chain should look more like this:

flowchart TD
    A[Incoming agent request] --> B{Agent recognized?}
    B -->|No| C[Unknown-agent policy]
    B -->|Yes| D{Acting for whom?}
    D --> E{Delegation valid?}
    E -->|No| X[Deny]
    E -->|Yes| F{Capability allowed?}
    F -->|No| X
    F -->|Yes| G{Business policy}
    G -->|Deny| X
    G -->|Needs human| H[Ask for approval]
    G -->|Allow with limits| I[Controlled action]
    H --> I
    I --> R[Receipt + trace]

Identity gets you into the conversation.

Authority decides what can happen next.

The Transaction Boundary Is Where Things Get Real

Discovery is forgiving.

If an agent misunderstands a product page, that is annoying.

If it misunderstands a purchase, cancellation, payment, claim, booking, or transfer, the mood changes quickly.

Consider the clean version:

sequenceDiagram
    participant H as Human
    participant A as Agent
    participant B as Business

    H->>A: Buy this if total is under $100
    A->>B: Request quote
    B-->>A: $82, quote Q123
    A->>H: Approve $82?
    H-->>A: Yes
    A->>B: Commit quote Q123
    B-->>A: Order created

Now make it normal software:

sequenceDiagram
    participant A as Agent
    participant B as Business

    A->>B: Commit order with key K1
    B->>B: Order created
    B--xA: Response times out
    A->>B: Retry with key K1

Did the retry create a second order?

Did it return the first result?

Was the quote still valid?

Did the human approve the final price or only the earlier one?

Can the business prove what happened?

This is why idempotency, quote expiration, confirmation binding, cancellation, compensation, and receipts are not edge-case polish.

They are the contract around delegated action.

The hard part is rarely the POST.

The hard part is everything that makes the POST safe enough to allow.

Receipts Matter More When Humans Do Less Direct Clicking

When a human clicks through a workflow, the interface itself becomes part of the evidence.

When an agent acts for a human, evidence needs to become more explicit.

Not just:

success: true

More like:

receipt_id: rcp_123
agent_id: agent_xyz
principal: user_abc
capability: purchase
delegation: grant_789
policy_version: 14
confirmation: confirm_456
quote: quote_123
value: 82.00
currency: USD
result: SUCCEEDED
trace_id: trace_999

The exact schema will evolve. The principle is the important part:

Consequential agent action should leave durable evidence.

A trace explains how the system got there.

A receipt explains what the system says happened.

Those two should agree.

What Agent Native Is Trying To Become

Agent Native started as a readiness scanner.

I want it to grow toward a business-side control layer for agent participation.

The shape in my head looks like this:

flowchart TD
    A[External agents] --> B[Agent Native layer]

    B --> C[Discovery]
    C --> D[Capability graph]
    D --> E[Agent identity]
    E --> F[Delegated authority]
    F --> G[Participation policy]
    G --> H[Simulation or preview]
    H --> I[Controlled execution]
    I --> J[Receipt]
    I --> K[Trace]
    I --> L[Recovery path]

    I --> M[Business systems]

The important part is that Agent Native should sit on the business side of the relationship.

Not as another model runtime.

Not as another shopping agent.

Not as another tool-calling framework wearing a new hat.

As the layer that helps a business decide what agents can do and what proof should exist afterward.

Sector Packs Make Sense, But Later

Retail, healthcare administration, local services, travel, banking, and professional services will not all expose the same capabilities.

Retail cares about pricing, inventory, carts, payments, shipping, returns, and refunds.

Healthcare administration cares about identity, consent, minimum necessary access, appointment workflows, records requests, billing, and human boundaries.

Local businesses care about simplicity, platform integration, owner controls, human handoff, and not needing a staff engineer to accept a Tuesday appointment request.

The horizontal control questions stay the same:

Who is the agent?
Who is it acting for?
What was delegated?
What does the business allow?
What changes if we proceed?
Can it be retried safely?
Can it be undone?
Can we prove what happened?

The sector-specific packs should define the capabilities, policies, workflows, and failure modes that sit on top.

One control architecture.

Many business contexts.

Otherwise this becomes a museum of if industry == ... statements, and nobody needs that tour.

What This Is Not

Agent Native gets weaker if it tries to be everything.

It should not be:

another general-purpose agent framework,
another payment processor,
another identity provider,
another API gateway,
another marketplace,
a fake AI safety certification,
a single magic readiness score.

The useful goal is narrower:

Make the boundary between agent intent and business action explicit, testable, controllable, and reviewable.

That is already difficult enough.

Why This Matters

The agent economy will not become real just because models become better at clicking buttons.

Models can be brilliant and still run into businesses that cannot answer basic questions about delegated action.

An agent might know exactly how to buy a product.

That does not mean the merchant knows:

whether the agent is legitimate,
whether the customer authorized it,
whether the request is inside the delegated limit,
whether the transaction is retry-safe,
whether the price changed after approval,
whether a human should step in,
whether the final result can be reviewed.

That infrastructure has to exist somewhere.

I think the business needs its own side of the contract.

Not a terms-of-service page.

Not a chatbot.

Not a shiny badge that says “AI ready” because a vendor needed a pricing tier.

A real technical contract:

Who are you?
Who sent you?
What are you allowed to do?
What am I willing to let you do?
What changed?
Can it be undone?
Where is the receipt?

That is the internet I want Agent Native to help build.

Preferably before someone’s agent orders twelve sofas because the first eleven requests timed out.

Explore Agent Native on GitHub Read the first Agent Native essay