What is the difference between an AI assistant and an AI agent?

An assistant responds to a prompt and returns text you then act on. An agent holds a goal, takes a sequence of actions across tools or systems, and produces an outcome, often without a human in the loop for each step. The practical difference is accountability: the agent's actions have consequences your assistant's suggestions do not.

How much does it cost to move from AI assistants to embedded agents?

It varies too much to quote a single figure, but a bounded first agent tied to one workflow typically costs between $50,000 and $250,000 to build and instrument properly, including API integration, observability tooling, and the data cleanup that almost always precedes it. The build-versus-buy decision shifts those costs toward licensing if a vendor already serves your category.

How do we maintain human oversight once an agent is acting autonomously?

Design approval gates into the workflow before the agent can take irreversible actions, such as writing to a database, sending an external communication, or committing a transaction. Log every decision with enough context to reconstruct why the agent chose it. Most teams start with high human-in-the-loop rates and reduce them as measured error rates fall.

What data quality is required before deploying an agent?

The agent will surface whatever gaps exist in your data faster than any human process did. At minimum you need consistent identifiers across the systems the agent will touch, documented field definitions, and a known refresh cadence. Schema inconsistencies and missing foreign keys that a human analyst works around silently will cause an agent to fail or, worse, proceed incorrectly.

Beyond Copilot, Claude and ChatGPT: Actually Embedding AI Into Your Company

What you get from this article

By the end you will understand what concretely changes when AI moves from assistant to agent inside your systems, what plumbing that transition requires, how to make a defensible build-versus-buy decision at mid-scale, and where to start without creating a project that loses executive support before it delivers anything.

The gap between suggestion and action

Copilot, Claude, and ChatGPT are already part of how your people work. They draft, summarise, and answer questions. That is genuinely useful. It is also the easy part, because nothing those tools do has consequences unless a human reads the output and chooses to act on it.

An AI agent is different in a specific way: it takes actions. It calls your CRM API, updates a record, routes a ticket, triggers a payment, or generates a purchase order. The human is no longer the final relay between the model’s output and your systems. That shift changes three things at once: what permissions you need to grant, how you assign accountability for outcomes, and what your existing infrastructure has to support.

Most organisations discover this gap when a proof of concept that worked in a sandbox meets a production system with inconsistent data, undocumented APIs, and no audit trail. The model was never the bottleneck.

What actually changes when agents act

Permissions become structural, not conversational

When a person uses ChatGPT to draft a supplier email, the person sends it. When an agent drafts and sends it autonomously, your email infrastructure has to decide which systems the agent is allowed to reach, under what conditions, and with what rate limits. That is an access-control problem, not a prompting problem.

You need to scope the agent’s credentials the same way you scope a service account: least privilege, audited, revocable. An agent authorised to read order data should not also have write access to pricing. RBAC and ABAC are the same frameworks you already use for human access; apply them to agent identities before the first production deployment.

Integration is the actual work

Assistants sit on top of your organisation. Agents sit inside it. That means your agent needs reliable, documented access to the systems it will act on, which usually means APIs your internal teams built for other purposes, with undocumented edge cases, inconsistent field names, and no SLA for the agent’s call volume.

APIs, data quality, and orchestration are the three pieces of plumbing assistants never needed. Data quality is the one most teams underestimate. General Mills has run an AI supply chain agent assessing over 5,000 shipments daily since fiscal 2024, generating more than $20 million in savings. That kind of throughput is only possible when the underlying shipment, vendor, and routing data is consistent enough for the agent to reason over it without constant exception handling.

Accountability follows the action

When an agent takes a consequential action and it is wrong, someone has to own that. Define it before deployment, not after an incident. The agent’s decisions should be logged with enough context to reconstruct the reasoning. This is not optional compliance overhead; it is how you diagnose errors and reduce them. Agent observability tooling exists specifically for this: capturing inputs, tool calls, intermediate states, and outputs in a queryable form.

flowchart TD
    A[Trigger: new event in source system] --> B{Agent checks scope}
    B -- Within permissions --> C[Agent calls tool or API]
    B -- Outside permissions --> D[Route to human]
    C --> E{Reversible action?}
    E -- Yes --> F[Execute and log]
    E -- No --> G[Human approval gate]
    G -- Approved --> F
    G -- Rejected --> H[Log and halt]
    F --> I[Outcome recorded in audit trail]

The honest build-versus-buy decision

A mid-size organisation, say 500 to 5,000 employees, with daily Copilot or ChatGPT usage faces a genuine choice when moving to agents: build on a framework, buy a vertical product, or some combination.

The buy case is strongest when a vendor has already solved your category problem with demonstrated integrations. Thomson Reuters did not ask its legal customers to build document review agents from scratch. It shipped CoCounsel Legal, a product that handles multi-step research and review of up to 10,000 documents, grounded in Westlaw content, and embedded into the Microsoft 365 environment legal teams already use. More than 20,000 law firms and corporate legal departments now use it. If you are a legal department, you are not building that infrastructure yourself.

The build case is strongest when your competitive advantage lives in proprietary data or workflows that no vendor product reaches. Morgan Stanley did not buy an off-the-shelf research tool. It built the AI @ Morgan Stanley Assistant over 100,000 proprietary documents, integrated it with advisor workflows, and added a meeting-debrief agent that writes CRM notes and follow-up drafts automatically. Document retrieval efficiency went from 20% to 80%. Synthesis time for multi-report research dropped from over 30 minutes to seconds. Ninety-eight percent of financial advisor teams adopted it. The proprietary document corpus is the moat; a generic product could not replicate it.

