Services — Path 01 — AI Strategy

Everyone has an AI idea. Nobody agrees what to do first.

The support team wants an agent. Sales wants call intelligence. Operations has a workflow that still lives in a spreadsheet and a vendor has offered to fix everything by Thursday. The board, meanwhile, would like a plan. Every one of these ideas can be made to sound inevitable in a meeting. Strategy is the discipline of deciding which of them deserves an owner, data, and permission to interrupt normal operations, and which of them should stop consuming your calendar.

01

Every idea sounds plausible in isolation.

That is what makes this moment genuinely hard, and it is worth saying plainly: the difficulty you are having is not a personal failing, and it is not evidence that your company is behind. The field is moving faster than any operator's attention can follow, the vendors are selling certainty they do not have, and the widely reported truth is that most corporate AI initiatives so far have returned nothing measurable. In an environment like that, hesitation is not weakness. It is pattern recognition.

What breaks the pattern is not more ideas and not more demos. It is a decision, made close to the actual work, with its costs and its limits stated out loud.

02

The work settles real questions.

Which workflow is important enough to change now?

What is expensive, slow, inconsistent, or quietly impossible about the current way?

What information and judgment does the work actually depend on?

Where would AI help, and where would delegation create more review than it removes?

What must a person continue to approve, no matter how good the system gets?

Who will own the changed workflow?

What evidence would justify expanding, and what result would tell us to stop?

If a strategy does not settle these questions, it is not ready to guide a build. It is a mood with a deck attached.

03

Follow the work before naming the solution.

This is where the listening happens. We talk to the people doing and receiving the work. We read real examples, especially the awkward ones nobody puts in the demo. We trace the sources, the approvals, the exceptions, the rework, the handoffs, until we can say what the workflow is actually for and which rule it must preserve. Only then do we let anyone, ourselves included, say the word "agent."

A support-summary project, for example, is never only a summarization problem. The questions that decide whether it works are questions about the business: which source wins when the records disagree, what must be quoted rather than paraphrased, which issue always escalates to a person, and whether anyone downstream will act on the summary at all. A better model cannot answer those. Somebody who listened can.

04

Make the tradeoff visible.

A useful recommendation names the bet and the alternatives it displaces. It might say:

  1. Begin with one high-volume workflow rather than a company-wide assistant.
  2. Automate the first draft, but keep approval with the role that carries the consequence.
  3. Retrieve from approved sources instead of trusting a model's memory.
  4. Delay the customer-facing release until internal reviewers agree on the standard.
  5. Stop after a bounded test if accepted work does not improve.

The exact decision will differ. The obligation to make one does not.

05

We write down when to stop.

Before serious money moves, two things go on paper.

The first is what "working" will mean, in terms tied to accepted work or business behavior, not to a demo's applause. The second is the evidence that would make us stop, pull back, or revise: the result that says do not expand, the threshold that sends us back to the drawing board at small cost instead of large. We define both, and we sign our name under both.

A strategy without a stopping rule is not a bounded bet. We will not ask you to sponsor an open-ended pilot. A bet with a floor under it is a bet you can test without holding your breath.

06

What you receive.

Decision tools, not a binder:

a ranked set of opportunities with the reasoning behind the order;

an explicit recommendation and the alternatives considered;

a map of the workflow, its owners, sources, and failure points;

the authority and approval boundaries the system will live within;

a sequence of tests with owners and stop conditions;

examples that define acceptable and unacceptable output;

and an honest assessment of what your team can own today and where it will need help.

07

Engineering joins before the strategy is finished.

The riskiest assumption is usually technical, operational, or buried in the source material, and the cheapest time to find it is before anyone is attached to the plan. So a builder joins early. A small engineering test can reveal that the useful data does not exist, that one exception dominates the workflow, that review cost would erase the benefit, or that a far simpler tool would do. That information belongs inside the strategy while the strategy can still change. This is the quiet advantage of a practice that builds: our recommendations have been in contact with reality before you have to defend them.

08

The decision should survive new evidence.

You keep the rationale, the owner, the thresholds, and the authority to revise the sequence when the build teaches you something. The aim was never dependence on an outside strategist. It is a leadership team that can interpret what the work reveals and make the next call without reopening the original debate from zero, which is, when you think about it, what having a strategy was supposed to mean all along.

09

Strategy is the right entry point when

The list is growing faster than the decisions. Several leaders want different things from the same initiative. The expected gain, the owner, or the risk boundary is still unclear. A production build would otherwise begin on assumptions.

And probably not when

The decision is already explicit, the owner and limits are clear, and what the company needs is senior engineering. In that case, skip ahead.

Go straight to AI Engineering →

Which decision keeps returning to the meeting?

Tell us the options, the disagreement, and what the delay is costing. That is enough to begin.