Your Agent Worked in the Demo. Now What?

The agent works in the demo. It answers the questions, uses the right information, completes the intended action. Users can see how it’ll help, and the capability moves into production. Then a policy changes, a connection expires, a model gets upgraded, or the person who configured it moves on. The agent may still be sitting there, still getting relied on more and more, but being available isn’t the same thing as being operated.

The previous article covered the organizational context an intelligent capability needs to trust. Run asks how that context, the capability’s authority, and its behavior stay dependable once people actually start using it in everyday work. A successful demo proves that selected scenarios can work under controlled conditions. It doesn’t prove they’ll stay reliable as information, permissions, tools, users, and business purpose all keep evolving.

As building gets easier, this distinction matters more, not less. Business teams can configure agents, vendors can drop them into existing applications, technology teams can assemble them from reusable parts. The constraint shifts. It’s no longer about whether the organization can build something useful. It’s whether it can manage a growing population of intelligent capabilities embedded in real work.

Useful agents can become unmanaged assets

Enterprise technology has been down this road before. Spreadsheets, SaaS, cloud platforms, low-code tools, each one made useful capabilities easier to create or acquire. Each one produced real value, and eventually, a pile of assets whose ownership, dependencies, and continued purpose became genuinely hard to explain. Making something easier to create never removed the need to manage it. It just increased the number of things that needed managing.

AI is likely to make this worse, because an agent can look valuable fast without looking anything like a conventional application. A business team builds one for a workflow. A platform vendor adds another. A second function solves basically the same problem without even knowing the first capability exists. The risk isn’t that they all fail. It’s that plenty of them work just well enough to stick around while the organization loses track of what they do, what they trust, what authority they carry, and who’s actually still responsible for them.

The capability changes even when the code does not

Traditional software has always needed maintenance, but intelligent behavior isn’t defined by code alone. An enterprise agent can depend on instructions, model behavior, retrieval logic, knowledge sources, permissions, tools, workflow rules, and whatever context gets supplied at runtime. A real change to any one of those things can alter how it reasons or acts, even when nobody has touched the application in the conventional sense.

A changed property in the CRM platform can break an action. A model upgrade might improve reasoning while quietly changing how an instruction gets interpreted. A new knowledge source might conflict with something the agent used to trust. An additional tool might stretch its authority past whatever assumptions the original review was based on.

None of this is inherently bad. It’s often exactly how a useful capability gets better. What operating requires is knowing when a change happened, what it touched, and whether it shifted behavior, risk, or value. Production AI is better treated as a living operational capability than as some finished configuration you hand over at the end of a project.

Ownership has to cover the whole capability

The name of whoever first built or configured an agent is rarely a good enough answer to who owns it. A technical team might understand the platform without owning the business outcome. The business might understand the work without being able to manage connections, model changes, or security. Both kinds of responsibility matter, and neither one should just be assumed based on who happened to build the first version.

A workable model needs a business owner who’s accountable for the capability’s purpose and whether it keeps improving the work. It also needs technical stewardship: someone who actually understands its configuration, models, tools, knowledge, permissions, and change process. Those responsibilities can sit with different people. They just need to stay connected once the original implementation team has moved on.

Security, data, platform, risk, and compliance teams get involved based on how consequential the use case actually is. Knowledge sources may have their own owners, and a process owner may need to sign off on changes that alter how work gets done. The principle here matters more than any universal role chart: a production capability shouldn’t become a piece of intelligence that a lot of people rely on and nobody actually owns.

Monitoring must include behavior and value

Traditional application monitoring starts with availability: is the service running, did the connection complete, did the transaction succeed. Those measures still matter, but an agent can be technically healthy while quietly becoming less useful or less trustworthy. It might answer every request using stale information, invoke a tool successfully while misunderstanding when it should even be used, or produce fluent responses that employees gradually stop believing.

A mature operating view covers technical health, information health, behavioral health, and business health, all four. The capability needs to stay available, grounded in maintained sources, acceptable across realistic scenarios, and connected to an outcome the organization still actually values. Whether it responds is a different question from whether its contribution is still appropriate.

Repeatable behavioral testing is what makes that distinction practical. For an agent that identifies customer risk, the organization should keep examples of what it should recognize, what it should ignore, which sources it should use, and when it should just admit uncertainty. For employee-policy questions, testing should cover the common cases, the ambiguous ones, and the inappropriate ones, including situations where the user doesn’t actually have the authority to receive that information.

How rigorous the evaluation needs to be should track the consequence. A low-risk internal assistant doesn’t need the same controls as a capability that’s initiating financial or employment actions. The point is to stop model upgrades, instruction changes, new knowledge, and additional tools from turning every production change into an uncontrolled experiment on the people actually using the system.

Knowledge, permissions and process all drift

Anchor made the case for why intelligent systems need authoritative organizational context. The operational consequence of that is the context has to be maintained. Policies get replaced, organizational structures shift, contracts get amended, local teams create document versions that look current even when they aren’t. Connecting an agent to a repository solves access at one point in time. It doesn’t guarantee its sources will stay trustworthy.

