Picture a customer-service manager trying to shorten the time it takes to resolve routine account problems. A vendor shows her an AI agent that can read a customer's request, look up the account, check the company's policy, update a record and prepare a reply. It does the whole thing in a minute.

During the demonstration, everyone is impressed.

Then someone from IT asks a less exciting question: "What account is it using to make those changes?"

The sales representative explains that the agent has access to the same system as a customer-service employee. That raises a few more questions. Can it change any account, or only the one attached to the request? Can it issue credits? What happens if it misunderstands the policy? Is there a record of what it changed? Can someone stop it halfway through?

The conversation has suddenly become much more useful.

AI agents have moved well beyond the novelty stage. They can plan a sequence of steps, work through documents, use software tools and, in some cases, make changes in business systems. Coding agents are already part of many developers' daily routines. Other teams are experimenting with agents for research, reporting, IT support and internal operations. The commercial opportunity is genuine, though the evidence is uneven across industries and tasks.

The question for a business in late 2026 is how to make use of these capabilities without creating a new kind of operational mess.

The enthusiasm has some substance behind it

In its August 2026 global AI survey, McKinsey reported that 40% of respondents at large organizations said their companies were scaling AI agents, up from 27% the year before. Among smaller organizations, the reported share scaling agents was 22%. Software development stood out: about one in five respondents overall reported scaling coding agents. [1]

That does not mean 40% of all large businesses have successful autonomous systems running their operations. It means the surveyed organizations reported reaching a particular stage of rollout. Still, the direction is clear: more companies are trying to turn agent demonstrations into repeatable work.

A June 2026 LangChain survey of more than 1,300 professionals found that 57% of respondents reported agents in production. Its audience included people interested in agent engineering, so it should not be treated as a representative survey of every business. More revealing was the obstacle they described. Output quality was the leading barrier, cited by 32% of respondents. [2]

The gap between a promising demonstration and a reliable process is now one of the defining problems of agentic AI.

Researchers have also begun examining what working agents actually do. In Measuring Agents in Production, presented at ICML 2026, researchers combined 20 case studies with a survey of practitioners responsible for 86 deployed systems across 26 domains. They found that 68% of the systems ran no more than ten steps before human intervention, and 74% relied primarily on human evaluation. Reliability was the leading development challenge. [3]

That is a useful picture of the present. Many production agents are fairly restrained. The people running them have good reasons to keep them that way.

First, decide whether the job needs an agent

The word agent is being attached to so many products that it has become a poor guide to what a system can do. A chatbot that answers a question, a scripted automation that moves an invoice and a tool-using system that decides its own next step may all appear under the same marketing category.

For a manager evaluating a workflow, it helps to separate four approaches.

Approach What it does A sensible example
Traditional automation Follows known rules and steps Route invoices based on a purchase-order number
AI assistant Helps a person research, draft or decide Summarize a contract or explain an unfamiliar error
Fixed AI workflow Uses AI inside a defined sequence, with specified checks Extract data from incoming forms, validate fields, then queue an employee review
AI agent Chooses and carries out multiple context-dependent steps using tools Investigate a support problem across several systems, gather evidence and propose or perform bounded actions

An agent earns its place when the work involves uncertainty that cannot be handled comfortably by a fixed sequence. It may need to look at the result of one step, decide what to investigate next and select another tool.

Consider a finance team that receives invoices in many formats. Extracting fields from those documents and matching them against purchase orders can often be handled with a structured workflow. Letting an autonomous agent invent its own payment process would add little value and a great deal of risk.

Now consider an IT service desk dealing with vague reports such as "The application has been slow since yesterday." An agent could examine recent deployments, correlate logs, check service health and assemble a diagnostic summary. The next step depends on what it finds. That may be a reasonable agent use case, especially when the agent begins with read-only access and an engineer decides whether to apply a fix.

The NIST AI Risk Management Framework encourages organizations to evaluate whether an AI system serves its intended purpose and whether its benefits justify its risks. Its framework is built around governing, mapping, measuring and managing risks throughout the lifecycle. [4]

That's a sound purchasing discipline too. Ask the team to compare an agent with a simpler integration, a better form, conventional automation or an assistant that keeps a person in charge.

The jobs and tasks where agents are already useful

Software development is the clearest early example. Coding agents can inspect a codebase, modify files, run tests, find failures and try again. That is substantially different from an assistant that suggests the next few lines of code. McKinsey's 2026 survey and Anthropic's research on actual agent use both identify software engineering as a major area of activity. Anthropic reported that software engineering accounted for nearly half of the agentic tool-use activity it observed on its public API, with the important caveat that its data reflect its own platform rather than the whole market. [1, 5]

There are promising opportunities elsewhere, although deployment claims outside engineering deserve more scrutiny. The useful unit of analysis is usually the task, because two people with the same job title may do very different work.

