← Writing
AI StrategyLeadership

AI Agents Are Not Your IT Project

Every conversation I have with a mid-market CEO eventually lands in the same place: "We need to do something with AI." What they mean, almost always, is that they want the efficiency gains without the transformation risk. The problem is you cannot have one without the other.

Ryan Hopf··6 min read

Most AI deployments fail for the same reason most ERP projects fail: the organization treats a people-and-process change as a technology problem.

When a company installs an AI agent to handle customer inquiries, they are not automating a task. They are restructuring who owns the relationship with the customer, what information flows where, and how the team defines success. If leadership does not see it that way from day one, the tool gets adopted awkwardly, stalls, or gets quietly abandoned after six months.

What an agent actually is

An AI agent is a piece of software that perceives its environment, makes decisions, and takes actions — usually in a loop, often unsupervised. It is not a chatbot with a better vocabulary. It can draft a contract, look up a client record, send an email, flag an anomaly, and hand off to a human — all without anyone pressing a button.

That is powerful. It is also why treating it as an IT project is so dangerous. IT projects have a defined scope and a go-live date. An agent that works autonomously in your business has neither. It needs governance, monitoring, and a clear escalation path for the moments it gets something wrong.

The mid-market blind spot

Enterprise companies have compliance teams, AI ethics boards, and change management offices. Small businesses move fast and have low complexity. Mid-market companies — say, $20M to $500M in revenue — sit in an awkward middle: complex enough that a poorly governed AI agent can do real damage, lean enough that they are unlikely to have the infrastructure to catch it.

This is where I spend most of my time. The organizations that get it right do three things differently:

They start with the workflow, not the tool. Before selecting any platform, they map the process end-to-end — who touches it, where decisions get made, what "good" looks like. The agent is designed to serve that workflow, not replace it wholesale.

They appoint an owner, not a vendor. Someone inside the organization is responsible for the agent's performance, not just its uptime. That person monitors outputs, handles exceptions, and decides when the agent needs retraining or replacement. Vendors do not do this for you.

They plan for the uncomfortable middle. There is always a period — usually three to six months — where the agent is running but staff are not yet trusting it, processes have not fully adjusted, and ROI is not yet measurable. Organizations that plan for this phase survive it. Organizations that expect a clean line from pilot to productivity do not.

The question worth asking

Before your next AI initiative, ask your leadership team: if this agent makes a mistake that costs us a client, who is accountable? If the answer is "the vendor" or "IT," you are not ready to deploy it.

That is not a reason to wait. It is a reason to build the internal capability now, while the stakes are manageable, so that when you deploy something more consequential, you have the muscle memory to govern it well.

The organizations that will lead in three years are not the ones that adopted AI first. They are the ones that built the operational discipline to use it responsibly at scale.

← All essays