Roles

When to make your first in-house AI hire

Daniel Kerambrum Bicourt · Founder, CO-ORDI · 3 November 2026 · 6 min read

Founders usually ask the wrong question. It isn't whether to hire an AI engineer. It's when. Hire too early and you're paying a full salary to find out what the job even is. Hire too late and a competitor has already automated the thing you're still arguing about in a meeting. Here are the signals that actually separate the two, and what to do while you're still deciding.

Why the timing is so easy to get wrong

An AI engineer or automation hire is unlike almost any other role you fill. There's no established qualification, no agreed job title, and no ten-year track record of what good looks like at your size of business. So founders default to one of two instincts. Some hire the moment AI becomes a board-meeting topic, before anyone has scoped a single system, and spend six months paying a salary to watch someone learn the business. Others wait until the pain is undeniable, by which point three teams have built their own patchwork fixes and the eventual hire spends their first quarter untangling that mess instead of building anything new.

Neither instinct is really about AI. It's the same mistake businesses have always made with any new, hard-to-vet role: hiring on urgency rather than on evidence.

The signals that mean now

Three things, together, are a reliable "hire now" signal. First, AI work has stopped being a project and become a function. If you can point to live systems, in production, that already touch revenue or delivery, and the question is who keeps them running and extends them, that's a function, not a one-off build.

Second, more than one person is already doing a version of the job badly. When your operations lead, your head of sales, and a contractor are each quietly maintaining their own automations, with no shared standard between them, you don't have a staffing gap. You have a coordination problem that a single accountable owner will fix faster than any amount of training.

Third, and most important: you can write the job spec because you've already run the job with someone. You know what a good day looks like, what the role should be measured against, and what the first ninety days need to produce. A spec written from direct experience attracts better candidates and lets you interview for substance instead of buzzwords.

The signals that mean wait

Two signals point the other way. The first is simple: you still can't describe the job in one paragraph. If "automate things with AI" is the full brief, you're not ready to hire. You're ready to find out what the brief should say, and that's a different kind of engagement entirely.

The second is that the need is a single, bounded project rather than an ongoing seat. A reporting pipeline that needs building once, a sales process that needs automating once: these don't need a permanent headcount line. They need a scoped build, delivered and documented, after which the right question is whether anything new has appeared that justifies keeping someone on.

What a premature hire actually costs

The salary is the smallest part of it. Recruiting for a role this new is slow, because there's no shared language yet for what "senior" means in it, and interview panels routinely rate confidence above capability. The larger cost is the months spent finding that out: a hire who can talk fluently about models but can't ship a system that survives contact with your actual data, your actual customers, and your actual edge cases. By the time that becomes clear, you've lost the better part of a year and have to run the whole search again, now with less trust in your own judgement on the role.

The move that removes the guesswork

This is exactly the gap an embedded AI Architect is built to close. Rather than guessing at a job spec, you get someone production-proven working inside your business for a flat monthly fee, building the systems and writing down, in real terms, what the ongoing job actually requires. If the answer turns out to be a permanent hire, you now have a spec drawn from direct evidence, and you can interview against it properly, or convert the embed into that hire outright. If the answer is that the need was bounded all along, you walk away owning everything that was built, with no severance, no notice period, and no mis-hire to unwind. We've written more on how that comparison plays out in practice, and on who should actually hold ownership of AI once the function exists.

What a good first hire looks like, when it's time

When the signals do point to hiring, resist the pull towards a researcher or a specialist. The first hire should be a generalist builder: someone who can scope a problem with the business, wire a system end to end, and hand it over documented. Depth in a narrow specialism is a second or third hire's problem. The first hire's job is coverage, not elegance, and the interview should test for exactly that: ask for a system they built, end to end, that is still running today.