The combination is most common in practice: buy or license a foundation model and an orchestration layer, build the connectors and domain logic yourself. Agentic AI frameworks like LangGraph and CrewAI exist specifically to handle the orchestration layer so your team is not writing state management from scratch.

One category worth knowing: tools like Prefactor sit between the framework and the production system, handling agent governance and policy enforcement so teams do not have to wire that into every agent individually.

flowchart TD
    A[Start: identify candidate workflow] --> B{Vendor product exists\nfor this category?}
    B -- Yes --> C{Does it reach\nyour proprietary data?}
    C -- Yes --> D[Evaluate vendor product]
    C -- No --> E[Build connectors\non vendor foundation]
    B -- No --> F{Internal data is\nthe differentiator?}
    F -- Yes --> G[Build on framework\nwith internal data layer]
    F -- No --> H[Re-evaluate: is this\nan agent problem?]
    D --> I[Pilot with one team\nbounded scope]
    E --> I
    G --> I

Where to start without betting the company

Sixty-two percent of organisations are at least experimenting with AI agents, but only 23% are actively scaling, and just 39% report any measurable EBIT impact at the enterprise level, according to McKinsey’s 2025 global survey of nearly 2,000 respondents. The gap between experimentation and value is where most programmes stall.

The pattern that separates programmes that stall from those that compound is the choice of first workflow. Pick one that is:

High frequency. The agent needs enough volume to generate measurable outcomes quickly. Hundreds of events per week beats dozens.
Bounded. The agent’s actions should not cascade into systems you cannot monitor or roll back.
Currently expensive in human time. The baseline cost of the manual process is the denominator for your ROI calculation. Without a real baseline, you cannot prove value.
Already data-complete. Do not start on a workflow where 30% of the inputs are missing or inconsistently formatted. Fix the data first, or pick a different workflow.

Klarna’s customer service deployment is the most cited example of this pattern working at scale. The agent handled 2.3 million chats in its first month, two-thirds of total customer service volume, cutting response times from 11 minutes to under 2 minutes and reducing repeat contacts by 25%. Cost per transaction fell from $0.32 to $0.19 over two years, a 40% reduction, generating an estimated $60 million in annual savings by Q3 2025. Klarna later reintroduced human agents specifically for complex and emotionally sensitive cases, which is a meaningful data point: the agent handled volume, and humans handled judgment-heavy edge cases. That division is not a failure; it is a design.

For a mid-size organisation, the realistic first deployment looks more like one internal workflow than Klarna’s 23-market rollout. A procurement routing agent. An internal IT triage agent. A contract data extraction agent feeding a dashboard. The point is not scale on day one; it is a measured outcome you can show a sponsor within 60 to 90 days.

The plumbing checklist assistants never needed

Before your first agent goes into production, confirm you have answered each of these:

APIs. Which systems will the agent read from and write to? Are those APIs documented, versioned, and rate-limit-aware? If you are relying on screen-scraping or undocumented internal endpoints, that is a dependency risk you should resolve before wiring an agent to it.

Identity and access. Does the agent have a service identity with scoped credentials? Is that identity auditable? Can you revoke it without taking down other services?

Data quality. Run the agent’s intended inputs through a schema validation pass before deployment. Every field the agent will reason over should have a known type, a known null rate, and a documented meaning. Fields that a human analyst interprets charitably will confuse an agent reliably.

Orchestration. How does the agent handle a failed tool call? What is the retry logic? What triggers escalation to a human? Multi-agent systems add a layer here: if one agent hands off to another, the handoff state needs to be durable, not held in memory that disappears if a service restarts.

Observability. You need to be able to answer, after any completed agent run: what was the input, what tools did it call, in what order, what did each return, and what was the final action? If you cannot reconstruct that from logs, you cannot diagnose errors or demonstrate compliance. Implement agent observability before you scale, not after.

Governance. Only one in five companies currently has a mature governance model for autonomous agents, per Deloitte’s survey of over 3,200 leaders across 24 countries, even as deployment rates rise sharply. Define who approves the agent’s scope, who reviews its error rate, and at what threshold a human takes back control, before the first production run.

Proving value before sponsorship runs out

Executive sponsors have a shorter patience horizon than engineering timelines. The fix is not to move faster; it is to instrument your pilot so you can report a real number within the first four weeks.

Pick a metric your sponsor already tracks: cost per transaction, time-to-resolution, hours of analyst time per output. Measure the manual baseline for two weeks before the agent goes live. Report the agent’s number against that baseline, with the error rate alongside it. A number with an honest error rate is more credible than a clean number with no context, and it signals that you are running this as an engineering programme, not a demonstration.

When the first workflow is measured and stable, the case for a second is already made. That is how Walmart’s agentic programmes expanded: the Trend-to-Product multi-agent system, which compresses fashion production timelines by up to 18 weeks, did not emerge from a single grand deployment. It emerged from a series of connected investments in internal data infrastructure and agent tooling that made each successive system cheaper to build than the last.

The compounding effect is real, but it starts with one workflow, bounded, measured, and reported honestly.

Where to start

If you are unsure which workflow to pick first, or whether your data and API layer is ready to support an agent at all, the right move is to assess your current state before committing budget to a build. Take the agent readiness assessment to get a concrete picture of where your organisation sits across data quality, integration readiness, and governance maturity, and what to address first.

In this series

Build vs buy for your first production agent