The Agent Is Not the Strategy

This fall, a new AI agent seems to come up in conversation almost every week. Someone gets an invitation, shares a demo, or builds something over the weekend. By Monday, there is another tool to consider.

Instinct is a personal agent you can text through iMessage, WhatsApp, or email. Meta has been moving Muse further into the workplace, including integrations with tools businesses already use. xAI’s Grok Bot gives bots their own cloud computers so they can sign into existing software and interact with other bots. At the same time, teams are increasingly building their own internal applications with tools like Claude and Codex, giving them more control over how the application works, what it can access, and where the data lives.

I am genuinely excited about what this category can do.

There is a lot of work inside companies that consumes time without requiring the level of judgment we currently assign to it. Account research, invoice matching, CRM maintenance, ticket triage, onboarding paperwork, internal reporting, policy lookups, and dozens of other repeatable tasks are obvious candidates.

But every one of these tools leaves the same decision with the business:

What, exactly, should this thing do?

That sounds obvious. It is not.

Without a clearly defined job, usable inputs, an agreed measure of success, and someone responsible for the outcome, companies can spend an extraordinary amount of money automating work that did not need to exist in the first place.

A good demo only answers so much

In June 2025, Gartner predicted that more than 40% of agentic AI projects would be canceled by the end of 2027, citing rising costs, unclear business value, and inadequate risk controls.

That prediction did not surprise me.

A lot of AI projects are already in trouble before anyone turns the agent on. The organization has not defined what success looks like. The system cannot access the information it actually needs. Nobody has decided which exceptions require human judgment. And the team has not thought through what happens when the agent confidently does the wrong thing.

The technology itself also still has limits. Agents are getting much better at executing multi-step work, but that does not mean you should hand them an ambiguous business objective and walk away.

There is an enormous difference between giving an agent a narrow job with reliable information and telling it to “grow pipeline,” “fix customer service,” or “clean up vendor payments.”

The first can be tested.

The second is a business objective disguised as an instruction.

That distinction matters even more as these systems gain permission to act.

A weak draft costs someone editing time. An email that has already been sent can cost a relationship. A bad recommendation is inconvenient. A record changed in the wrong system, a payment routed incorrectly, or a customer contacted with the wrong information can become an operational problem very quickly.

The more agency we give the technology, the more discipline we need around the work.

Most companies are messier than the demo

The appeal of agents is obvious in almost every function.

Sales always has another account to research. Finance has another reconciliation. HR has another employee question. Customer service has another ticket. Operations has another exception sitting in a queue.

When teams are under pressure to hit a number, close the month, or simply keep up with the volume of work, an agent that promises to take some of that pressure away is hard to ignore.

Then the agent meets the business as it actually exists.

The persona document has not been updated since the pricing model changed. The CRM and ERP disagree about the customer. The policy library still includes last year’s rules. Half of the exceptions are not documented anywhere because the experienced employee handling them has simply “always known” what to do.

This is where the conversation gets less exciting.

Because an agent can produce a completely reasonable answer from bad or incomplete information.

The output can look polished.

It can sound confident.

It can even be logically consistent.

And still be wrong for the business.

That is why I keep coming back to the same point: better AI does not eliminate the need for better inputs. It makes input quality more important.

Start with the person the work serves

At Cresera, we do not start an AI deployment by asking which agent a company should buy.

We start with the work and the person that work is supposed to serve.

In sales, that is the buyer. In finance, it could be a controller, an auditor, or a vendor waiting on payment. In HR, it is the employee asking a question. In customer service, it is the person on the other end of the ticket.

Before an agent acts, it needs usable answers to some very basic questions.

Who is this for? What do they already know? What information matters to them? What would they consider accurate and credible? What are we allowed to say or do at this point in the process? What requires approval? What should happen when the situation falls outside the norm?

Most companies have more of this knowledge than they realize. The problem is that much of it lives inside people.

Your best salesperson knows that a CFO needs different proof than an operations leader. Your most experienced AP specialist knows which vendors routinely require a second look. Your strongest HR partner knows when an employee asking about a policy actually needs a conversation, not a link to the handbook.

That context is part of the work.

If the agent cannot use it, you do not necessarily get better execution. You may just get more output for someone else to review.

