From Proof of Concept to Production: Agents as Process Participants

Share
From Proof of Concept to Production: Agents as Process Participants

A controlled demo proves that an agent can complete a staged task. It does not prove that the agent can be trusted inside a changing business process.

The data is cleaner in a demo. The process is narrower. The scope is narrowly defined. The edge cases are mostly out of view. In the business, customers send strange inputs, teams work around missing data, policies change, and systems disagree with each other. The documented process and the actual process are often close cousins, not identical twins.

That is the mistake enterprise leaders need to avoid as every SaaS vendor brings agents into their products: evaluating agents as features when they should really be viewed as process infrastructure.

Deloitte's 2026 State of AI in the Enterprise report found that only only 25% of organizations have moved 40% or more of their AI pilots into production. Only a fraction of enterprises are moving successfully from pilot to production. Getting AI to work in a controlled setting is one thing. Getting it to hold up inside the business requires process ownership, context, monitoring, and boundaries.

The higher the risk related to the work the agent is doing, the more the SaaS vendor needs to prove before the agent gets operational authority.

Does the Agent understand how work actually happens?

How work happens, not just at the vague process map level, you know, the one the team created 12 months ago. I'm talking about how it really happens, the corner cases, the hidden factories of work, the relationships, the business rules.

For an agent to go any wider than a single team or individual process, and I'm not talking about the Level-1 process maps, it needs to be able to navigate not only complex technical questions but also organizational goals, implied boundaries, relationships, and business rules.

Most of the SaaS agents you'll come across understand the software they live inside. They can read records, summarize activity, and trigger actions inside the application. Useful, but it's typically only one slice of the actual work.

A real customer workflow, approval path, claims process, revenue motion, or contract review includes policies, exceptions, customer history, handoffs, workarounds, and judgment. Some of that context lives in the system of record. Much of it does not.

Deloitte found that only 30% of organizations are redesigning key processes around AI, while 37% are still using AI at a surface level with little or no change to the underlying process. This is where the numbers start to show that organizations aren't yet seeing the returns from their investment. An agent cannot reliably support a workflow the organization has not made clear, at least not at scale.

This is where demos can overstate what is happening. The agent understands the fields in a CRM record, the status of a ticket, or the metadata attached to a contract. That still leaves the harder question: does it understand how the company actually makes the decision?

The right test to use is whether the vendor can explain the business context the agent uses when deciding what to do. Which customer segments matter? Which approvals are meaningful? Which exceptions are routine? What related information is actually important?

Without deep organizational context, the agent is just a helpful assistant. What you're looking for is a reliable participant in the process.

Who can see what the Agent is doing?

If an agent participates in a workflow, humans need to see what the agent is doing.

That means more than an activity log. Business leaders and agent managers need to know what information the agent used, where it escalated, where it failed, and whether the process is improving or degrading over time.

Without that level of visibility, the agent becomes another opaque failure point in the workflow. It can end up reducing manual work while making the overall process harder to manage or producing lower-quality outcomes.

The lack of maturity across the enterprise shines through the thin sheet of annual planning, with governance as the typical afterthought. Deloitte found that close to three-quarters of companies plan to deploy agentic AI within two years, but only 21% report having a mature model for agent governance. McKinsey’s 2026 AI Trust Maturity Survey similarly found that only about 30% of organizations have reached a mature level in strategy, governance, and agentic AI controls.

The numbers are important because trust isn’t just a human feeling. It’s an operating capability. If a leader cannot see how the agent is affecting throughput, quality, cycle time, risk, and rework, the organization isn’t really managing the process.

The question to ask here is whether the vendor can make the agent’s work legible.

What happens when the process changes?

Processes do not hold still. Your organization is probably spinning up a big initiative with large teams that you’re either on or being told to “be more AI-forward,” “more agentic,” or however it’s being internally marketed. This is going to bring a wave of changes to your process at one level or another.

