FOUNDATIONS / RETROSPECTIVE

Foundation Models to Enterprise Agents, 2021–2026

The important transition was not from chatbots to a fashionable new label. It was from models that generated outputs to systems that can retrieve context, invoke tools, maintain state, coordinate steps, carry identity and act inside governed enterprise workflows.

Period analysed: 2021–2026 · Published: 16 October 2026 · Updated: 21 October 2026
Figure 01The widening enterprise system boundary
2021Foundation modelGeneral capability across tasks
→
2022–23AssistantNatural-language work interface
→
2023–24Tool userRuntime context + action
→
2024–25Workflow actorState + multi-step execution
→
2025–26Managed agent systemIdentity + governance + evaluation

Notice the boundary shift: each stage adds not only capability, but a larger operating surface that the enterprise must govern.

1. The foundation-model shift widened the feasible task space

In 2021, Stanford researchers used foundation model for models trained broadly and adaptable across many downstream tasks. A single technical base could increasingly support writing, classification, extraction, coding and analysis without a separate model being engineered for every task. That changed the economics of experimentation. It did not remove the need for task design, data, controls or integration.

2. Instruction-following turned capability into an interface

General-purpose models became easier to direct through natural language and conversational interfaces. Copilots emerged from this pattern: the model stayed close to a person, producing drafts, suggestions, summaries, code or analysis while the human retained the surrounding workflow. This lowered adoption friction, but often left the process itself largely unchanged.

3. Retrieval changed what the model could know at runtime

Enterprise usefulness depends on context that is specific, changing and private. Retrieval architectures allowed applications to supply relevant documents, records and knowledge at runtime. The model became one component inside a larger information system; identity, permissions, search, data quality, provenance and lifecycle became architectural concerns.

4. Tool use changed what the system could do

Function calling and structured tool interfaces moved applications beyond generating text about an action. A model could select a defined function, produce structured arguments and hand execution to software connected to databases, APIs and business systems. Once actions enter the architecture, authorization, transaction boundaries, validation, exception handling, auditability and recovery become part of the AI system.

5. Agentic workflows added sequencing, state and feedback

Calling one tool is not the same as operating through a workflow. Agentic systems combine model reasoning with repeated observation, tool selection, execution and evaluation. The practical unit of design becomes larger than a prompt: a goal, available tools, memory or state, decision rules, checkpoints, escalation paths and termination conditions.

6. Protocols began separating agents from individual application silos

Model Context Protocol standardized a way for AI applications to connect with external tools and data. Agent-to-Agent protocols addressed communication and coordination between distinct agents. By 2026 these ideas were moving into major enterprise platforms rather than remaining developer experiments.

Microsoft Copilot Studio now supports agent-to-agent communication and multi-agent orchestration across Copilot Studio, Microsoft 365 and other agent environments. Its current platform also supports MCP tools. This matters because the architecture is shifting from isolated assistants toward composable systems of specialized actors.

7. 2026 added an enterprise operating layer

The most consequential 2026 development is not simply that agents became more capable. Major platforms began supplying the surrounding machinery required to operate them as enterprise entities.

Figure 02The enterprise operating layer around an agent
AGENT / WORKFLOW ACTORmodel reasoning + context + tools + state
IDENTITYManaged actor, ownership
PERMISSIONSData and tool boundaries
INVENTORYDiscovery and lifecycle
TELEMETRYRuns, errors, outcomes
EVALUATIONCases and business metrics
CONTROLPolicy, escalation, recovery

The agent becomes enterprise infrastructure only when the surrounding operating layer makes it identifiable, observable, bounded and governable.

Microsoft Agent 365 is now positioned as a centralized control plane for agent inventory, permissions, behavior and activity. Copilot Studio automatically creates an Entra Agent ID for new agents, exposes agent inventory and telemetry, and supports outcome-based evaluation. OpenAI’s AgentKit similarly brought workflow versioning, connector administration, guardrails and evaluation tooling into the agent-development stack. These are signs of the same maturation: the agent is becoming a managed software-and-work entity rather than a prompt wrapped around a model.

