Chat windows are becoming interchangeable. Enterprise AI's real contest is who authorizes the transaction

An employee types into Microsoft Teams that they need to move two days of vacation to next month. A model from one vendor works out what that means. An orchestration engine from another decides which agent should handle it. A third system checks the balance, the manager’s approval and the country’s leave rules, and then changes the record.

Four vendors may touch that request. Only one of them can say yes.

This week’s announcements make that division unusually visible, and in our view it is where the next few years of enterprise AI architecture will be decided. Not in which assistant employees prefer, and not in which model tops a benchmark, but in which layer holds the authority to commit a business transaction.

The same line, drawn three times

The facts first.

On October 13, Workday made its agent platform headless: outside agents can call its MCP tools and query live data, and its Sana orchestration is going into Claude, Copilot, Gemini Enterprise, Teams and Slack. Its position on the boundary is explicit: “Third-party AI tools and platforms never get raw access to Workday data,” and “policy checks and approvals stay anchored in Workday.” We analyzed the release in Workday goes headless for AI agents.

On October 12, Microsoft published a reference architecture in which a Foundry agent runs inference on its own identity but retrieves SharePoint documents as the signed-in user, so that SharePoint, not the agent, decides what each person may see. We covered it in retrieval as the user.

On October 13, a Microsoft Azure Networking engineer described an on-call agent where “the model never makes the decision and never holds the execution credential.” Production writes stop for human approval, enforced in the execution engine. See how that agent turns reasoning into playbooks.

And earlier this month, SAP made the same bet from the opposite side by keeping Joule’s agents inside the transaction system, where approval limits and segregation of duties already work.

Different companies, different products, one architecture: reasoning is portable, authority is not.

Four layers, two of them movable

Every enterprise AI request now crosses four layers: the interface where it starts, the reasoning that interprets and plans, the authorization that decides whether this person may do this thing now, and the execution and record that commits it. The first two are becoming interchangeable. Workday supports half a dozen model families and five assistants; Microsoft’s agents switch models by configuration; employees will use whichever chat window their company licensed this year.

The last two are not interchangeable, and they should not be. Authorization depends on facts only the system of record holds: reporting lines, balances, limits, open approvals, regulatory rules by country. Execution must be atomic, auditable and reversible on the system’s own terms. An assistant that tried to hold those would have to duplicate the record, and then there would be two.

Here we move from fact to opinion. Our expectation is that the commercial contest will follow this split. Interface vendors will push to orchestrate more of the work and keep more of the context. Systems of record will push to own authorization for every agent that touches their data, whoever built it. The vendors that win the enterprise will be the ones that make authorization easy for others to call, not the ones that make their chat window stickier.

In regulated sectors, this is already settled

Banking and life sciences did not wait for agents to decide where authority lives. A bank’s maker-checker rules and segregation of duties are enforced in its core systems and audited there. In a GxP environment, the validated system is the record, and a front end cannot become the record by being convenient. For these organizations, the architecture above is not a design preference. It is the only version an examiner or inspector will accept. The question is whether AI programs are designed that way from the start, or retrofitted after the first audit finding.

What to do with this view

If the transaction layer is the strategic one, four practical consequences follow:

• Decide where each transaction class is authorized, and default to the system of record. A list of “which assistants may start which transactions, authorized where” is a short document that prevents long arguments.
• Keep execution credentials out of the reasoning layer. No model, and no orchestration engine you do not control, should hold a credential that can commit a transaction on its own. This is the separation we described in six independent authorities.
• Design the join between audit trails. The assistant logs the conversation; the system of record logs the transaction. An incident review needs both, linked by an identifier both sides record. Ask for it in the integration design, not after the incident.
• Ask vendors which layer they claim. In procurement, “Does your agent authorize, or does it ask the system of record?” is a better question than “Which models do you support?”

What would prove us wrong

If assistants start holding authoritative records themselves, or if auditors begin accepting an assistant’s conversation log as the record of a business decision, the authority would be moving up the stack, and this view would need revising. We will watch for both. For now, the evidence points the other way: the chat window is becoming a doorway, and the business still decides who gets through.