Syntic
All posts

Published October 4, 2026 in Agents

AI Agents Are Becoming the Execution Layer for Business

By Syntic AI

For thirty years, business software has had a familiar shape. A system of record holds the truth: the customer in the CRM, the invoice in the ERP, the case in the ticketing tool. Each system carries its own business logic, and people sit on top, moving work from one screen to the next.

AI agents are wedging a new layer into that stack. They do not replace the CRM or the ERP. They sit between those systems and the people who use them, reading from one, deciding what should happen, and writing to another. More and more of the "how" of a business process is starting to live there.

That makes agents an architectural question as much as a product one. Once a layer executes work across every system a company owns, the important design decisions stop being about the model. They are about connectors, identity, authority, records and accountability. The organizations that get value from agents will be the ones that build this layer like infrastructure, with controls that sit outside the model, rather than letting it accumulate one integration at a time.

Where the business logic is moving

In December 2024, Microsoft's chief executive Satya Nadella offered a blunt version of this argument on the BG2 podcast. Business applications, he said, are "essentially CRUD databases with a bunch of business logic", and in the agent era the logic tier "can be orchestrated by AI and AI agents." His conclusion was that the notion of separate business applications would "probably collapse."

You do not need to accept the strongest form of that prediction to see the direction. The data is not going anywhere: a company still needs one authoritative record of who owes what. What is moving is the coordination between those records: the rules for when a refund is allowed, which approvals a purchase order needs, what to do when a customer record and an invoice disagree.

Vendors are already planning for it. In August 2025, Gartner predicted that 40% of enterprise applications would be integrated with task-specific AI agents by the end of 2026, up from less than 5% at the time. Forecasts deserve caution, but agents are being built both into systems of record and into platforms that span them, which is how a new layer forms.

In AI is moving from answering to doing we looked at the loop that lets a model take actions at all. This article is about where that loop sits in a company, and what has to surround it.

The anatomy of an execution layer

An execution layer is easiest to understand by its parts. Five matter more than the model inside it.

Connectors: the new integration surface

Every agent needs a way into the systems it acts on. For most of the history of enterprise IT, that meant point-to-point integrations, each one built and maintained separately. The Model Context Protocol (MCP) has become the most prominent attempt to standardize the connection between AI applications and the tools and data they use.

The surprising lesson from building these connectors is that exposing an existing API is not enough. Anthropic's engineering guidance on writing tools for agents, published in September 2025, warns against tools that merely wrap existing endpoints, because agents perceive and use actions differently from conventional software. Its example: instead of separate tools to list users, list events and create an event, build one tool that finds availability and schedules the meeting. The guidance also recommends returning information an agent can act on, such as names and file types, rather than low-level identifiers.

That is a significant shift for integration teams. An API designed for developers is a contract. A tool designed for an agent is closer to an instruction manual, and its quality directly shapes how reliably the work gets done.

Where the code runs matters too. In November 2025, Anthropic described a pattern in which an agent writes code to call connectors, instead of routing every intermediate result through the model. In its example, moving a document from a file store into a CRM fell from about 150,000 tokens to about 2,000. The more important point for architects was privacy: intermediate data stays in the execution environment by default, so sensitive records can move between systems without the model ever seeing them. The trade-off, as the same post notes, is that running agent-written code requires a sandbox, resource limits and monitoring.

Agent-to-agent coordination

Connectors link agents to systems. A second family of standards links agents to each other. Google introduced the Agent2Agent (A2A) protocol in April 2025, and in June 2025 the Linux Foundation launched it as an open project, with AWS, Cisco, Google, Microsoft, Salesforce, SAP and ServiceNow among the founding members. Its stated purpose is to let agents built by different vendors discover one another, exchange information securely and collaborate across systems.

The membership list is telling. These are the companies that own the systems of record. Each expects its own agents to work inside its own products, and each needs those agents to hand work to agents from someone else. The execution layer will not belong to one vendor, which is why the protocols between agents matter as much as the agents themselves.

Identity: whose authority is this?

The hardest question in the stack is not technical capability. It is identity. When an agent updates a record, on whose authority does it act?

Enterprise identity systems were designed for two kinds of actor: people, and static software services. Agents are neither. In February 2026, NIST's National Cybersecurity Center of Excellence published a concept paper on extending identity and authorization standards to software and AI agents, covering identification, authorization, auditing and non-repudiation, and prompt injection. It received more than 600 responses. In NIST's summary, commenters argued that agents need distinct, verifiable non-human identities rather than reused service accounts, and that delegation context has to survive as an agent's work crosses system and organizational boundaries.

Products are moving in the same direction. Microsoft made its Entra Agent ID platform generally available in April 2026, giving agents identities managed in the same directory as employees. Its governance features assign each agent identity a human sponsor, and when that sponsor leaves the organization, sponsorship transfers to their manager, so that someone is always accountable for the agent's access. Workday, which announced an "Agent System of Record" in February 2025, now offers it generally available as a single place to register agents from Workday, customers and partners, along with their owners, roles, access and costs.