Policies are going to change. Teams are going to continue to reorganize. Systems will get replaced. Edge cases and workarounds accumulate while the “AI team” is moving fast. The IT team is likely sending you monthly emails about new AI tools that are being introduced and that you should now use in your daily work. A workflow that looked clean during the initial implementation can behave differently three months later.

Agent drift is when an AI agent starts behaving differently from the way it was originally intended or tested.

The agent may have been aligned when it was configured. Then the business changes, and the agent quietly keeps operating against yesterday’s reality. Or a new model comes up that is more sensitive to prompts. Now the agent doesn’t respond in the same predictable way, and no one knows why.

A report published by Infosys found that only 14% of enterprises have scaled agentic AI, only 16% have deployed it enterprise-wide, and 60% say their most advanced agents still perform rules-based tasks rather than autonomous decision-making. As a side note, if you’re using agents to execute rules-based tasks, congratulations, you’ve made RPA more expensive.

I’m not saying that RPA or more “agentified” rules-based automation is bad. It has its place in the enterprise stack. The issue is buying something as an adaptive agent when the underlying system doesn’t have the ability to deliver on its commitment once it’s out of the POC stage.

If the system, meaning the agent plus governance, doesn’t have a durable representation of how the process should work, it will struggle to know when the agent has begun to “drift” from its intended alignment.

Where can the agent act on its own?

Permissions are where trust in the agent becomes operational.

There is a big difference between an agent that can observe, recommend, draft, execute a reversible action, execute an irreversible action, communicate externally, move money, or alter a customer or contract record.

The agent needs its own access, with specific roles and scopes that limit what it can do. This is how you prevent unintended actions, like deleting emails or sending messages outside the right boundary. My OpenClaw agent kept trying to email my now-manager, Emmanuel, even after I repeatedly told it not to. Emmanuel never got a response from Jeeves, my agent, because I kept its scopes intentionally narrow.

Other examples of managed agent access include giving an agent that suggests account research a different authority level than an agent that approves an invoice, changes a contract field, sends a customer message, or closes a compliance exception.

The broad use of “human-in-the-loop” (HITL) is too vague when you’re identifying the points in a process where a human needs to make or confirm a decision. A more useful version of HITL is specific about:

  • Which decisions stay human-owned
  • Which steps are delegated to an agent
  • Which actions need approval
  • Which exceptions require escalation

If the permission model isn’t clear, teams will either over-trust the agent or route around it. Both outcomes weaken the investment and reduce trust in AI’s ability to be a reliable participant in the process.

Standards rise with the risk

Some SaaS agents will be narrow productivity features, for example Slack agents or Notion agents. Others will become part of important operating workflows. These are significantly different use cases, so they can’t be evaluated by the same standards.

One is a productivity tool. The other is a process participant.

I talk daily to the world’s largest companies about how they’re using AI to transform their companies, including the successes and the failures. The organizations seeing the most success understand that their people and processes are the most important assets they have. They’re not just handing out Claude Cowork or OpenAI Codex/ChatGPT licenses like candy. They’re investing in redefining how their business operates so it can be understood by both humans and agents.

BCG’s 10/20/70 rule is a useful reminder: AI models are 10% of the work, the technology backbone is 20%, and the people and processes make up the remaining 70%. This is especially true when software is being trusted to participate in the work.

There’s a simple test to apply: the higher the process risk, the more the agent vendor should prove context, visibility, adaptation, and permission boundaries before the agent gets operational authority.

Don’t get me wrong, demos and proofs of concept still matter. They’re incredible opportunities to build institutional knowledge about how your company uses AI. Even the failed experiments force your team to flex their AI muscles.

One of my favorite qualities about AI and agentic technology is how personal it is.. Personal to the individual. Personal to the team. Personal to the organization.


Written by JD Fetterly

Senior AI Strategy & Value Deliver Manager @ Klarity.ai

Founder of ChatBotLabs.io, creator of GenerativeAIexplained.com, Technology Content Creator, AI Enthusiast, lover of Open Source Software.

If have thoughts on the article, want to talk about your companies AI transformation, building Enterprise-grade agents or want to figure out where to get started on your AI journey shoot me a message!