Before You Build an AI Team, Borrow One

The wrong first question is: “Should we hire an AI person?”

The better question is: “Which workflows are valuable enough to operationalise?”

Those are not the same question. Hiring implies you already know what needs to be built, who will own it, what systems it should touch, and how success will be measured. Most companies are not there yet. They have scattered experiments, a few enthusiastic people using ChatGPT, and a growing suspicion that useful work is hiding somewhere between their inbox, CRM, spreadsheets, project boards, and reporting routines.

That is real opportunity. It is also too early to turn into a permanent team.

AI operations should start as proof, not headcount

Shopify recently said one in eight merged pull requests is now coauthored by River, its Slack-native internal agent. The striking part is not just the number. It is the operating model around it: a clean environment, written-down skills, reproducible systems, public threads, and a workflow that teaches the organisation as it runs.

Shopify earned that path because it already had the scale, environment, and operating discipline to make an internal agent useful. Most teams have not reached that stage yet.

That is not “we bought an AI tool.” It is operational design. And that operating model is exactly what you borrow before you build.

The same lesson applies outside engineering. An AI workflow is not just a prompt or a chatbot. It needs access boundaries, approval points, escalation rules, audit trails, and someone responsible for improving it when the business changes. If you hire before you understand that operating model, you risk building a team around a guess.

Buying a vertical AI product does not create a fourth path. Without an operating model, it is just a tool dropped into a messy workflow. The question is still whether to wait, borrow the operating capability, or build enough internal ownership to make the tool useful.

When to wait

Waiting is underrated. If the process is unclear, the pain is mild, the volume is low, or nobody owns the outcome, AI will not save it. It will mostly make the mess faster.

Do not automate a workflow just because it is annoying. Wait when the work is infrequent, when a human decision is still the whole value, when the data is too chaotic to trust, or when the team cannot agree what “good” looks like. In those cases, the useful next step is process cleanup, not AI implementation.

When to borrow an AI operations team

Borrowing makes sense when the workflow is valuable but the internal capability is not there yet.

That might be a weekly reporting loop, quote follow-up process, support triage workflow, compliance check, merchandising audit, lead qualification system, or client-ops assistant. The pattern is the same: there is enough value to justify a serious test, but not enough clarity to hire a permanent specialist or build a platform.

External operators can map the workflow, connect the messy tools, define what the system can read and write, design the review step, run the first version, and measure whether it actually saves time, reduces risk, or creates revenue. The goal is not dependency. The goal is evidence.

When to build internal

Build internal once the work has proven itself. A good signal is repetition: the same workflow runs often, affects meaningful money or risk, has clear metrics, and needs ongoing iteration from someone close to the business.

At that point, internal ownership becomes an advantage. The team knows the edge cases, controls the systems, and can make judgement calls quickly. The external role should shift from “operate this for us” to “help us harden, document, and transfer the operating model.”

The practical takeaway

Do not start with the org chart. Start with the workflow.

If the workflow is fuzzy, wait. If it is valuable but unproven, borrow operators and run a contained proof. If it is repeated, measurable, and strategically important, build the internal capability to own it.

AI work becomes expensive when companies confuse those stages. They hire too early or automate a process nobody has properly designed. The safer path is smaller and sharper: pick one workflow, prove it, contain it, then decide whether it deserves a permanent team.