Customer service. Agents may help investigate an order problem, gather information scattered across systems and prepare a resolution. Starting with recommendations or draft actions gives the organization time to learn where exceptions occur before allowing the system to make customer-facing changes.

IT operations. Agents can collect diagnostics, review incident timelines or open well-formed tickets. Restarting a production service, rotating credentials or changing access permissions calls for stronger controls than producing a report.

Finance and procurement. They can reconcile discrepancies, follow up on missing records and assemble evidence for review. Releasing payments, changing vendor bank details or approving unusual transactions should face a different standard from flagging inconsistencies.

Sales and account management. An agent might prepare account research, summarize CRM history and draft a follow-up. Sending emails, changing customer commitments or updating commercial terms adds external consequences that a manager needs to consider separately.

HR and internal services. Agents can answer routine policy questions, organize requests and prepare onboarding materials. Employment decisions, sensitive personnel data and access to confidential records raise issues that make uncontrolled autonomy a poor starting point.

Research and analytics. Agents can search sources, run analysis tools and prepare a first report. Somebody still needs to check the data, assumptions and conclusions before the findings influence a major decision.

These are illustrations of plausible use cases, not evidence that every example will produce a positive return. A well-designed trial would establish the benefit in the actual workplace, using representative cases and the company's own error costs.

The new management problem is deciding what the agent can do

A person who summarizes a customer complaint can make a mistake. If an agent can also edit the customer's account, that mistake can travel further before anyone notices.

It helps to distinguish three levels of independence:

  • Current autonomy: the actions the system is actually able to perform today.
  • Desired autonomy: the actions its owner wants it to perform eventually.
  • Supported autonomy: the independence that the existing permissions, evidence and safeguards reasonably justify.

Those levels can be different, and sometimes they should be.

Imagine an IT team that wants an agent to solve straightforward access problems. Today it can read tickets and draft a response. The intended end state is an agent that changes user permissions directly. But the team has not built a reliable approval check, does not know whether tool calls are fully logged, and has no tested way to halt an operation halfway through.

It may be appropriate to continue using the agent to investigate and propose changes. Granting write access can wait until the safeguards are ready. The project has still delivered something useful.

That distinction appears in practice. In Anthropic's February 2026 analysis of millions of interactions with its own tools and API, experienced users increasingly allowed coding agents to act without approving every step, but they also interrupted agents more often. The longest-running sessions were becoming longer, yet most turns remained short. [5]

Human oversight is changing from a series of clicks on every small action to a more selective process of reviewing consequential work, watching exceptions and intervening when needed. That transition demands good visibility. A manager cannot supervise a system whose actions are difficult to reconstruct.

Giving an agent access is a much bigger decision than giving it a prompt

The practical risks are easier to understand when you ask what the agent can touch.

An agent that reads a knowledge base has one kind of authority. An agent that edits files, executes code, sends messages, changes a CRM record or calls another agent has quite another. Scheduling or event-triggered execution adds another dimension: work can begin without an employee explicitly starting each run.

Connections often arrive through APIs, browser sessions and newer tool protocols such as the Model Context Protocol (MCP). MCP provides a common way to connect AI systems to tools and data sources. Its July 2026 authorization specification addresses authorization for HTTP-based servers, including guidance about requesting only the scopes required for an operation. The protocol itself does not decide which business actions an organization should permit. [6]

An example makes this concrete. Suppose a research agent can read customer records and create a weekly summary. If it also has permission to send email, a malicious instruction hidden in a retrieved document might try to trick it into forwarding customer data elsewhere. The instruction is untrusted content, even if it appears inside a document from a familiar repository. An approval prompt alone may be inadequate if the permission system lets the agent perform the action automatically.

The OWASP Top 10 for Agentic Applications, released for 2026, identifies risks including agent goal hijacking, misuse of tools, identity and privilege abuse, compromised memory and cascading failures. OWASP also published an Agent Control Standard in September 2026 as organizations sought more operational guidance. [7, 8]

The basic safeguards are not mysterious. Give an agent a separate identity where possible. Limit it to the data and operations its assignment requires. Make consequential actions reviewable. Keep an audit trail of tool calls and outcomes. Set limits on runtime, expense and repeated actions. Have a tested way to revoke access or stop the run.

Some situations also require isolation. An agent that can execute code or inspect outside websites should not automatically inherit broad access to a company's production infrastructure. Nor should an agent be allowed to hand work to another agent that quietly has more authority than the first one.

None of this requires treating every agent as equally dangerous. Reading a public report and sending money from a company account deserve very different controls.

Reliability remains the hard part, even when the model is impressive

Agent demonstrations typically show a successful path. Real workflows have damaged files, conflicting instructions, incomplete data, strange exceptions and customers who provide information in the wrong format.

