In April 2026, Salesforce announced Headless 360 at TrailblazerDX with the pitch “No browser required.” Every capability in the platform now sits behind an Application Programming Interface (API), a Model Context Protocol (MCP) server or a Command-Line Interface (CLI), so AI agents can use the entire system without using an interface. “Headless” went from engineering jargon to a word leaders are hearing in board meetings.
What does “headless” mean, and does your company need to go there?
If your honest answer is “I have no clue,” you are in good company. Most businesses are still building internal AI agents that don’t yet interact with the outside world. The few external-facing agents that do exist typically live behind a corporate boundary within a product website and require logging in using human credentials. That setup is just step one of the journey to headless. From inside the company’s four walls, “headless” still sounds like a buzzword in search of a problem.
The need for “headless” only shows up at stages two and three, where agents stop being gated by your human-facing website and start talking to your software directly. The graphic below lays out all three stages, and the rest of this post walks through them with one shoe-buying example.
* Image created using Gemini
The Setup: Your company sells running shoes. A human shopper has asked her shopping agent to find the best deal on a pair of trail runners under $150, delivered by Friday. The shopper agent is now standing at your door, ready to do business on her behalf. What happens next depends on which step you are on.
Let’s call this Step Agent-to-UI, or AG2UI.
You have done nothing to accommodate the shopper agent, so the agent does what the human shopper would do. It opens your website, dismisses the cookie banner, navigates the menus, picks a size and tries to check out. If you have ever watched an agent fumble through dropdowns and popups, you know it is painful. A human webpage is foreign territory for an agent.
This is where most companies are. During the shopping process, your site asks for user login or payment authentication, and the shopper agent stalls. The human shopper has to take over and finish the transaction by hand.
In step two, you stop asking the shopper agent to pretend to be a human. This is precisely the problem the Model Context Protocol (MCP) was built to solve. Let’s call this Step Agent-to-MCP, or A2MCP.
MCP provides a structured way for agents to call your tools, query your data and get clean answers back. You publish a menu of available capabilities, like a search_shoes tool, an add_to_cart tool and a checkout tool. Each tool specifies exactly what inputs it requires and what outputs it returns. The agent simply picks the right tool and calls it directly.
If you are familiar with the term “API,” you already understand the human-engineering equivalent. An API is a structured way for software to talk to software instead of clicking through a webpage. Think of MCP as the universal standard for exposing those APIs in a format that AI agents can seamlessly consume.
In our running shoes example, the shopper agent no longer scrapes your webpage. It knows it needs to call search_shoes(size=8, type=”trail”, max_price=150) and get back a clean list. It knows it can now call add_to_cart and checkout directly. Because each call is a structured request rather than a webpage to interpret, the whole transaction runs at machine speed.
Step two is a real upgrade, but it has a quiet limitation. MCP is structured around the shopper agent making a call and your software responding. Your software does not start its own conversation, ask follow-up questions or surface a deal the shopper agent did not think to ask for. It can be smart inside each call, but it does not initiate. It also needs to be set up, it is not automatically discovered and used.
In step three, your software stops being a passive responder and becomes a seller. For example, your agent recognizes the shopper from prior purchases, sees that size eight is low in stock and proactively offers the shopper agent an upgrade to a comparable model with free expedited shipping if the order is placed today. When the shopper agent mentions it is also looking at a competitor, your agent applies a loyalty discount to close the gap. None of those moves come from the shopper agent asking. They come from your side actively trying to win the sale, the same way a good salesperson would on a showroom floor. Let’s call this Step Agent-to-Agent, or A2A.
Stages 2 and 3 are “headless” because they do not force the shopping agent to use a browser.
The progression through these three stages makes the reason clear. Going from step one to step two takes your software from human speed to machine speed, since the shopper agent can now act through structured calls instead of clicking through your webpage. Going from step two to step three lets your software meaningfully compete and leverage a much richer context, instead of acting as a passive lookup that only returns what was asked for.
If you stay on step one, the shopper agent leaves without making a call and picks a competitor that has gone headless. You might not even know about a lost opportunity because there is no abandoned cart to follow up. Your customers will be using agents to shop, you have no other options but to go headless and the only question is when you should start.
Companies starting this headless journey will stay stuck on step one until we collectively solve one important pre-condition: agent identity and trust. Before you let a shopper agent connect with your MCP or your agent, you need to know with certainty that it is not malicious and that it really represents the shopper it claims to. The same is true on the shopper’s side: she wants the best deal, and she also wants to make sure her credit card is not handed to the wrong party. Today, agents answer those questions with static API keys and hardcoded tokens that would horrify any security architect doing the same for human users. That approach cannot scale to agentic commerce, and if you are a less well-known brand, your chance of getting discovered by a shopper agent is close to zero.
The good news is that you already own the infrastructure to fix it. The same Domain Name System (DNS) that tells the world nordstrom.com is really Nordstrom can be extended to your agents. Your inventory agent becomes inventory.agents.yourcompany.com. Your checkout agent becomes checkout.agents.yourcompany.com. You own that namespace the same way you own your storefront, and you can carry it across mobile, web, APIs, MCP, A2A or whatever protocol comes next, with no vendor lock-in and no dependence on where the agent was built or deployed.
This concept is already being turned into reality by emerging standards such as DNS for AI discovery (DNS-AID). DNS-AID names agents and MCPs in a way so they are tied to the domain name of an organization, conveying trust and driving accountability when the agent misbehaves. Adjacent efforts extend security mechanisms such as DNS Security Extension (DNSSEC) to cryptographically prove that an agent really belongs to the domain it claims. OWASP’s Agent Name Service and GoDaddy’s ANS implementation leverages the same domain-based foundation to enhance agent and MCP authentication and trust.
Once the foundation of identity and trust is established, organizations will be able to fully complete their transition to going headless.
Ultimately, moving from human-speed websites (step one) to machine-speed endpoints like MCP (step two) and proactive agent-to-agent negotiations (step three) is a necessary evolution. While verifiable identity and trust remain the gatekeepers to completing this full transition, the shift is inevitable, and businesses must get their infrastructure ready now. By opening these direct doorways and securing them with a domain-based identity, your business remains reachable and competitive when the customer at your door is an AI agent. Organizations that embrace this transition will win the next decade of agentic commerce.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。