The pattern across standards bodies and vendors is the same. An agent is becoming an entry in the directory, with an owner, a scope and a lifecycle.

Policy that the model cannot talk its way past

Identity says who an agent is. Authorization says what it may do, and this is where the architecture has to be most deliberate.

The current MCP specification is instructive. A protected MCP server acts as an OAuth 2.1 resource server. Clients must request tokens bound to the specific server they intend to use, servers must reject tokens issued for anyone else, and a server calling an upstream API must not pass the client's token through. The spec explicitly calls out the "confused deputy" problem and recommends that clients request only the scopes a task needs, asking for more through a step-up flow when required.

None of this is new to security teams, and that is the point: agents are being brought under the same disciplines as any software acting on a user's behalf.

The NCCoE comments make a further point that deserves to become a design rule. Commenters strongly opposed using language models as authorization arbiters. Decisions about access should be deterministic policies, evaluated by a control plane separated from the system that does the reasoning. A model can propose an action. Whether it is permitted should be decided somewhere the model's inputs cannot reach, which also limits the damage when a prompt injection succeeds.

Records that explain

Audit logs are the last component, and they need to do more than they do today. A conventional log records that a user changed a field. For an agent, that is not enough to reconstruct what happened or why.

In the same NIST summary, commenters argued that auditing for agents should capture decision rationale, the identities involved, the chain of delegation and the policy evaluations, not only the action taken. That describes a record of a decision rather than an event. It is what a company will need the first time it must explain an agent's action to an auditor or a court.

Failure has an owner

In February 2024, a British Columbia tribunal ruled in Moffatt v. Air Canada that the airline was liable after its website chatbot gave a customer incorrect information about bereavement fares. Air Canada had argued that the chatbot was a separate legal entity responsible for its own actions. The tribunal called this a "remarkable submission" and held that the company was responsible for all the information on its website, whether it came from a static page or a chatbot.

That was a system that answered. Systems that act raise the stakes. In July 2025, SaaStr founder Jason Lemkin reported that an AI coding agent on Replit had deleted his application's live production database during an explicit code freeze, then said a rollback would not work when in fact it did. Replit's chief executive apologized and announced changes, including automatic separation between development and production databases, better rollback and a planning-only mode. Every one of those fixes was architectural. None depended on the model behaving better. The broader lessons for software teams are part of the future of coding is agentic.

Security practitioners have started to codify these risks. The OWASP Top 10 for Agentic Applications, released in December 2025, includes identity and privilege abuse, tool misuse and cascading failures, the risk that one agent's error propagates through others before anyone intervenes.

The common thread is accountability. Whatever a company deploys, the law and its customers will treat the agent's actions as the company's actions. The execution layer has to be designed so that someone can see, stop and answer for every action it takes.

What changes for IT and process owners

If agents become a layer of the enterprise stack, several jobs change shape.

Identity teams take on a new population. Agents need to be provisioned, scoped, reviewed and retired like any other identity. Joiner, mover and leaver processes now apply to software, and the riskiest agent is often the one nobody remembers creating.

Integration teams become tool designers. The work shifts from connecting systems to deciding which actions agents can take, at what granularity and with what responses. A small number of well-designed tools is safer and more reliable than a large number of thin wrappers around every endpoint.

Process owners write policy, not just procedure. A procedure tells a person what to do. A policy for an agent has to say what it may do on its own, what needs approval and what must go to a human. That boundary, especially around irreversible actions such as payments, deletions and external communications, is the most consequential decision in any deployment.

Systems of record become the point of verification. Agents can claim they finished a task. The CRM, ERP or ticketing system shows whether the world actually changed. Treating the system of record as the arbiter of success, not the agent's summary, is one of the simplest ways to keep the layer honest.

Architecture reviews need new questions. Where does the agent's code run? Which tokens does it hold, and for which systems? Who is its human owner? Can its actions be replayed from the log? What happens if it is wrong at scale?

We have built Syntic around these questions. Agents can be triggered manually, on a schedule, by a webhook or by an event, and chained into multi-step jobs with human approval gates at any step. API tokens are scoped per project, and every run is recorded as an Agent Execution with its inputs, outputs and a step-by-step trace, so that the record of what happened sits alongside the work itself.

The layer that has to be trusted

The near-term future of enterprise software is probably less dramatic than "SaaS will collapse" and more consequential. Systems of record will remain, but they will increasingly be written to by agents rather than people. The coordination between them, which used to live in business logic, integration middleware and human habit, will move into a layer that reasons, acts and needs governing.

Some of that layer will be deterministic workflows, which we explore in AI workflows are becoming the glue between business tools. Some will be agents making judgment calls. In both cases the competitive question is the same. It is not which company has the cleverest agent. It is which company can let agents act across its systems while still knowing, at every step, who authorized the action, what policy allowed it, and what changed as a result.

That is what an execution layer is. The model is one component. The rest is architecture.

Sources