Designing the Enterprise Agent for a Three-Body World
The real question is not whether the enterprise will have an agent. It is whether the enterprise is willing to design it for the complexity of the relationship it is about to enter.
I’ve focused a lot on this Substack on the arrival of an empowered customer side agent. In many ways, that is the more interesting story, and it is where a lot of the real change is going to come from. But it is not the whole story. In the near future, the enterprise will meet the customer’s agent with one of its own, and the design of that agent will end up shaping every relationship it enters.
The enterprise agent is the general focus in today’s agentic AI conversation, and a lot of assumptions have been made on what the agent actually does. However, I think there is a massive gap that exists in the assumptions around enterprise side agents. That is a gap worth closing, because building the enterprise agent well is going to be one of the harder operational challenges of the next several years.
The work sorts into three areas. The first is representation. The agent will speak for the enterprise in every exchange with a customer-side agent, which means it will be the operational face of what the enterprise has committed to. Every claim it makes will be logged in the customer agent’s memory as a commitment the enterprise can be held to later. The design question is how much authority the agent carries. What can it commit to on its own. What does it need to escalate. What is it never allowed to promise. Those are strategic questions, not technical ones, and most enterprises have just started asking them.
The second area is protection. The agent has to look after the enterprise’s interests without losing the respect of the customer-side agent it is talking to. That balance is harder than most current agent frameworks are built for. If the enterprise agent is too accommodating, margins erode and precedents get set the enterprise cannot sustain. If it is too rigid, customer-side agents will note the pattern and route their relationships elsewhere. The right posture will vary by industry, by relationship stage, and by the specific commitments already on the table.
The third area is reciprocity. The customer agent will be sharing context under a trust protocol like MyTerms. The enterprise agent will need to receive that context in ways the customer agent can verify, act on it in ways the customer agent can audit, and contribute context back where doing so would strengthen the relationship. While secure API connectors have existed for a long time in the B2B world, the concept will need to radically evolve to be agentic, especially in the B2C world. This is not how enterprise communication with customers has ever worked. It has been almost entirely one-directional. Adding to this is that there will be a third, agentic agent, that of the product/service. The enterprise agent has to be built to handle these new relationships for that from the start.
There is a further layer of complexity most current thinking is missing. The enterprise agent is not going to be operating in a two-body relationship. It will be operating in a three-body one. I first proposed this as the three-body problem of customer experience last year, and returned to it more recently with the three bodies, four forces model that has been a core thesis of this Substack. The customer is one actor. The enterprise is a second. The product or service the enterprise offers is the third, and in the near future the product will bring its own intelligence into the conversation. What the product is learning about how it is being used, where it is delivering value, where it is falling short. The enterprise agent has to be designed to receive that signal, weigh it against what the enterprise itself is committing to, and represent the whole picture accurately to the customer agent it is negotiating with.
That is a level of design complexity that current agent projects are likely not built for. Most enterprise agent efforts today assume a two-body model. A customer and an enterprise, mediated by a bot. The three-body reality is going to demand something structurally different, and the enterprises that recognize that early will end up with agents that hold together across the range of situations they are going to encounter. The ones that build for the two-body version will find their agents contradicting the product, mismanaging expectations, and eroding standing without anyone quite understanding why.
The infrastructure to support any of this does not currently exist at most enterprises. There is no operating model for what the enterprise agent should be authorized to do. There is no legal framework for what it can commit to on the enterprise’s behalf. There is no organizational home for the function that owns how it behaves. Each of these will have to be built.
The real question is not whether the enterprise will have an agent. It is what the enterprise wants that agent to stand for, and whether the enterprise is willing to design it for the actual complexity of the relationship it is about to enter. That complexity includes a product body that is going to have plenty to say for itself, and I want to spend the next piece on what that product body actually contributes and how the enterprise should be preparing to receive it.