AI assistant vs AI agent: the procurement distinction

In May 2025 Salesforce announced that Agentforce had been “deployed to over 4,000 customers” with the framing that AI is moving from assistant to agent across the enterprise stack. Twelve months later the procurement reality is that most enterprises that thought they bought an agent bought an assistant, and most enterprises that thought they bought an assistant have a feature flag away from operating an unbounded agent. The conflation is the most common single category mistake in 2026 enterprise AI procurement.

This piece is the structural distinction: what an AI assistant is, what an AI agent is, why the categories cannot be governed under the same procurement template, and how to structure procurement so the distinction holds across product evolution.

Two propositions structure the piece:

• The defining test is whether the system changes state on a downstream surface autonomously. Suggesting an output to a human is assistant work. Writing to a database, calling an API, sending a message, raising a ticket, modifying a repo — without per-action human approval — is agent work. The capability of the underlying model is not the dividing line; the connection to a write-path is.
• The procurement gate has to fire on capability change, not on vendor change. Many assistant-class products have agent capability one feature flag, one pricing tier, or one tool integration away. Procurement workflows that approve at vendor-onboarding and never re-evaluate are blind to the moment the same vendor becomes a different governance class.

What an AI assistant actually is

An assistant is a system that produces outputs for a human reviewer to accept, reject, or modify. The human is the decision-maker and the approval-step is in-loop on every consequential action. In product terms: ChatGPT (consumer or Pro), Claude.ai, Gemini chat, GitHub Copilot in inline-suggest mode, Notion AI, Microsoft 365 Copilot in chat mode (without agent tools enabled), and the long tail of vertical AI tools that draft and recommend.

The governance properties that follow:

• Bounded blast radius. The downstream effect of any specific output is gated by the human reviewer. A bad assistant output is at worst an embarrassing draft or a wasted minute of review.
• SaaS-template governance fits. Data residency, breach notification, exit clauses, support SLAs — the existing SaaS contract template covers most of the risk surface adequately.
• Audit obligation is light. Auditors care that the system does not retain protected data, not that every output was logged with chain-of-custody. The output is ephemeral and the human’s decision is the system of record.
• TCO is per-seat, predictable. Licence fee × users × annual term, with linear scaling.

Assistants are the dominant deployment class in 2026 by user count and by vendor revenue, and most enterprise AI procurement to date has been assistant procurement. The procurement approval for “we are buying ChatGPT Enterprise” is a known thing.

What an AI agent actually is

An agent is a system that acts on a downstream surface autonomously within a defined permission scope. The defining capability is tool use against a write-path — the system can change state in another system on its own decision, without per-action human approval, within bounds set at configuration time.

In product terms: Microsoft Copilot Agent Mode (with tools enabled), Anthropic Claude for Chrome (with browser actions enabled), Salesforce Agentforce, Google agentic features (restaurant booking, scheduling), Cursor agent mode, Devin (Cognition), Manus, Lindy, the long tail of vertical agentic products. Also: any framework deployment (LangChain, AutoGen, CrewAI, Semantic Kernel) running in production with tool access against enterprise systems.

The governance properties that follow:

• Blast radius is the tool surface, not the human reviewer. The downstream effect of any specific action is bounded by what the agent’s tools can touch and by the permission scope assigned at configuration time. A bad agent action can write to production systems, send messages to customers, raise tickets, modify code, transfer money. The blast radius can be much larger than any individual action’s apparent scope.
• SaaS-template governance does not fit. The contract template assumed the vendor was providing a SaaS application a human used. Agents introduce a non-human identity acting against your enterprise systems. Most of the risk surface is not covered by the existing template — see build vs buy vs partner on the procurement-shape mismatch.
• Audit obligation is heavy. Regulators (EU AI Act, NIS2, GDPR Article 33 incident-reporting, sector-specific) increasingly require evidence-of-action for autonomous systems. The audit trail per action, the threat model for the tool surface, the action-approval gate for high-blast-radius operations — these are the audit production requirements. Assistant-class instrumentation does not produce them.
• TCO is per-action and uncertain. Token costs scale with action volume, not with seat count. Integration cost, oversight cost, and incident cost are typically 40-60% of the visible vendor cost. The CFO TCO model that worked for assistants underestimates agent TCO consistently — see hidden costs at /claims/AM-020/.

Agents are a smaller but faster-growing deployment class. Most 2026 procurement of agents is happening under approval workflows that were designed for assistants, which is the structural problem this piece is naming.

Why the line matters: the EchoLeak class of incident

The clearest concrete demonstration of the assistant-vs-agent distinction is the EchoLeak family of cross-agent prompt-injection exploits. The mechanism is straightforward: an attacker plants an instruction inside data the agent will read (an email body, a calendar event, a shared document), and when the agent reads that data while connected to write-paths, it executes the planted instruction.

Against an assistant, EchoLeak does almost nothing. The assistant produces an output to a human, the human reads it, sees something odd, and discards it. The blast radius stops at the human reviewer.