In LangChain's 2026 survey, nearly 89% of respondents reported some form of agent observability, while about 52% reported offline evaluations and 37% online evaluations. The survey is self-selected, but the difference is revealing: watching what happened and proving that a system handles representative cases are distinct activities. [2]

Consider a scheduling agent that books service appointments. It may handle normal requests beautifully. The real tests are things such as a customer changing the appointment twice, an unavailable staff member, two systems disagreeing about availability, or a confirmation email failing after the booking record was updated.

The test should include the work that usually goes wrong. Can the agent identify inconsistent records? Does it stop instead of guessing? Can a human see which step failed? If a task is retried, does it avoid making the same booking or charge twice?

A business owner should care about the full result, not simply whether the model answered correctly. Useful measures include successful completion, correction and rework time, exception rates, processing cost, customer impact and the time a human spends supervising it.

If a task takes three minutes for a person and the agent needs two minutes plus four minutes of supervision and repair, the automation has not made that task faster. It may still have other benefits, but the pilot should reveal the trade-off.

A related question is whether agents actually change the organization's capacity. Saving ten minutes for an employee does not automatically produce ten minutes of financial benefit. The time has to be recovered, reassigned or used to improve an outcome that matters. That's why reported productivity gains are a starting point for measurement, not an ROI calculation on their own.

Put the right people in the room

A business owner usually knows why a workflow matters. They know what counts as a useful result and what a mistake might cost. They may know little about an agent's credentials, network access or tool-call logging.

An engineer or IT operator can explain how it connects to internal systems, what it can execute, how memory works and how to disable its access. A security, privacy or governance reviewer can challenge the permissions and review evidence for the most consequential risks.

Treating those as separate responsibilities makes the evaluation more honest.

If the operations manager does not know how credentials are stored, the answer is "technical review pending." It should not become a zero that suggests the manager is incapable, or a guessed "yes" that makes the project look ready. If the engineer also cannot establish the answer, the control is genuinely unknown and needs investigation.

For larger projects, a short register of the agent's components helps. Include the models, tools, connected data stores, memory, identities and any other agents involved. Each connection may carry permissions or failure modes that the person requesting the solution never encounters.

One accountable owner should still be able to answer the ordinary business question: "If this agent makes a mistake tomorrow, who gets the call?"

Start with a narrow pilot, then earn more autonomy

A useful pilot can begin without allowing the agent to change anything. Give it read-only access, a realistic set of tasks and a human reviewer who records what happened. Choose examples that represent ordinary work, along with cases where the answer is ambiguous or the proper action is to stop.

Before running the trial, write down what success looks like. Include acceptable error rates and the kinds of actions that must always require approval. Decide who will review surprising behavior and what evidence will be retained. Use reference IDs or sanitized traces where possible; avoid collecting raw customer data or credentials merely because they are convenient for debugging.

Then widen the system in stages. An agent might progress from gathering information, to drafting proposed actions, to taking limited reversible actions after approval. Some low-consequence tasks may eventually justify automatic execution inside explicit boundaries. Other workflows may remain at the draft stage indefinitely because that is the appropriate arrangement.

NIST's Generative AI Profile offers risk-management actions that complement this approach. It is guidance for evaluating and managing risk, not a certification that any particular agent is safe. [9]

Four outcomes are all perfectly reasonable after a serious review:

  1. Proceed with a bounded next step where the use case and controls are clear.
  2. Pilot with additional controls when the benefit is plausible but the evidence is incomplete.
  3. Redesign the workflow when a simpler automation, narrower permission set or stronger human handoff would be better.
  4. Seek specialist review where legal, safety, privacy or security consequences exceed the project's normal expertise.

A useful decision records the reason. "Needs a tested rollback mechanism before it can update records" is far more actionable than "AI readiness: 63%."

The European question: what does the AI Act change?

For businesses operating in the EU, the AI Act is part of the governance discussion. It follows a risk-based approach. Obligations depend on what the AI system does, where it is used and the people or interests it affects. Calling something an agent does not automatically place it in a particular legal category.

As of October 2026, several provisions already apply, including AI-literacy obligations and certain prohibitions. Under the 2026 amendments, important high-risk provisions for specified stand-alone systems are scheduled for December 2, 2027, with separate timing for AI embedded in regulated products. The European Commission's implementation guidance and the European Parliament's October 21, 2026 implementation update are appropriate places to check the current schedule. [10, 11]

A service-desk assistant that suggests answers and an agent used to make employment decisions pose different questions. A company should document the specific use case and seek qualified advice when the intended deployment affects employment, safety, access to essential services or other regulated matters.

Good operational controls are valuable regardless of whether a particular use falls under a high-risk category. Having an owner, known permissions, meaningful testing and a route for reporting incidents also makes ordinary business sense.

One company's agent problem can reveal a company-wide weakness

