The Part Most AI Projects Skip

The AI projects I’ve seen stall didn’t stall at the model. They stalled at the business underneath it. The models mostly work. They get pointed at businesses that aren’t ready for them.

I’ve watched this happen from inside client systems for years. An agent gets bought before anyone has looked at the data it’s supposed to act on. A workflow automation gets built across two systems that disagree about who the customer is, and it automates the disagreement. A roadmap gets written that was never pressure-tested against how the business actually runs, and it ages out before the first sprint closes.

The work that decides whether an AI project succeeds happens before any model gets called. We call it readiness work. Data hygiene, system connections, governance, permissions, change management. None of it is glamorous, and it is usually the first thing cut when a team is in a hurry to see an agent do something.

For years, businesses have quietly accepted friction in these places because fixing it cost more than working around it. A person can work around a messy system. They know the customer in row 400 is the same one as row 12, even though the data doesn’t say so. An agent can’t. The moment you put software in the loop, the workaround you’ve tolerated for years becomes the thing blocking the payoff. AI changes what that friction costs you, and the firms getting the most out of AI are the ones doing the readiness work first.

We’ve been doing that readiness work for a long time under different names. Salesforce implementation. PSA implementation. Org merges and migrations. Data cleanups nobody else wanted to own. Same discipline, new label.

The Path to Operationalized AI: five stages from pilot to production

That work has a shape. Five stages, in order, and the order is what matters. It isn’t a maturity model. It’s the sequence the engagements actually run in, and skipping a stage doesn’t save time, it moves the cost later.

The full story is almost never in one system

Here is where it gets specific for professional services firms, because it is the pattern I run into most. The question a partner actually wants answered is some version of: did this project make money, and if it didn’t, when did it stop. Answering that means the scope from the CRM, the plan and the actuals from the delivery system, the invoices and the cost from finance, and the timesheets from whoever hasn’t submitted theirs yet. Four systems, four owners, and at least three opinions about what counts as a project.

A person handles that by opening four tabs and doing the reconciliation in their head. They know the opportunity and the project refer to the same piece of work, even though nothing in either record says so. An agent doesn’t get to know that. It gets what the connection gives it, and if the connection stops at the CRM, the answer stops at the CRM.

So connection is doing as much of the readiness work as cleanliness is. Not a data lake, and not tearing anything out. The plumbing that lets an agent read the record where it already lives, with the permissions it should have, and understand that this record and that one are about the same client. That is unglamorous integration work, and it is most of the difference between an agent that summarizes one system and an agent that can answer the question somebody actually asked.

We do that work on Salesforce most days. We don’t only do it there, and neither should the agent.

Four questions that decide whether an AI project works

Discovery isn’t a phase you rush through to reach the build. It’s the conversation that decides whether the build is worth doing. Four questions tend to surface early.

1. Is your data ready to be acted on by software you didn’t write?

   Operational data is usually structured for people to interpret, not for an agent to act on. AI needs cleaner ground than people do.

2. Which workflows actually matter?

   Every business has a long list of automation candidates. The ones worth automating tend to be the ones leadership already feels the friction of.

3. Where does the human stay in the loop, and why?

   Some decisions get faster with AI in the room. Others get riskier. Knowing which is which is the difference between a deployment that holds up when someone audits it and one that doesn’t.

4. What changes for the people who used to do this work?

   Adoption is a clarity problem before it’s a training one. If the team doesn’t know what’s expected once the agent lands, it won’t land.

None of these have a general answer. They have an answer for your business, and the answer usually shows up in the first conversation.

Who is the agent allowed to act for?

There’s a question that tends to get asked late, if it gets asked at all: who is the agent allowed to talk to, what data can it touch, what can it do on whose behalf, and where does the audit trail live when someone asks? These aren’t questions for later. They’re the difference between a deployment that holds up under review and one that quietly accumulates risk until somebody notices.

I’ve spent years in systems where the answer to those questions was the difference between a working solution and an audit finding. It’s the same discipline we’ve applied to PSA, Salesforce, and org-merge work: knowing who can see what, who can change what, and where the trail lives. AI deployments don’t get a pass on that discipline. If anything, they need more of it.

We don’t have a finished answer to all of it, and nobody does. Asking the question before the deployment rather than after is most of the advantage.

What this looks like in practice

One engagement in flight: an investment bank that operates on both sides of the table, sell-side businesses preparing for transaction and buy-side private equity and strategic acquirers. We’re designing the AI-augmented version of their deal workflow. The analyst-grade work (research, modeling, document preparation, first-pass diligence) is what AI does well once the data and the process are set up correctly. The judgment calls and the negotiation stay with the senior bankers, where they belong.

Discovery is where the consequential decisions got made. Which steps to automate. Which to leave alone. Where the audit trail lands. What the bankers keep in their own hands. The build comes next, and the build is the easy part once the design is grounded.

Readiness is a discipline, not a phase

We build on Claude because it holds up against the work our clients ask of it, and we work on the platforms the business already runs on, because tearing out a system to make room for AI is rarely the right move. That part is settled. What isn’t settled, in most businesses, is whether the ground underneath the agent will hold.

The firms getting real value out of AI right now aren’t the ones who bought earliest. They’re the ones who found out what their data and their processes could actually support, and built for that. It doesn’t make for a good demo. It makes for a project that survives contact with the business.

Frequently asked questions