We need to shift building web apps toward supporting AI Agents first.
Today I listened to a talk on a shift so fundamental it should be keeping every product manager and founder up at night: the web is transitioning from Business-to-Human (B2H) to Business-to-Agent (B2A). For thirty years, we have optimized our products for emotional, human browsing habits. We sweated over landing page copy, A/B tested our call-to-action button colors, and measured success in time-on-site and scroll depth. That entire playbook is being made obsolete. The primary user of the internet is no longer a person sitting at a screen. It is an AI agent executing tasks on that person’s behalf.
The implications are enormous. And most product teams are not ready.
The Principal-Operator Framework
One of the most clarifying ideas from this talk was the Principal-Operator Framework. When someone interacts with a business in the emerging B2A world, there are two interconnected stakeholders acting as one customer.
· The Principal is the human who desires an outcome: a booked flight, a filed expense report, a negotiated vendor contract.
· The Operator is the AI agent delegated to achieve that outcome, under strict constraints of speed, token efficiency, and determinism.
This distinction matters enormously for how we design products. The Principal still needs emotional reassurance, receipts, and a psychological safety net. The Operator needs none of that. It needs clean endpoints, structured data, and fast, predictable responses. Building for one without accommodating the other means you will fail both.
Most products today are built entirely for the Principal (the human user). The Operator is an afterthought, if it is considered at all. That is the gap we need to close.
The Interface Spectrum: From Fragile to Robust
The way that AI Agents actually interact with software today is deeply inefficient. Agentic browsing, where an AI navigates a webpage visually by taking screenshots and parsing the DOM, is the current default. It is also the worst possible approach. The agent has to spend enormous amounts of compute power just to understand what a human would grasp in seconds. Every screenshot is wasted tokens.
Instead, imagine if the website being scrapped with screenshots offered a way for AI Agents to understand and index its content in a faster and more AI-friendly way. That’s the Business-to-Agent (B2A) future.
This future belongs to structural interfaces, arranged roughly in order of agent-readiness:
APIs: Contract-like endpoints that expose product functionality directly to calling systems, bypassing any visual layer entirely.
CLIs: Downloadable, interactive program menus running locally or on servers. When an agent pulls down a CLI, it gets the full menu of available commands in one shot and can chain them instantly without re-querying the system.
MCPs: Model Context Protocol wrappers built for agent discovery and streamlined OAuth authorization. Easy to configure, increasingly popular, but more token-hungry than most people realize.
The Contrarian Take on MCPs
MCPs are everywhere in the AI discourse right now. Every developer tool, every platform, every startup is rushing to build one. The presenter acknowledged their appeal: easy setup, smooth authorization flows, good discoverability. Then he threw cold water on the hype.
MCPs are context-hungry by design. Every time an agent invokes an MCP, it has to load the full menu of available tools into its prompt context. In complex workflows, that overhead compounds rapidly. The agent is constantly asking “what can you do?” before it can do anything.
For raw, high-performance execution, CLIs and APIs win decisively. A CLI downloads the entire capability set to the agent’s local environment once, and the agent can then target any command instantly without burning additional context.
The lesson is not that MCPs are bad. They serve a real purpose for discoverability and ease of integration. The lesson is that hype and engineering reality are two different things, and product managers need to understand the tradeoffs before making architectural decisions based on what is trending on LinkedIn.
The Growth of B2A and the Agent Lane
A shift is already happening: we all grew up with Google searches but today, my preferred way of finding an answer is no longer Google: it’s an AI. I type a question in the browser bar and I expect Gemini to give me an answer. When, instead, the Google search algorithm UI kicks in, most of the time it annoys me. “Where is my AI answer?”
There exist a possible future when users are going to stop logging into our carefully designed user interfaces. The SaaS dashboard we spent months perfecting, the onboarding flow we iterated on for a year: AI Agents do not care about any of it. They want clean endpoints and structured data. Our interfaces are obstacles, not assets.
“We are over the human era. Humans are just now one user and soon not going to be the primary user. Every business has to go through this ego death.”
Companies like Salesforce, Stripe, and American Express are already navigating this. Salesforce is building headless Agentforce infrastructure so agents can trigger Apex classes and Flows directly without touching the CRM UI. Stripe has evolved its one-click wallet into a machine-readable token credential store. American Express has launched a developer kit with cryptographic intent contracts and single-use payment tokens so agents can transact without exposing raw card numbers. These are not feature updates. They are architectural pivots away from the human interface as the primary product surface.
For product teams navigating this, there are two paths forward:
Build an Agent Lane: If you have an existing product, you do not have to tear it down. You can build an agent-accessible layer on top of current functionality. More of this comes down to software hygiene than most teams expect: clean code, properly labeled DOM elements, structured endpoints, and thorough API documentation. If an agent can pull down a list of 100 available commands and execute step 77 without human intervention, your Agent Lane is working.
Go Headless First: If you are building from scratch, the human UI should be secondary. Your APIs, CLIs, and structured data interaction mechanisms are your core product. The visual layer is a convenience layer built on top, not the foundation.
The Assumption Worth Examining: Trust and Authorization at Scale
There is a critical assumption running underneath the entire B2A framework that deserves more scrutiny than it typically receives: the idea that humans will actually delegate high-stakes decisions to AI Agents with sufficient consistency to make this architecture matter.
The technical case for B2A is compelling. The behavioral case is less settled. Financial transactions, travel bookings, healthcare decisions: these are domains where trust is built slowly and broken quickly. American Express is betting on cryptographic intent contracts and insurance products to close this gap, and that is the right instinct. But the trust infrastructure required for mass adoption of autonomous agents in high-stakes domains does not yet exist at scale.
Product managers building for the B2A world should design with this in mind. The Principal still needs visibility, override capability, and confidence that the agent is acting within sanctioned boundaries. Products that ignore the human trust layer in pursuit of pure agent efficiency will hit a wall. The goal is not to eliminate the Principal from the loop. It is to make their involvement frictionless and their control legible.
Slack as an output surface for Salesforce’s multi-agent workflows is a good example of getting this right. Agents execute autonomously in the background, but when a decision crosses a threshold requiring human judgment, the system surfaces a structured summary and an approval button in the channel where humans already work. The agent does the work. The Principal stays informed. That balance is the template.
What to Do This Week
The B2A shift will not happen overnight in every industry, but it is already happening in enough sectors that waiting is a losing strategy. Time-on-site as a productivity metric is being replaced by API latency. Engagement rate is being replaced by agent completion rate. The products that will thrive in this environment will be the ones that are easiest for AI Agents to work with, not the ones with the most polished interfaces.
Audit your product’s agent-readiness today. Do you have a public API? Is it well-documented with self-describing specifications? Are your DOM elements properly labeled for programmatic access? Do you have a plan for how an agent would authenticate, authorize, and transact on your platform without human hand-holding?
These are the product questions of the next decade. The teams that can answer them will be the ones still standing.
Case Study: How Salesforce Is Surviving Its Ego Death
Salesforce is one of the most instructive examples of a legacy platform doing this transition right. The company has not simply bolted an AI chatbot onto its CRM and called it a transformation. It has rearchitected its entire software stack under the Agentforce umbrella, treating autonomous digital workers as first-class citizens of the platform rather than a feature layer on top of existing functionality.
The centerpiece of this is the Atlas Reasoning Engine. Rather than relying purely on an LLM to figure out what to do with a broad user goal, Salesforce built a proprietary reasoning loop that sits on top of the LLM. Atlas takes the Principal’s intent, decomposes it into an autonomous sequence of steps, selects the right tool for each step, executes, and self-corrects when something goes wrong. This is the difference between an AI assistant and an AI operator. An assistant waits to be told what to do next. An operator figures it out.
What I find particularly clever is how Salesforce solved the “fragile-web problem” without rebuilding everything from scratch. Agentic browsing can be brittle: an agent that has to log into a UI, click buttons, and parse screens is slow, expensive, and error-prone.
Salesforce bypassed this entirely by exposing its backend to agents through the same mechanisms human developers have used for years: Apex classes, Salesforce Flows, and MuleSoft APIs. If a company already has a workflow to approve a customer discount, the agent does not log into the CRM to click an Approve button. It triggers the underlying Flow directly. Zero re-platforming required. The infrastructure that already existed became the Agent Lane.
Their agent architecture deserves attention too. Rather than building one massive, generalist agent and hoping it handles every scenario, Salesforce structures agents around four components: Role, Instructions, Knowledge, and Actions. Complex tasks get routed through an Agent Network, where a coordinator delegates to highly specialized subagents: a Compliance Review Agent, an Order Management Agent, a Customer Success Agent. Each subagent is narrow and deterministic. The coordinator handles orchestration. This is exactly the kind of modular, composable design that scales.
Finally, the way Salesforce handles the Principal’s need for visibility is worth borrowing directly. Multi-agent workflows execute autonomously in the background via APIs, but when a decision crosses a threshold requiring human authorization, the agent network drops a structured reasoning log, a summary, and an approval button into Slack. The human stays in the loop without slowing down the machine. That is the model: full agent autonomy up to a clearly defined boundary, with a clean handoff to the Principal when that boundary is reached.
Salesforce is a company with twenty-plus years of UI investment. If they can build an Agent Lane on top of that legacy, there is no excuse for teams building new products today to not design for agents from day one.
Case Study: American Express and the Trust Infrastructure Problem
If Salesforce represents the B2A pivot in enterprise workflows, American Express represents it in financial transactions, which is a harder problem. Payments are where the trust barrier is highest. An AI Agent booking a meeting on your behalf is a low-stakes delegation. An AI Agent spending your money is a fundamentally different proposition. Amex has looked at that challenge directly and built infrastructure specifically designed to make autonomous spending trustworthy.
Their ACE Developer Kit (Agentic Commerce Experiences) is the most concrete expression of this. Rather than forcing an agent to parse a payment page visually, ACE exposes payment rails directly through structured APIs. The kit handles three core functions: Agent Registration, which verifies and authenticates the identity of an AI agent before it is permitted to transact; Account Enablement, which allows the human cardholder to securely link their account to a specific agent and set operational guardrails; and Intent Contracts with Single-Use Tokens.
That last one is the most interesting. The human defines what the agent is authorized to purchase: for example, red running shoes under $150. The system generates a cryptographic Proof of Intent Token bound to those exact constraints. When the agent finds the right product, it calls Amex’s API to receive a single-use payment token that expires immediately after the transaction completes. The agent cannot overspend. It cannot go off-script. The Principal’s intent is enforced at the infrastructure level, not just the prompt level.
But Amex went further than just the technical infrastructure. They introduced Agent Purchase Protection: if a registered AI Agent makes a processing mistake or misinterprets policy while acting on behalf of a cardholder, American Express covers the losses. This is significant. It means Amex is not just building the rails for agentic commerce. They are absorbing the risk of machine error to accelerate human trust in machine action. They are positioning themselves as the trust broker of the B2A economy, which is an extraordinarily smart strategic move for a company whose core asset has always been trust.
On the commercial side, Amex acquired Hyper, an agentic AI expense management company, and is integrating it directly into their enterprise platforms. Hyper’s approach flips the traditional expense management model on its head. Instead of employees collecting receipts and manually filing reports after the fact, Hyper’s agents review, categorize, cross-reference company policy, and file expense reports in real time, in the background, via text protocols. No UI required. The human never has to log into anything.
Amex is also contributing to Google’s Agent Payments Protocol (AP2) to help shape global frameworks for machine-to-machine commerce, and researching Zero-Knowledge Proofs so agents can verify financial capability to merchant systems without exposing proprietary budget information. They are not waiting for standards to emerge. They are helping write them.
The Amex story illustrates something the original B2A framing underemphasizes: the technical architecture is necessary but not sufficient. For agents to operate in high-stakes financial domains at scale, someone has to own the trust layer. Amex has decided that someone is them.
Every product team building in the B2A space should ask the same question: who owns the trust layer in your domain, and what does your answer to that question mean for your architecture?
Key Takeaways
1. The web is shifting from B2H to B2A. AI agents are becoming the primary interface between humans and digital products. Products built exclusively for human browsing habits will become invisible to the autonomous economy.
2. Serve both the Principal and the Operator. The human needs trust signals, receipts, and override capability. The agent needs speed, determinism, and clean endpoints. Designing for one at the expense of the other creates a broken experience.
3. CLIs and APIs outperform MCPs for execution efficiency. MCPs offer discoverability and easy setup, but carry significant context overhead in complex workflows. Raw APIs and CLIs remain the benchmark for high-performance agent interaction.
4. Your UI is not your product anymore. Your database logic, workflow orchestration, and API surface are. Companies like Salesforce, Stripe, and Amex are already repositioning their value around headless infrastructure, not visual interfaces.
5. Build your Agent Lane now. Existing products can adapt without full rebuilds. Clean APIs, proper accessibility standards, and thorough documentation are your Agent Lane. New products should treat the human UI as a layer built on top of an agent-first architecture.
6. Trust infrastructure is the unsolved problem. The technical case for B2A is strong. The human trust layer needed for mass adoption in high-stakes domains is still being built. Products that solve for agent efficiency while preserving Principal confidence and control will have a meaningful competitive advantage.
7. Legacy infrastructure is your Agent Lane. Salesforce’s Agentforce approach shows that existing workflows, Apex classes, Flows, and APIs, can be surfaced to agents without rebuilding from scratch. The key is exposing backend logic directly, bypassing the UI layer entirely. Teams do not need to start over. They need to open the right doors.
8. Owning the trust layer is a strategic opportunity. American Express’s ACE kit, Intent Contracts, single-use tokens, and Agent Purchase Protection are not just technical features. They are a bid to become the foundational trust broker of the B2A economy. In every domain where agents will operate at scale, someone will own the trust layer. The companies that move first to define it will have an enduring structural advantage.
Interested in AI training for your team?
I run a suite of AI training programs. Find one that works for you here: