We are moving from a world in which people operate software step by step to one in which people state goals and agents enter existing systems to carry them out. This essay proposes A2B, Agent-to-Business, as a working concept for naming that emerging relationship.
When a team says, "We want to connect AI to our existing business systems," the sentence can mean almost anything.
A product manager may imagine a conversational interface. An AI team may think about models, retrieval, and context. A developer may think about function calling, an MCP server, or internal APIs. A security team may think about identity, authorization, and audit. The business owner may simply expect the system to read orders, update inventory, create tickets, process refunds, or reschedule appointments.
None of these interpretations is wrong. Each describes one part of the same change.
What remains difficult to say in one sentence is this:
An agent receives a goal from a person or an organization, enters a business system that already exists, reads business facts, selects an operational path, and completes work that once required a person to understand an interface and act through it.
If every serious conversation must repeat that entire paragraph, the problem may not be only a missing technical solution. We may also be missing a category.
We already use short terms such as B2B, B2C, and B2B2C to compress complex market relationships. We can use A2A to discuss collaboration between agents. But when we try to describe agents entering existing software and producing real business outcomes, we fall back on loose phrases: AI integration, tool use, LLM calling APIs, enterprise automation, MCP adoption, an AI assistant for operations.
Each phrase touches the phenomenon. None identifies it completely.
This essay calls it A2B: Agent-to-Business.
A2B is not presented here as an established industry standard, a protocol, or a product category that everyone has already agreed to use. It is a working concept: a name for situations in which an agent acts under delegation, crosses into an existing business system, invokes real operational capabilities, and produces outcomes for which people or organizations remain accountable.
The purpose of naming the relationship is not to add another acronym to an already crowded field. It is to make a recurring but fragmented problem visible enough to examine as a whole.
Categories are infrastructure for collective thoughtå
Technical communities often treat language as packaging applied after the real engineering is finished. In practice, stable categories are part of the infrastructure through which engineering knowledge accumulates.
Without a shared name, a problem can exist only inside individual projects. A commerce team calls it an AI refund assistant. A CRM team calls it an autonomous sales operator. An HR team calls it an employee service agent. An operations team calls it automated incident handling.
These teams may be confronting the same architectural questions without recognizing that they are working on the same class of system:
- How does the agent learn which business capabilities exist?
- Is it offering advice, preparing a draft, or taking an official action?
- Whose identity is represented when it acts?
- Why did a natural-language goal become this particular sequence of operations?
- Which consequences may be produced automatically, and which must return to a person?
- If the result is wrong, can the organization reconstruct the chain of responsibility?
When these questions remain "integration details," every organization has to rediscover them. The knowledge stays trapped in product-specific configurations, internal prompts, gateway rules, and incident reports.
A useful category changes that. It lets product managers, developers, architects, security teams, and business owners see that they are not merely adding an AI feature. They are designing a new relationship between intention, software, action, and responsibility.
A durable category should have at least three properties:
- Compression. It should reduce many recurring situations to a short concept without discarding their essential structure.
- Distinction. It should clarify what belongs to the category, what does not, and how it differs from adjacent concepts.
- Generativity. It should help us ask questions that were previously difficult to formulate and derive claims that practice can test.
The value of A2B therefore does not depend on whether the acronym becomes fashionable. The more serious test is whether it can reveal a common structure across commerce, CRM, healthcare, public services, AI operating systems, robotics, and multi-agent systems; whether it can distinguish that structure from chat, content generation, fixed automation, and pure agent-to-agent coordination; and whether it helps us anticipate how software and organizational responsibility may change.
If it cannot do those things, it is only a label. If it can, it becomes a cognitive tool.
The important change is not that AI can call an API
At first glance, A2B may sound like a new term for "an LLM calling an API." That would be too shallow.
Software has called software for decades. Workflow engines, scripts, RPA systems, schedulers, and integration platforms already update orders, synchronize inventory, send notifications, and trigger approvals.
Nor did machines begin making consequential decisions with modern agents. Algorithmic trading, fraud detection, industrial control, recommendation systems, and autonomous vehicles have long selected actions from data.
What agents change is not the existence of machine action. They change its generality, openness, and accessibility.
Earlier automated decision systems usually operated inside domains whose inputs, objectives, state spaces, and available actions had been carefully modeled in advance. A specialized team defined the path before the system ran.
A general-purpose agent can instead receive a goal that was never encoded as a complete procedure, discover or select from heterogeneous tools, construct arguments, inspect intermediate results, and revise its next step.
Traditional automation often begins with an execution path:
developers predefine the condition
-> workflow designers arrange the steps
-> parameters come from deterministic mappings
-> the program executes the known procedure
An agent may begin with only an intended outcome:
a person states a goal
-> the agent interprets the goal
-> the agent selects capabilities
-> the agent constructs arguments and an action order
-> the agent observes intermediate results
-> the agent decides what to do next
-> the business system produces an official result
Both chains may use the same API. They do not have the same action structure.
The first mainly delegates execution. The second delegates part of the translation from intention to operational path.
This does not mean an agent possesses human will, moral agency, or legal personhood. It remains software deployed by people and organizations. Responsibility cannot be transferred to a model merely because the model participated in reasoning.
But an important engineering fact has changed: a non-human component now participates in deciding how a goal becomes an operation.
When AI mainly generates answers, evaluation centers on epistemic quality: Is the output accurate, relevant, grounded, or biased?
When an agent enters a business system, another dimension appears: Is the action legitimate? Was it authorized? Did it remain faithful to the original delegation? Could it have been stopped or reversed? Who is accountable for the outcome?
An answer can be factually correct and still lead to an action that should never occur. A parameter can satisfy every schema rule and still be illegitimate because the acting subject, current business state, or authority is wrong.
A2B marks the boundary at which AI output becomes institutional action.
From human-operated software to agent-operated software
Most of the history of software interfaces has been about improving how people operate machines.
Command lines required people to learn machine-oriented languages. Graphical interfaces organized operations into windows, forms, menus, and buttons. Mobile computing made those interfaces continuously available. Natural language reduced the effort required to express intent.
These interfaces will coexist for a long time. But agents introduce a change in direction:
The direct operator of software is expanding from humans to agents.
The familiar business path looks like this:
a person understands the business goal
-> logs into a system
-> finds the correct function
-> enters parameters
-> submits the operation
-> the system validates and executes it
The emerging path may look like this:
a person expresses the business goal
-> an agent interprets it
-> the agent selects a business capability
-> the agent constructs operational arguments
-> the system validates and executes
-> the agent continues from the result
This is more than replacing clicks with tool calls.
Historically, a business system exposed functions to people through pages, menus, and buttons. Increasingly, it will also need to expose functions to agents through structured capabilities, machine-readable semantics, and reliable execution feedback.
Conversation is only the human entry point. The decisive change happens after the conversation: how a goal enters a business process, how it becomes an action, and how the result returns to the sphere of human responsibility.
What A2B describes
A2B can be understood at three levels.
The plain-language definition is:
People used to open software and perform the steps themselves. A2B describes a person stating a goal and an agent entering existing business systems to get the work done.
The engineering definition is:
A2B describes situations in which an agent, acting under human or organizational delegation, uses capabilities provided by existing business systems to read business facts, organize operations, and produce traceable business outcomes.
The structural definition is:
A2B is a relationship in which an agent crosses a software, organizational, or trust boundary and participates in a real business process.
The shared structure can be compressed into three elements:
A2B = semantic delegation + boundary crossing + institutional consequence
Semantic delegation
The person or organization supplies a goal rather than a complete sequence of steps. The agent participates in translating that goal into capabilities, arguments, and an order of action.
Boundary crossing
The action moves from the agent's environment into another system with its own identities, data, policies, and responsibilities. That boundary may surround an application, an enterprise, a public institution, or an external trust domain.
Institutional consequence
The result is not merely model output. It becomes a fact recognized by an organization: a refund was created, an employee record was changed, an appointment was cancelled, an application was submitted, inventory was deducted, or a work order was closed.
Institutional consequence is not limited to writes. Reading a private order, medical record, account, or employee file changes who possesses protected information and creates duties of confidentiality, use, and traceability. A2B consequences include both changes to business state and access to constrained business facts.
These elements are descriptive, not prescriptive. Naming A2B does not require every deployment to adopt the same protocol, identity format, approval workflow, or governance model. It first tells us what kind of relationship is forming. Different organizations can then decide how that relationship should be governed.
"Business" does not mean commerce alone
The word Business in A2B should be read broadly as business systems and institutional processes, not only as for-profit commerce.
The relevant systems include ERP, CRM, HR, finance, support, production, healthcare, education, government, and public-service systems. Their shared characteristic is that they maintain real states recognized by an organization: whether an order was refunded, an employee is active, inventory was allocated, a medical request was updated, a permit was approved, or a case was closed.
A modern business system is not merely a database that stores passive information. It is an executable carrier of institutional rules.
Permissions, workflows, obligations, and responsibilities are encoded in accounts, roles, state machines, approvals, records, and business logic. A changed database row may be a technical event. When that row means "the refund exists," "the employee has left," "the contract is active," or "the treatment was approved," it is also an institutional fact.
An agent entering such a system is therefore doing more than crossing an API boundary. It is moving from computational space into institutional space. Model-generated arguments, after validation and execution, become states that affect resources, rights, obligations, and accountability.
That is why this relationship deserves to be identified separately. A2B sits between what a machine computes and what an organization recognizes as having happened.
What is not A2B
A category only becomes useful when it can exclude things.
Ordinary content generation is not usually A2B. Asking a model to write an article, create an image, or rewrite copy may produce valuable output, but the model has not thereby entered an existing business process.
Answering public knowledge questions is not a typical A2B action. The activity remains primarily in the information domain.
Model training, inference services, and vector retrieval are not themselves A2B. They may support an A2B system, but they do not constitute the relationship.
Pure A2A collaboration is not automatically A2B. Agents can exchange tasks, capabilities, and intermediate results without entering a system that maintains official business state.
Traditional automation overlaps with A2B but is not identical to it. A script that executes a fixed path is better described as automation. The more a system receives open-ended goals, chooses capabilities, constructs arguments, and adapts its path, the more clearly it displays the agent characteristics relevant to A2B.
A2B also does not require full autonomy. Human confirmation does not make an action cease to be A2B. Autonomy describes how much of the path has been delegated, not whether the relationship exists.
A2B is adjacent to MCP, A2A, RPA, and Agent Commerce, but not identical to them
Several existing terms describe important parts of the landscape:
| Concept | Primary object of description |
|---|---|
| B2B / B2C / B2B2C | Commercial relationships between market participants |
| A2A | Communication and collaboration between agents |
| API / MCP / SDK | How capabilities are described, discovered, connected, or invoked |
| RPA / workflow automation | How predefined automation steps are organized and executed |
| Agent Commerce | How agents participate in discovery, transactions, or payments |
| A2B, as used here | How an agent enters an existing business system and performs accountable work |
MCP may carry an A2B action, but connecting a tool is not the same as defining the relationship in which the tool is used.
A2A may coordinate several agents before one of them enters an order, finance, healthcare, or production system. A complex task can contain many A2A interactions and still culminate in one or more A2B boundary crossings.
RPA may automate the same business operation, but its path is usually predefined around an interface or workflow. A2B emphasizes semantic delegation and dynamic path selection.
Agent Commerce may describe agents finding products, negotiating, purchasing, or making payments. A2B includes commercial scenarios but is broader: an agent reading a patient record, changing an employee status, or filing a public-service application is still crossing into an institutional system even when no market transaction occurs.
These concepts are not rivals. They describe different axes of the same emerging stack.
A2B is a continuum of delegation, not an on/off switch
Organizations will not wake up one morning and move from no agents to fully autonomous operations. Delegation will expand in stages.
Stage 0: information
The agent answers from public content or a knowledge base without entering live business systems.
Stage 1: controlled reading
The agent can query orders, inventory, customer records, cases, or tickets but cannot change state.
Stage 2: action proposals
The agent uses business facts to prepare a recommendation, draft, or pending action that a person completes.
Stage 3: human-in-the-loop execution
The agent selects capabilities and constructs arguments, but consequential steps pause for human review before execution.
Stage 4: bounded ongoing delegation
Within explicit capability, identity, and responsibility boundaries, the agent continuously performs a class of business work and returns only exceptions or high-consequence decisions to people.
A2B therefore matters long before full autonomy.
The first time an agent reads private orders, the system must already know whom it represents and what it may see. When it prepares actions, the organization must distinguish suggestions from official acts. When it can submit a refund, delegation and traceability become central.
A2B maturity is ultimately a measure of how much real business action an organization is both willing and able to delegate.
Model quality is only one variable. Often, the factor preventing an organization from moving from reading to execution is not another benchmark point. It is the inability to explain and control the action chain.
Existing systems are the center of the problem
It is tempting to imagine that enterprises will rebuild everything as AI-native software and leave old systems behind. Reality will be less clean.
Orders, money, employees, customers, inventory, contracts, production, and public records already live inside systems that have accumulated years of data relationships, permissions, legal duties, and operating rules.
Agents will not enter an empty world. They will enter an existing institutional order.
That makes "legacy integration" a misleadingly small phrase. The hard problem is not only compatibility. It is allowing an agent to act inside an established system without asking that system to surrender its authority over identity, business state, and final outcomes.
A new conversational interface may receive the goal. A new protocol may expose capabilities. A new runtime may organize the task. But the valid order state, account balance, employment relationship, approval record, or production status still belongs to the business system.
One of the defining capabilities of future software may therefore be this:
Can the system expose clear, stable, and governable capabilities to agents while retaining its own business authority?
A2B is not tied to a screen, device, or protocol
A2B first becomes urgent in enterprise software, but its structure is not limited to an admin console or a chat window.
Software agents, AI operating systems, phone-level assistants, embodied robots, and multi-agent systems may have different sensors, actuators, and protocols. The test is not what device they run on. The test is whether semantic delegation, boundary crossing, and institutional consequence are present.
| Carrier | Usually outside A2B | Potentially inside A2B |
|---|---|---|
| Software agent | Summarizing local documents or organizing personal files | Creating a purchase order in ERP or changing a customer state in CRM |
| AI phone or operating system | Adjusting screen brightness or starting a timer | Entering airline, banking, healthcare, commerce, or government systems to make an accountable change |
| Embodied robot | Local navigation, motion planning, or obstacle avoidance | Receiving inventory, confirming handoff, and updating WMS, ERP, or fulfillment state on behalf of an organization |
| Multi-agent system | Discussion, planning, and exchange of intermediate results | A collaboration chain that ultimately performs an official action in a business system |
Physical action is not automatically more A2B than digital action. A robot navigating safely in a closed environment is primarily a robotics and control problem. A software agent reading a protected medical record may already have crossed a consequential institutional boundary.
The same system can contain both A2B and non-A2B layers. A warehouse robot needs control systems to avoid collisions. When it claims inventory, records a handoff, and changes fulfillment state, it also enters a business relationship. The first layer concerns physical safety and control latency. The second concerns whom the robot represents, why it may act, who confirms the result, and how errors are traced.
A2B does not replace robotics safety, operating-system security, identity infrastructure, or A2A protocols. It identifies the relationship that appears when those systems carry delegated action into the business world.
As this relationship spreads, software competition may change as well. Applications have traditionally competed for human attention through screens, notifications, and branded interfaces. If agents become a primary entry point, services will increasingly compete to be correctly understood, selected, invoked, and completed by agents.
That could shift part of digital distribution from control of the screen toward control of delegation, identity context, and task orchestration. This is not a completed fact, but it is an important possibility revealed by the A2B frame.
Once the category exists, an ecosystem can accumulate around it
Categories are sometimes dismissed as marketing. At their best, they are coordinates around which research, engineering practice, investment, regulation, and community knowledge can accumulate.
If A2B is recognized as a distinct problem, we can begin to ask systematically:
- At what stage of A2B maturity is an organization?
- Which business capabilities should be delegated first?
- What responsibilities belong to the agent, runtime, gateway, identity system, and business system?
- How should an A2B incident be classified and reconstructed?
- Which infrastructure needs recur across implementations?
- Which knowledge can be shared across industries, and which rules must remain local?
- Will cross-platform semantic and interoperability layers become necessary?
Without the category, the market sees isolated features: AI customer service, AI sales, AI finance, AI operations, AI phones, AI robots.
With the category, we can recognize their common infrastructure problem: agents are being connected to real capabilities, and machine action must become something an organization can accept, constrain, and explain.
The metrics of enterprise AI may change accordingly. Answer accuracy, model choice, and retrieval quality remain important. But once agents act, organizations will also need to measure:
- how many real workflows can be delegated;
- how many human steps are removed;
- which decisions still require human judgment;
- whether automation can expand without making responsibility ambiguous;
- whether failures can be stopped, explained, and recovered.
That is not merely an additional model benchmark. It is a different way of evaluating AI after it becomes part of production.
A useful concept should make falsifiable predictions
Technology narratives become grand very easily. A serious concept should do more than redescribe the present. It should make claims that reality can later support or reject.
If A2B identifies a durable relationship, we should gradually observe at least five developments.
1. Software will develop interfaces for both people and agents
Graphical interfaces will remain, but stable capability descriptions, machine entry points, and execution feedback will become first-class product surfaces rather than internal integration artifacts.
2. Enterprise AI maturity will be measured by delegable action
Organizations will care less about how many models they have connected and more about which operational responsibilities can be safely delegated, how exceptions return to people, and whether the delegation boundary can expand.
3. AI governance will extend from output quality to action provenance
It will not be enough to inspect what a model said. Organizations will need to know who initiated the goal, why the agent selected a capability, which identity it represented, how consequential arguments were formed, and where human decisions entered the chain.
4. An infrastructure layer will emerge between agents and business authority
It may be implemented by agent platforms, gateways, cloud providers, business applications, or independent control planes. Its product shape may vary. But capability exposure, identity continuity, action constraints, human intervention, and accountability records will recur.
5. Competition for user attention will partly become competition for delegated choice
When people express goals through agents, a service must be understandable and selectable by machines as well as visible to humans. Agent platforms may become a new distribution layer between intention and external capability.
If none of this happens, if business software remains purely human-operated, if enterprise AI remains an information tool, and if organizations never need to reconstruct agent action chains, then A2B should be challenged as an unnecessary category.
A concept that permits reality to prove it wrong is more useful than a slogan designed to survive every outcome.
From interface design to the institutional design of machine action
Graphical interfaces changed how people use software. Mobile computing changed when and where they use it. Natural language changed how people express intent.
Agents introduce a different question:
When people no longer perform every software operation themselves, how should the relationship among intention, software, organizations, and responsibility be redesigned?
The long-term significance is not that people click fewer buttons.
Many jobs currently involve understanding a human goal and translating it into system operations. As agents assume more of that translation, human work may shift toward goal setting, exception judgment, responsibility, and institutional design.
Software products may also be reorganized. Instead of being defined only by seats, pages, and workflows, some systems may be valued by how much work they allow people to delegate safely.
The deeper issue is one of agency and responsibility.
Human institutions have always depended on delegation. Employees act for organizations. Lawyers act for clients. Banks process funds under authorization. These relationships are governed by professional obligations, law, organizational controls, and the fact that the delegate remains a person who can bear responsibility.
An AI agent can perform more and more functions associated with agency while remaining unable to assume moral or legal responsibility in the human sense. It can interpret a goal, select a capability, submit arguments, and advance a process. It cannot independently carry the obligation that made the delegation legitimate.
This creates a machine-agency responsibility gap: operational capacity moves into the technical chain, while accountability must remain with deployers, business owners, and human authorization structures.
The more steps machines perform, the less acceptable it becomes to explain an outcome by saying, "the model decided." Organizations must instead explain who exposed the capability, who set the boundary, who allowed execution, and who owns the resulting institutional fact.
A2B is where that gap becomes concrete. It turns abstract AI risk into a traceable action chain:
information ends here; business action begins
tool connectivity ends here; organizational delegation begins
model output ends here; institutional consequence begins
A2B is not a complete answer to the governance of machine action. It is a coordinate for locating where the problem becomes unavoidable.
The name may change. The relationship will not disappear.
A2B remains a proposed expression.
The acronym already appears in other contexts, including agent-mediated commerce and payments. Another term may ultimately describe the broader relationship more clearly. The industry may absorb the problem into a larger discipline of agent infrastructure, digital delegation, or machine-action governance.
A concept can have explanatory value without owning the future vocabulary.
As long as people increasingly state goals rather than steps, agents increasingly choose tools and paths, business systems increasingly expose machine-operable capabilities, and organizations remain accountable for the results, this relationship will require a language.
The carrier may change. The protocol may change. The final name may change.
But the boundary between AI producing information and agents entering the business world to act will not disappear merely because we leave it unnamed.
A question for builders
This proposal should be tested against real systems, not protected from disagreement.
If you are building agents that read or change orders, accounts, staff records, inventory, healthcare workflows, production systems, or public services:
- What term do you currently use for this class of work?
- Where do you draw the boundary between agent assistance and agent-operated business action?
- Does the combination of semantic delegation, boundary crossing, and institutional consequence describe something that existing terms fail to isolate?
Alternative names, counterexamples, and boundary cases are useful evidence. A category becomes stronger by surviving precise criticism, not by avoiding it.
Conclusion: we are naming a relationship, not a technology
A2B matters not because the industry needs another acronym, but because a new relationship is beginning to take shape:
people once learned and operated software
-> people now state goals to agents
-> agents enter software and complete work on their behalf
Technically, that chain is composed of models, tools, protocols, runtimes, and business systems. Organizationally, it is a new division of labor. Socially, it means machine systems are entering human action chains in a more general, language-driven, and dynamically organized form.
We need a name for this relationship because without shared language, product managers, developers, architects, security teams, and business owners will continue to rediscover the same problem from different directions.
Once it becomes visible, the questions reorganize themselves: Which work should be delegated? Which capabilities should be exposed? Which decisions must remain human? How should software present itself to agents? How does responsibility return to people after machine-mediated action?
The shortest definition is still the most useful:
People used to open software and perform the work. A2B describes people stating goals and agents entering existing business systems to get the work done.
A2B may not be the final name.
But if agents are moving from answering questions to acting on our behalf, the era this name points toward has already begun.
Top comments (1)
I appreciate how the concept of A2B, Agent-to-Business, sheds light on the complexities of AI agents interacting with existing business systems, and I think it's particularly interesting that you highlight the importance of stable categories in accumulating engineering knowledge. The fact that different teams, such as commerce, CRM, and HR, may be working on similar architectural questions without realizing it resonates with my own experience in integrating AI into existing systems. I've seen firsthand how the lack of a shared vocabulary can lead to duplicated effort and fragmented solutions. By introducing A2B as a working concept, do you think it could also facilitate the development of more standardized frameworks and tools for agent-to-business interactions, potentially simplifying the process of integrating AI into existing business systems?