Imagine that three departments independently build agents. The sales team wants access to CRM records. Finance wants to update purchase-order information. IT wants to automate routine tickets.

Each project appears to have its own problems. Yet all three teams struggle to identify a safe service account, cannot easily review tool actions and have no shared process for disabling an agent during an incident.

That suggests the company needs a reusable approach to agent identity, logging and interruption. Solving those issues once may help more than writing three separate policies that nobody uses.

The same logic applies to evaluation. If every team invents its own definition of success, the organization cannot distinguish a genuinely effective workflow from a technically impressive one that produces more checking work. A shared evaluation template, tailored to each task, is often a better investment than another demonstration.

This is one reason agent governance should include both the individual workflow and the broader organization. A company can have sensible AI guidance overall while a particular agent still has excessive permissions. The reverse can happen too: a careful, low-risk pilot may succeed before the organization has a mature enterprise-wide program.

A practical way to make the decision

The next time someone proposes an agent, ask them to walk through a real case from beginning to end. Avoid the polished demonstration if you can. Use something with missing information or an unusual exception.

What work is the company trying to improve? How often does it occur, and what does an error cost? Would an ordinary integration solve most of it? What will the agent read, and what could it change? Which actions need approval? Who can see what happened and stop it? How will you measure the result, including the time spent supervising and correcting it?

These questions give an operations leader, an engineer and a security reviewer something concrete to discuss. They also make it possible to say "yes" to a useful part of the project even when full autonomy is premature.

AI agents are becoming more capable and more common. Companies will learn a great deal by giving them bounded, measurable work to do. The ones that benefit most are likely to be those that get good at choosing the right work, learning from mistakes and granting additional authority only when the evidence warrants it.

How Behaviture approaches agentic AI

Behaviture's Agentic AI Readiness methodology is designed to examine workflow opportunity, solution fit, organizational readiness and appropriate autonomy as separate decisions. It considers both agent-enabled work and simpler alternatives, such as ordinary automation or an AI assistant. Where available, its workflow-level assessment captures business-owner, technical and governance declarations, highlights unresolved controls and explains what would need to change before a broader pilot.

Those findings depend on what an organization reports and the evidence references it supplies. They are decision support, not a live security test, regulatory certification or permission to deploy an agent.

For a broader look at how employees are using AI, where they encounter barriers and which workflows may merit closer attention, visit Behaviture.

Sources and further reading

  1. McKinsey & Company (August 25, 2026). The state of AI in 2026: On the road to ROI. Survey results covering organizational AI deployment, agent scaling and coding-agent use. https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai
  2. LangChain (June 12, 2026). State of Agent Engineering. Survey of 1,300+ professionals; vendor-run, self-selected research on production usage, observability and evaluation practices. https://www.langchain.com/state-of-agent-engineering
  3. Pan, M., et al. (2026). Measuring Agents in Production. Proceedings of the 43rd International Conference on Machine Learning, PMLR 306. Includes 20 case studies and a survey of practitioners responsible for 86 deployed systems. https://proceedings.mlr.press/v306/pan26a.html
  4. National Institute of Standards and Technology. AI Risk Management Framework (AI RMF 1.0) and AI RMF Playbook. Voluntary framework and guidance for evaluating appropriate uses and managing AI risks. https://www.nist.gov/itl/ai-risk-management-framework
  5. Anthropic (February 18, 2026). Measuring AI agent autonomy in practice. Observational research on Claude Code and public API tool use; findings are specific to the observed platforms. https://www.anthropic.com/research/measuring-agent-autonomy
  6. Model Context Protocol (July 28, 2026). Authorization specification. Security and authorization requirements for compatible HTTP-based MCP implementations. https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization
  7. OWASP GenAI Security Project (December 2025; 2026 edition). OWASP Top 10 for Agentic Applications. Risks and defensive guidance concerning agentic workflows. https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
  8. OWASP GenAI Security Project (September 2026). OWASP GenAI Security Project releases 2026 LLM Top 10 and Agent Control Standard. https://genai.owasp.org/2026/09/01/owasp-genai-security-project-unveils-2026-top-10-for-llm-applications-new-agent-control-standard-and-sponsors-as-community-tops-30000-members/
  9. Autio, C., et al. (2024). Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. NIST AI 600-1. https://doi.org/10.6028/NIST.AI.600-1
  10. European Commission (2026). AI Act: Shaping Europe's Digital Future. Official guidance including the amended implementation schedule. https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
  11. European Parliamentary Research Service (October 21, 2026). AI Act – Implementation timeline. https://eprs.europarl.europa.eu/contents/publications/EPRS/2026/10/EPRS_ATA%282025%29772906.html?locale=EN

Editorial note: The workplace examples are illustrative, not documented customer deployments. Survey results describe their respective samples; they should not be read as population-wide adoption rates. The article reflects guidance and available research as of October 24, 2026.