ThinkingEssay
Hire the AI engineer third
A lot of owners start on AI with a hire. Make it the third move, after an owner in operations and one written question. A tool of ours that stumbled on a leader’s first questions showed us why.

On this page
Most owners I talk to aren’t looking at AI to cut people. The business is growing, the systems are split across locations or running on an ERP from another decade, and a lot of what they need lives in spreadsheets and email.
What they want is capacity: headroom without headcount, and the people they already have getting better. So they reach for what’s closest, the AI add-on their ERP vendor is selling or a job posting for an AI engineer.
It’s a sensible instinct, since nothing gets built without an engineer. I’d still make that hire third, and our own mistakes are the reason.
In September I walked one of the leaders at a steel fabricator we work with through a tool we’d built for them. They asked about estimates, one customer’s jobs over a date range, and totals across jobs. Two things went wrong.
The tool said “I can’t access that” to questions it should have dug into. It had been built to read jobs, and the estimates live in folders on a shared drive. Nobody had written down a question for it before that day. We’d come in to understand how the business worked and what was limiting its growth, and we’d built against that. Their leaders’ own questions got written down afterward, and five days later, on our test copy, it could read those folders and tell an estimate from a job.
The second problem was harder. They didn’t know which questions it could already answer, because nothing in the tool told them. There wasn’t one example question anywhere in it.
That one was on us. Showing people what a tool can do is part of building it.
The leader suggested we show people example questions. Within a week we’d built them into the box where they type, cycling through questions drawn from their own jobs.
The folders took days of engineering, and the example questions took a night. Knowing either was needed took people who use the tool. At the September demo I told the fabricator’s team, “This isn’t our baby, it’s yours. You can call it ugly all you want.” Somebody inside the company has to own that, or the engineer builds for the questions they guess.
So: first, name the owner. Second, write down the question that costs your team the most hours. Third comes the engineer, hired or brought in. The owner decides which question is worth the work and gets people using the answer. The written question tells the engineer what to build and gives you a number to measure it against.
We don’t want to build things that don’t get used, and a written question from an owner makes that much harder. Plenty of companies your size run IT with one person and an outside firm, and still call it the IT department. Applied AI can start just as small.
Why AI needs an owner
Somebody has to own how the work changes, not just the tool. At the fabricator, the head of project management is copied on PMs’ email to catch the wrong thing going out: a question sent to the customer that the shop’s own engineer should have answered, or a reply to a supplier in the wrong tone. That’s inspection at the end of the line. Put AI on it as it stands and you get faster inspection. Reorganize the work and the email gets checked at the source, while the PM is still writing.
The PM writes
The check
The customer gets
The job also never finishes. New customers, new suppliers, a new plant, a PM who leaves. A tool nobody updates keeps answering with confidence about a business that has moved on.
Someone also has to decide how separate efforts fit together. At a demo in August, a long stretch of the call went to an estimating workflow one of the fabricator’s leaders had built in ChatGPT, with its own capacity check and approval chain. It will either get folded into what the company builds next or compete with it, and somebody has to decide which.
And someone has to answer when the tool is wrong. Name two people in writing before it goes live: the engineer who fixes it, and the person in your business who signed what went out. If nobody can say both names, the tool isn’t ready.
What an applied AI department does
- 01LearnHow the work runs, desk by desk
- 02ConnectThe systems you already have, read-only first
- 03BuildThe agent, app or workflow the team asks for
- 04RunWatch it, fix it, teach people what to ask
- 05Keep accurateRules and records updated as the business moves
- Your people signEstimator, PM, buyer. Accountable for what goes out
The first three run for each new question. The last two never stop. At the fabricator, reading the estimate folders was Connect and Build; the example questions were Run.

How is applied AI different from IT?
AI usually lands in IT because it looks like software. IT will keep it secure. It won’t change how a quote gets built, because nobody in IT owns the quote, and nobody in IT is measured on how long a quote takes.
Hire, buy software or bring in a team
A mid-sized company usually can’t hire a department outright. The engineers who can do this have to read a shop drawing and tell a rush job from a standard one, and still ship software someone runs every day. There aren’t many of them, and one or two hires can’t do all five jobs alone.
You can hire. You get one or two engineers who learn your business, at a senior salary, with someone to manage them, and what they know stays for as long as they do. It’s slow, and it’s one person to lose.
You can buy software built for companies like yours, which someone else keeps running. You pay for seats every month, your team adopts another login, and your data ends up in someone else’s shape.
Or you can bring in a team alongside yours. You pay them while they learn your business, and you depend on them until your people can run it. What they built is yours if the contract says so, and what they knew stays only if it’s written into the record and the rules.
We’re biased, because the third is what we do. Under our agreement with the fabricator, the record, workflows, rules, reports and configurations we build for them are theirs. Our software and reusable tools stay ours, including what we improve along the way.
The fair objection to the third is that the learning leaves when the team does. Whoever you bring in has to leave behind what they built, in a form your own people can run or hand to someone else. We build to stay portable on purpose, and that includes outliving us.
Where to start
Write the question down like this: “Is this email about to say something we’ll regret? Asked about every email a PM sends to a customer or supplier. Answered today by the head of project management, reading copies after they’re sent.” Then add how many hours a week it takes today.
We haven’t measured hours saved at the fabricator yet. The measure we hold ourselves to is simpler: their leaders using the tool on their own work.
Whose name would you put next to AI in your company tomorrow?
Questions people ask
What is applied AI?
The work of making AI useful inside one company’s operations, connected to its systems and accountable to its people. The labs build the models. Applied AI is what happens when one of them meets a quote due on Friday and a drawing set on its third revision.
Do we need a chief AI officer?
Name the owner first. It could be the COO or the head of operations, whoever already answers for how the work gets done. The title can come later, if it comes at all.
Do we have to tell the PMs their email is being checked?
Yes, in writing, before anything reads it. Say what is read, what for, and who sees the result.