Permissions drift in pretty much the same way. An agent starts with read-only access, later gets permission to create a note, picks up another tool because a useful opportunity comes along. A new user population gets added. A security role gets broadened to fix a connection problem. Each individual change can seem reasonable, and the cumulative authority ends up materially different from whatever got originally approved.

Business change adds one more obligation on top of that. When a policy, process, security model, or authoritative source changes, the affected agents are now part of that change too. Their instructions, tools, grounding logic, tests, or permissions may need to change right alongside employees and conventional applications. Starting out as an innovation experiment doesn’t earn a permanent exemption from normal operating governance.

The relationship between purpose, knowledge, and permission has to stay visible. The organization should be able to explain what the capability currently does, what it currently trusts, and why its authority is still necessary. Authority can grow as evidence builds up, but it also has to be able to shrink when the use case or the risk changes.

Incidents will not always look like software failures

Some incidents will look familiar: authentication fails, a connection breaks, a transaction doesn’t complete. The harder cases show up when the behavior is technically explainable but organizationally wrong. The system might interpret an ambiguous instruction differently than the business meant, lean on a source that’s accessible but not actually authoritative, or surface an inference that should never have reached that particular user.

Investigating those events takes enough evidence to reconstruct what actually happened: the user’s request, the instructions and policy in force at the time, the sources retrieved, the tools invoked, the permissions applied, and the resulting answer or action. The goal isn’t unlimited logging. It’s enough visibility into consequential behavior while still respecting privacy and security requirements.

Users also need a clear way to flag when something’s wrong. Without one, failures just disappear into workarounds. Employees correct outputs by hand, stop trusting the agent, or quietly go back to the old process, while the organization assumes everything’s running fine. A dependable operating model connects those reports to actual investigation and turns recurring incidents into improvements in design, knowledge, testing, or training.

Scale requires visibility, not uniform bureaucracy

As the number of agents grows, organizations need some kind of inventory of production capabilities. That doesn’t mean every experimental prompt or personal assistant belongs in a giant governance database. Control should track consequence, reach, and dependency. Once a capability touches important enterprise information, does material work, or serves a significant population, it needs to show up as a real organizational asset.

Leaders should be able to say what it does, who owns it, who can use it, which systems and knowledge sources it depends on, what authority it carries, and how its behavior gets evaluated. That visibility surfaces duplicate agents, shared dependencies, and aging sources. It lets a platform or security change get assessed before several capabilities quietly break, and it helps spot when a local solution should really become a shared service.

Responsibility can stay distributed without becoming fragmented. A fully centralized AI team tends to become a bottleneck, because the business context lives elsewhere. A completely distributed model tends to fragment security, testing, architecture, and support. A more practical split keeps purpose and outcome with the business, common controls and infrastructure with platform, data, and security teams, and reusable patterns and evaluation methods with a specialist AI capability.

Similar operating models already exist around enterprise applications, analytics, integration, and cybersecurity. The goal is to make common things common while keeping domain ownership close to the work. Experimentation should stay easy. Production should create responsibility.

Retirement belongs in the lifecycle

An agent might stop creating value. Its function might become native to an enterprise platform. The process might get redesigned, or another capability might absorb its purpose. Users might just stop needing it. None of that makes the original experiment a mistake, but it does mean someone has to decide whether the asset should keep existing.

Retirement means more than just hiding an agent from the interface. Permissions and connections need to be removed, operating records preserved where it makes sense, dependencies identified, and users told what replaces it. An unnecessary agent can still hold onto authority, keep relying on changing information, confuse users, and create maintenance work. The lifecycle should treat stopping work as seriously as it treats starting it.

Make the operating commitment explicit

For a meaningful production capability, leadership should be able to name the business owner and the technical steward, explain the important dependencies, and describe how appropriate behavior gets evaluated. It should also be clear how changes to models, instructions, knowledge, tools, and authority get introduced. How consequential the work is should determine which changes require testing, review, communication, or renewed approval.

That commitment covers what happens when something goes wrong, and what would justify redesigning, replacing, or retiring the capability. Users need a way to report problems, owners need enough evidence to investigate, and the organization needs a way to act on what it learns. None of this is some brand-new management discipline. It’s familiar responsibility applied to a capability whose behavior can change through more than just conventional software development.

Easy to build does not mean easy to operate

The first generation of enterprise AI has naturally focused on creation: what can be built, which platform to use, how quickly something useful can be demoed. As models improve and reusable tools get more accessible, creation alone stops being much of a differentiator. The harder test is whether the organization can keep useful intelligence dependable after the demo has ended.

Production discipline isn’t just the bureaucracy that follows innovation. It’s how a promising experiment turns into a capability the organization can actually rely on, improve, and eventually replace. Run keeps purpose, authority, context, behavior, and value aligned as both the capability and the enterprise keep changing. The demo proves something is possible. Operation determines whether the organization can actually depend on it.