When the Customer Is an AI Agent, Not a Human

For thirty years the internet's primary customer has been a human. Someone scrolling, comparing, clicking, sometimes buying. Every piece of software, every landing page, every checkout flow is engineered for that customer. The colour of the button, the words above the fold, the social proof in the sidebar, it's all a persuasion machine pointed at a human nervous system.

That customer is being replaced. Quietly, in the background of every operating firm I look at, the buyer is shifting from a person to an agent acting on behalf of a person.

Most operators have not registered what this means yet. They're still optimising the human funnel while a second funnel is forming alongside it, with different rules, different signals, and a different definition of trust. The firms that build for both will compound. The firms that only build for the first one will quietly disappear from the consideration set when an agent goes shopping on behalf of its principal.

What actually changes when the customer is an agent

A human customer wants persuasion. An agent customer wants structured capability, permission, and trust.

That sentence does more work than it looks like it does. Almost every choice your firm has made about its public surface, the homepage video, the testimonial carousel, the gated pricing page, the "talk to sales" button, exists because a human needed to be moved emotionally before they would act. None of that applies to an agent.

An agent doing procurement on behalf of a CFO is not going to be charmed by your brand video. It's going to read your docs, parse your pricing, check your policies, look for an executable endpoint, and decide whether it can transact with you safely on behalf of its principal. If the answer is no, it moves on. There's no second visit. No retargeting ad brings it back.

The buying journey itself splits cleanly. An agent finds, evaluates, checks trust, transacts, uses, and recommends. The last step is the one most operators have not thought about: agents will recommend tools to other agents. The reputation graph of the agent internet is being built right now, and most firms do not know they are being scored on it.

The agent is not a feature on the human web. It is a different web.

This is the framing that unlocks the strategic decision. Two internets are forming. The human internet, which still matters and will continue to matter for brand, for emotion, for the parts of commerce that are inherently social. And the agent internet, a parallel surface where machines transact with machines on behalf of principals.

A human-readable homepage has a hero, a video, a value prop, social proof, a demo, and pricing tiers. An agent-readable homepage has structured documentation, schemas, policy statements, endpoint definitions, MCP tools, SDKs, OAuth flows, checkout primitives, a sandbox, and receipts. Same firm. Two completely different surfaces. Neither one is optional.

The firms I see getting this right are already building a dedicated entry point, a /agents path that exposes the capability manifest, the tool definitions, the permission scopes, and the audit-trail format. That's not a marketing decision. It's an architecture decision. And the firms making it now are quietly being added to the consideration set when an agent does a procurement run for the first time.

The ones that aren't making it are invisible. Not penalised, not deranked. Invisible. The agent cannot see them, so the agent cannot recommend them, so the agent's principal never hears about them.

What agents need that humans never did

The list looks mundane until you sit with what each item implies.

Identity. Who is the agent acting for? What authority does it have? What can it commit to in the principal's name? This is not a login field. It's a verifiable claim that survives across multiple counterparties and gets checked by every system the agent touches.

Tools. What actions can the agent safely invoke? Not "what does your API allow", but what does your firm's policy layer permit this specific agent to do, given who it is acting for and what budget it carries?

Inbox. Where do the OTPs land? Where do the contracts go? Where does the agent receive the threaded back-and-forth with your support team? AgentMail is building this as standalone infrastructure for exactly the reason Gmail exists for humans.

Memory. What does the agent know about the principal's preferences, the firm's rules, the historical decisions that should constrain the current one?

Wallet. What can the agent spend? Who approves it? Stripe is already shipping primitives here. There will be ten more before this time next year.

Receipts. What did the agent see, decide, change, buy, and on what authority? The audit trail is not a nice-to-have. It's the substrate that makes the entire agent economy legally and operationally defensible.

Each of those items is a SaaS category waiting to be rebuilt from the ground up for a machine principal. And each of them, on the buyer's side, is a new operating requirement your firm has not yet provisioned.

The question most operators are missing (and most firms have yet to provide an answer to)

The temptation is to treat this as a marketing problem. SEO becomes AEO. Landing pages become capability manifests. Sales calls become agent procurement runs. Improve the new funnel, hire someone who understands MCP, ship a docs page, move on.

That framing is wrong, and it's wrong in a way that will cost firms real money. The agent internet is not a new marketing channel. It's a new operating surface that requires its own data layer, its own permission model, its own audit trail, and its own governance line.