Building your own does not remove the operating problem

Of all the developments happening right now, I am especially interested in the rise of self-built internal applications.

There is something very compelling about building software around the way your business actually works instead of forcing the business into someone else’s product.

But there is a trap here.

A weekend build can feel finished long before it is operationally ready.

If a field changes in the CRM or ERP, someone has to update the application. If the output begins drifting, someone has to recognize it. If the underlying instructions or policies change, someone has to maintain them. If the employee who built the app leaves, someone else still has to know how it works.

In a larger company, there is another obvious question: does IT know this application exists?

Because the same tool that makes one employee dramatically more productive can also become a governance, security, or data problem if it was built outside the systems the company uses to manage those risks.

This is not an argument against building.

Quite the opposite.

I think more companies will build custom internal applications because the ability to do so is becoming dramatically more accessible.

But if the application matters to the business, it needs an owner, maintenance expectations, governance, measurement, and a plan for what happens when something breaks.

Otherwise, the company has simply created another piece of software no one fully owns.

Three questions before the next pilot

Before approving another agent pilot, I would want three very plain-language answers.

1. What business result are we expecting, and who owns it?

Start with the result, not the activity.

In sales, that might be meetings held, opportunities created, conversion, or sales-cycle movement. In finance, it could be days to close, exception rates, cost per transaction, or avoided labor. In customer service, it might be resolution time, escalation rate, or customer satisfaction.

The metric should fit the job.

Emails sent, tickets touched, records updated, and tasks completed can tell you what an agent is doing. They do not necessarily tell you whether the business is better because of it.

You also need a baseline, a review period, and one person accountable for the result.

If nobody owns the outcome, eventually everyone owns the experiment and nobody owns the economics.

2. Does the agent actually have the information required to do the job?

Walk through the real workflow, not the idealized version in the process document.

Can it reach the systems of record? Are the policies current? Does it have the approved language? Does it understand the relevant exceptions? Is the information reliable? Is it permitted to use that information for this purpose?

Connecting an agent to the CRM does not mean the agent suddenly has good customer context.

Sometimes the first AI project should not be automation at all.

It should be cleaning up the inputs.

3. What happens when it gets something wrong?

Every deployment needs an answer to this before it needs an answer to how impressive the demo is.

Who notices the mistake? Who can stop the agent? Can the action be reversed? Is there an audit trail? What happens if the customer, employee, vendor, or prospect has already been affected?

For anything touching customers, money, personnel, or regulated information, I would keep human approval in the loop until the agent has demonstrated acceptable performance against agreed standards.

And someone should have clear authority to shut it down.

That is not anti-AI.

That is management.

Ownership requires more than a license

There is also a people problem buried inside all of this.

Companies are giving employees access to increasingly capable AI tools, offering limited training, and then expecting those same employees to supervise systems that can act on the company’s behalf.

That is not a reasonable operating model.

The person responsible for an agent needs to understand the workflow well enough to know when the output is wrong. They need to understand the tool well enough to know why it might be wrong. And they need enough authority to intervene when the system leaves the expected path.

That takes practice.

It requires working with the agent on the real process, seeing where it fails, understanding the exceptions, and learning where human judgment still belongs.

Putting someone’s name next to “AI owner” in a project plan is not the same thing as preparing them to supervise autonomous work.

What will still be running in 2027?

The tools are going to keep changing.

Some of the products everyone is talking about today may be category leaders next year. Others may disappear, get acquired, or be replaced by something much better.

That is exactly why I would not build an AI strategy around the tool.

I would build it around the work.

The projects I expect to survive are the ones with a clearly defined job, reliable context, a measurable business outcome, and an owner who knows when to step in.

Those teams will also be in a much better position to evaluate whatever comes next because they will know exactly what they are trying to improve.

A good manager already understands this instinctively when hiring a person. You define the role. You provide the information required to do the job. You establish expectations. You train them. You review the work. You intervene when something goes wrong.

An AI agent deserves at least that much operating discipline.

The license is the easy part. The job design is the strategy.

If your team is trying to figure out where AI agents actually belong, what work should be redesigned, or how to move from experimentation into a practical operating model, that’s exactly the kind of work we do at Cresera AI Partners.

Talk with the Cresera AI Partners team →