A fictional example: six months on an AI pilot. It works in the demo. Then the person who built it leaves, and nobody can run it. Nothing in the system failed. The project did.
An automation engineer is the person who embeds inside a company to turn an AI tool into a working part of a real process, not a demo. The job needs technical skill, an understanding of what the AI can actually do, and an understanding of the workflow it has to fit into. As Aaron Levie put it, "there's no shortcut" to that combination, and the job is new enough that nobody has ten years of experience doing it yet.
Where does the term come from?
Aaron Levie, CEO of Box, named this role in an X post in October 2026. His description: enterprises are starting to embed a new kind of specialist inside departments, someone who bridges AI into day-to-day workflows. It takes technical expertise, an understanding of AI, and an understanding of the workflow itself. He called it an entirely new function.
He was quoting Jake Stauch's article, "The Rise of the Automation Engineer." Stauch's point is the one I'd underline: building automation has never been easier. Knowing what to automate, and fitting it into a company with real people, real politics and a hundred decisions nobody ever wrote down, is still the hard part.
What does an automation engineer actually do?
Not write code for its own sake, and not just switch on a chatbot. The work sits between the technology and the process: deciding which step is worth automating, which model fits the task, where a person needs to stay in the loop, and how the result gets documented so someone other than the builder can run it later.
That last part is where most pilots I come across fail. The build works. The handover doesn't exist, so the system quietly stops being used the day its builder moves on.
An internal hire, or your first automation engineer?
Levie and Stauch are both describing a permanent role, embedded inside a company for the long term. That's one way to get this done, and for a large organisation running many of these projects at once, it can make sense.
For a smaller business with one or two processes worth fixing, hiring a full-time automation engineer is a heavy first step. The alternative is bringing one in for the process you actually have, scoped and priced before anything starts, with the work handed to your own team at the end.
| An internal automation engineer | The first one you bring in | |
|---|---|---|
| Commitment | Permanent hire, salary and management | One engagement, scoped in writing |
| Scope | Grows and shifts over time | Agreed with you before work starts |
| Who runs it afterwards | They keep running it themselves | Documented and handed to your team |
| Ongoing cost | Headcount, whether or not there's new work | No mandatory retainer |
What does this look like with me?
This is close to what CPLT already does, with one difference I'll get to. Concretely:
- I start from one task or process you already repeat, sitting with the person who does it, not just their manager.
- I agree the scope and the price with you in writing before any work starts.
- I agree with you where AI actually helps, which model fits the job, and where a person still checks the result.
- I build the assistant or automation inside a workspace your company owns, not mine.
- I document how it runs and walk your team through the handover, so your own people run it without me.
I go through this in a short video, with the same fictional example below.
This page loads the YouTube player directly; I use youtube-nocookie.com for the embed, and playback starts when you press play. The presenter is my authorised AI-generated likeness and voice. See the provider disclosure for what that connects to.
A fictional example: one recurring invoice
Fictional illustration, independent of any real client, not a customer case: a company where someone retypes the same fields from a supplier invoice into their accounting system, every week.
I'd start by sitting with the person who does that today, not their manager, to see where the time actually goes: reading the PDF, finding the right fields, matching them to the right account, and catching the occasional invoice that doesn't fit the pattern. We'd agree the scope and the price in writing before any build starts.
The shape of the build follows from that conversation: receive the invoice, extract the fields, a person checks the extraction, draft the entry, a person approves it before it posts. Where the AI helps is extraction and drafting. Where a person stays involved is judgment: anything unusual, any missing information, the final approval. Once it's running, I document it and walk the team through the handover, so it's their system, not a black box I keep the keys to. No time or cost saving is claimed here; this is a fictional illustration of the shape of the work, not a measured result.
Before accepting a build, I would use the handover checks with the person who will run it. A working demonstration and a usable handover are different things.
If you want to scope something like this properly before spending anything, I've written about how to scope an AI trial before buying tools, and separately about the acceptance checks I use for an internal assistant so a result can actually be judged, not just admired.
What's the difference between me and the role Levie describes?
Levie and Stauch are describing someone a company keeps. I'm not that. I'm the first automation engineer you bring in for a process, and then I hand over, so your own people run it without needing me on staff or on a retainer.
Frequently asked questions
What is an automation engineer?
Someone who turns an AI capability into a working part of a real process inside a specific company, rather than a generic tool. Aaron Levie named the role in 2026; it combines technical skill with an understanding of the actual workflow and the people doing the work today.
How is this different from hiring a software developer?
A developer usually builds to a specification someone else has already written. An automation engineer spends real time working out what that specification should be, inside a company with existing habits, approvals and exceptions nobody wrote down. The technical build is often the easier half.
Do I have to hire an automation engineer permanently?
No. That's the difference between the role Levie and Stauch describe and what I offer through CPLT. I'm the first automation engineer a company brings in for one process, not a permanent addition to payroll. Once the work is scoped, built and documented, I hand it to your team.
What does the first engagement actually involve?
I sit with the person who does the task today, not just their manager. We agree the scope and the price in writing before any work starts, decide together where AI helps and where a person still checks the result, then I build it inside a workspace your company owns.
How much does it cost to bring in an automation engineer?
There's no number I can quote without knowing the process first. I agree a scope and a price with you in writing before work starts, during the free 45-minute call, so you know what you're agreeing to before anything begins.
If you have one process like this
If you have one recurring task that looks like the invoice example, bring it to a free 45-minute call. No technical spec needed to start, and no confidential documents in the first message.