This is operating-grade work. It does not get solved by the marketing team writing better metadata. It gets solved by the executive team deciding that the firm's data, tools, policies, and identity model need to be exposed to a machine principal in a form that machine can read, verify, and act on without leaking the firm's IP or violating its compliance posture.

The firms I work with at HIP that are already feeling this pressure are running into a recognisable pattern. Data scattered across SaaS instances nobody owns. Policies that exist in PDFs nobody can parse. Permission models that live in someone's head. Audit trails that exist in retrospect, if at all. When you try to expose that surface to an agent, the agent cannot operate on it. This is the missing-secure-data-layer failure mode, F2 in HIP's positioning shorthand, at the firm-architecture level. Solving it means placing throughput and data sovereignty on the same page: every endpoint an agent can call has to be governed, attributable, and defensible the moment it is invoked.

What the operating decision actually looks like

A firm that decides to be a real participant in the agent internet has to make six decisions, and each of them lives in a different part of the org.

One. What data is exposed to agents, in what form, under what permission scopes. That's a CTO and General Counsel decision, made jointly, with the CEO's authority behind it.

Two. What actions can an agent invoke, against what spend limits, with what approval rules. That's a CFO decision, and it looks a lot like onboarding an employee. You give limited authority first, you watch the audit trail, you raise the ceiling as trust accrues.

Three. What identity claims does the firm accept from agents, and how are they verified. That's a CISO decision, and getting it wrong is how a firm ends up paying a counterparty's invoice that no human ever authorised.

Four. What audit trail does the firm keep, in what format, retained for how long. That's a compliance decision, and the answer needs to survive a regulator inquiry, an LP DDQ, or a board audit committee question.

Five. What public surface, the /agents path, the capability manifest, the sandbox, does the firm publish, and who maintains it. That's a product decision, and it is the only one of the six that looks like a marketing problem from the outside.

Six. What governance line sits over all of it, so that as the firm extends more capability to more agents, the data surface and the exposure surface do not widen faster than the firm can defend them.

Those six decisions are exactly the shape of an AI Operating Audit. The firm that has answered them is in the consideration set when an agent comes shopping. The firm that has not is still optimising its human funnel while the second funnel routes around it.

What this looks like from a Kill, Fix, Build seat

When I walk an executive team through what their AI estate actually looks like, the agent internet question shows up as a Build column nobody had written down. They had been thinking about AI as something their employees use. They had not been thinking about AI as something their customers' agents will use against their public surface, on the customers' behalf, to decide whether to do business with them.

Once the framing flips, the prioritisation changes. The first move is rarely a /agents page. It's usually a cleanup of the data, policy, and permission substrate that the /agents page would expose. Build the page on top of an ungoverned surface and the surface is what gets exposed, not the page.

The work splits into what to Kill (the Shadow AI tools and zombie pilots that are creating an exposure surface nobody is governing), what to Fix (the data, policy, and identity layers that need to be operating-grade before any agent touches them), and what to Build (the agent-facing surface itself, once the substrate underneath it is defensible). Order matters. They decide what to Kill, Fix, and Build. The firms that try to Build first end up Killing the Build six months later when the substrate underneath it cannot carry the load.

Where this goes

The prediction worth taking seriously is the bifurcation. Two internets. The human internet, still important, still where brand and emotion and discovery live. The agent internet, parallel, machine-readable, transactional, and growing fast enough that ignoring it is a five-year mistake operators are making today.

Every SaaS category that exists today has an agent-native version forming. Payments, communication, memory, identity, support, procurement, analytics. The firms building those primitives are the next generation of infrastructure businesses, and they will be large.

For the operator reading this, the CEO, the COO, the General Counsel, the question is not whether to build a startup in this space. The question is whether your firm is operating-grade enough that, when an agent representing a real customer with a real budget arrives at your public surface in the next eighteen months, it can read you, verify you, transact with you, and recommend you to the next agent that asks.

If the answer is no, the work to fix it is not a marketing project. It's an operating one. And it's the kind of work that compounds. Every quarter your substrate gets cleaner, every agent that interacts with it adds to your reputation graph, and the firms that started this work in 2025 will be the ones inside the consideration set in 2028 while their competitors are still optimising their hero videos.

That's the move worth making this quarter. If your firm is anywhere near the size where this matters, $10M to $100M in revenue, an executive team that owns the P&L, a customer base that is starting to send agents, the right next step is to commission an AI Operating Audit and find out where your substrate actually stands. The agent internet is not waiting for the firms that are not ready. It's just routing around them.