8. Enterprise context is becoming infrastructure

An agent that lacks organizational context is a general capability with a narrow operating view. Current enterprise systems increasingly provide managed context layers that expose permitted company knowledge, signals and tools. Microsoft Work IQ connects agents to organizational data such as email, calendar, files, Teams messages and people information. Anthropic’s 2026 enterprise direction similarly centers Claude on connected tools, organizational knowledge, Cowork and plugins.

The design consequence is significant. Context is no longer only a retrieval implementation detail. It becomes shared infrastructure whose quality, permissions, freshness and semantics determine what multiple agents can reliably know.

9. Deterministic workflow and agentic reasoning are converging

Early agent narratives often implied that a sufficiently capable model should reason through the entire process. Enterprise platforms are moving toward a more disciplined hybrid. Microsoft now allows agents to be embedded inside deterministic workflows and AI actions to be inserted at selected steps. This is a useful architectural pattern: use rules and workflow where the process should be predictable; use model reasoning where interpretation and variation justify it.

10. “Agent” is too broad to be a useful design specification

The term now covers systems with radically different operating characteristics: a model choosing among two tools, a coding system working through a repository, a customer-service workflow with approvals, or multiple specialized agents coordinating a long-running task. For enterprise design, the label matters less than the operating contract.

01Goal

Bounded outcome and completion condition

02Context

Permitted data, memory and evidence

03Action

Tools, systems and transaction rights

04Control

Approval, limits, escalation and recovery

05Evidence

Telemetry, evaluation, outcome and learning

11. Enterprise agents are operating-model components

An agent that can read records, make intermediate decisions and initiate actions occupies a position in the work system. It changes task allocation, handoffs, supervisory load, response times, exception queues and potentially decision rights. Anthropic’s 2026 enterprise work shows this moving into legal, finance, sales and other knowledge-work functions; its KPMG alliance embeds Claude in Digital Gateway and extends access across more than 276,000 employees.

The implementation question is therefore not whether an agent can complete a benchmark task. It is whether the surrounding Human–AI system produces better outcomes under real organizational constraints.

12. Autonomy should be designed as a variable

Enterprise workflows rarely require one universal autonomy level. Low-risk, reversible actions may justify broad execution rights. High-consequence or ambiguous decisions may require human approval. Other steps may permit autonomous action inside thresholds with mandatory escalation outside them.

Figure 03Capability can move faster than authority
READ→INTERPRET→RECOMMEND→PREPARE→EXECUTE BOUNDED→COMMIT
System capability expands →Human authority remains explicit at consequential commitment

Capability can move right faster than authority should. Identity, permissions, evidence, reversibility and consequence determine where an enterprise should place the operating boundary.

Figure 04The enterprise-agent boundary is an operating contract
01 · CONTEXTWhat the system may knowPermitted data · memory · provenance · freshness
→
02 · CAPABILITYWhat the system may doReason · retrieve · use tools · maintain state
→
03 · ACTION BOUNDARYWhere consequence beginsExecute only inside explicit permissions, thresholds and reversible bounds
IDENTITYWho is acting?
AUTHORITYWho may commit?
EVIDENCEWhat is observable?
RECOVERYHow is action stopped or reversed?

The architecture becomes enterprise-grade when context and capability are connected to explicit action rights, accountable authority, operating evidence and recovery—not when autonomy is maximized.

13. The 2021–2026 transition is architectural

The deepest change across the period can be summarized as a widening system boundary:

Model→Assistant→Tool user→Workflow actor→Managed enterprise agent→Agent system

Each step adds organizational possibility and dependencies. Enterprise value increasingly depends on the architecture around the model: context, tools, workflow, identity, permissions, evaluation, Human–AI allocation, operating controls and production evidence.

The enterprise-agent era begins when autonomy becomes operable, observable and governable—not when software is given the label “agent.”

Sources