Against an agent with the same underlying model and similar capabilities but tools enabled, EchoLeak can exfiltrate data, send messages on behalf of the user, write to systems the user has permissions to touch. The same vulnerability has dramatically different operational consequence depending on whether the deployment is assistant-class or agent-class.

This is why the procurement distinction is not a marketing-language argument. It is a measurable difference in what the deployment can do under attack.

The vendor blur: same product, two classes

Most of the friction in 2026 procurement comes from products that are configurable across the line. Three concrete examples:

ChatGPT Enterprise. In default chat mode it is an assistant. With Custom GPTs that have actions configured (tool calls against external APIs), specific instances become agents within their action scope. The procurement approved “ChatGPT Enterprise” — was the approval intended to cover Custom GPT actions, and were any of the action surfaces specifically risk-assessed?

Microsoft Copilot. Across the Microsoft 365 surface, Copilot has chat mode (assistant), agent mode (agent), and tooled custom agents authored in Copilot Studio (variable). The same licence, the same vendor, three different governance classes depending on which surface the user is operating in. Most enterprise Copilot procurement approvals were written before agent mode existed and have not been revisited.

Anthropic Claude. Claude.ai is an assistant. Claude with computer-use enabled is an agent. Claude for Chrome with browser actions enabled is an agent. The vendor is the same; the governance class changes based on which capabilities are turned on, often by the user, often without procurement re-approval.

The pattern across all three: the agentic capability is one configuration step away from the assistant procurement that was originally approved. Procurement workflows that approve once at vendor-onboarding miss the moment the deployment crosses the line.

How to structure procurement so the distinction holds

Two-stage procurement gate. The structure:

Stage one — assistant procurement. The standard SaaS governance template applies. Per-seat licence, data residency clause, breach notification, exit clause, support SLA. The existing procurement workflow handles this competently. Sign off, deploy, monitor.

Stage two — agent procurement gate. Triggered by any of the following events, regardless of vendor change:

• The deployment gains the ability to call tools that change state in any downstream system.
• The deployment gains write-path access to enterprise data stores, communication channels, or customer-facing surfaces.
• A new pricing tier, feature flag, or integration enables agentic capability that was not present at original approval.
• The user count exceeds an agreed threshold for the agentic feature (the volume above which incident probability becomes material).

When the trigger fires, the deployment must pass a stage-two evaluation:

1. GAUGE scoring on the six dimensions (governance maturity, threat model, ROI evidence, change management, vendor lock-in, compliance posture). Free Excel diagnostic at /gauge/.
2. Action-approval gates appropriate to the blast radius. High-impact actions require human-in-loop approval; lower-impact actions can run autonomously but must produce audit-grade evidence.
3. Audit-evidence production matched to the regulatory exposure. NIS2, GDPR, EU AI Act Annex III tier obligations, sector-specific (HIPAA, GLBA, etc.). The evidence map is per-deployment, not per-vendor.
4. Threat model specific to the tool surface. Standard application-security templates do not cover cross-agent prompt-injection or non-human-identity escalation patterns. The threat model needs an agentic-AI-specific augmentation.
5. MTTD instrumentation. Detection time for unintended actions, with published targets (4h enterprise, 24h mid-market) per /mttd/.
6. The 60-question agentic AI RFP answered by the vendor. Free Excel template at /the-enterprise-agentic-ai-rfp-60-questions/.

The two-stage gate is not slower than current procurement on average — it is faster on the assistant cases (no extra gate fires) and substantively rigorous on the agent cases (where the rigour was missing). The shift is in matching procurement effort to actual risk class rather than to vendor identity.

What to do Monday

For a CIO reading this whose enterprise has approved one or more vendor AI tools in the last 18 months:

• Inventory by capability, not by vendor. Walk every approved AI deployment and answer: does this deployment currently have the ability to act on a downstream surface autonomously? Don’t ask the vendor; ask the team using it.
• Flag the assistant-to-agent transitions. Any deployment whose answer changed since the original approval is an audit-readiness concern. The question is not “was the original procurement wrong” — it is “what has changed since, and is the governance up to date with the change?”
• Add the stage-two trigger language to procurement policy. It is a one-page policy update. The trigger is: any AI deployment that gains the ability to act on downstream systems must re-enter procurement under the agent-class gate. The trigger applies regardless of vendor change.
• For deployments already on the agent side: score on GAUGE. Free Excel diagnostic, 30-45 minutes per deployment with the surface owners in the room. The two lowest scoring dimensions become the Q2 leadership agenda.

The structural fix is not in the technology layer; it is in the procurement workflow. The category mistake gets made once at the procurement gate. Catching it once removes the systemic source of the most common 2026 governance gap.

The claim of this piece — that AI assistants and AI agents are categorically different product classes for procurement purposes, that conflating them is the most common 2026 procurement mistake, and that the structural fix is a two-stage procurement gate triggered on capability change rather than vendor change — is on a 60-day review cadence. Logged at AM-034 on the Holding-up ledger.