What Does a Fractional AI Engineer Do? A Guide to Hiring One
A fractional AI engineer is a part-time, senior builder who finds the workflows worth automating, builds the agents and automations, tests them with evals, then hands them over and trains your team. You get the work of an AI engineer for a set number of days a month, without a full-time hire or an agency retainer.
Key points
The job has five parts: workflow discovery, building, evals, handover and training. The builds usually plug into an AI operating system for a B2B team.
A fractional engineer is closest to a forward deployed engineer: one customer, many problems, embedded with the team. It overlaps with the skills in the guide to becoming a GTM engineer.
Choose fractional when you need senior judgment on a few workflows, not a full-time AI team.
Scope the first 90 days around one costed workflow, not a list of tools.
The statement of work should name what you own at the end: prompts, code, logins, docs and test cases.
What does a fractional AI engineer actually work on?
They own a workflow from "this takes too long" to "this runs, and your team can maintain it." Most of the hours go into understanding the work and proving the build is reliable, not into writing prompts.
The work usually sits inside a shared layer: a knowledge base, connected agents, tool access, approval points and logs. Building is often the smallest share of the hours.
Workflow discovery
The engineer sits with the people doing the manual work, times each step and ranks workflows by yearly cost. The output is a short list of builds with a cost and a risk next to each.
Building agents and automations
Then they build the first workflow. Some steps are plain rules, some need a model. Anthropic's post on building effective agents recommends "finding the simplest solution possible, and only increasing complexity when needed." A good engineer follows that and will often talk you out of an agent.
On the agent layer I often use Relevance AI, whose docs describe a "low/no-code platform where you can build AI agents and multi-agent teams" with "human oversight and approval workflows." The Relevance AI vs n8n vs Zapier guide covers when each builder fits. My full tool list is on the stack page.
Evals
Evals are test cases that check the output before real users see it. Anthropic's guide to defining success criteria and building evaluations says to "design evals that mirror your real-world task distribution" and not to forget edge cases.
Handover and training
Finally they document the build, move every login to your accounts and train the people who will run it. If nobody on your side can change a prompt after they leave, the job is not done.
How is a fractional AI engineer different from a forward deployed engineer?
They do the same kind of work under a different contract. A forward deployed engineer is employed by a software company and embedded with its customers. A fractional AI engineer is hired directly by you, for part of the month, and is not tied to one vendor's product.
The forward deployed role started at Palantir. Palantir's own post on Dev versus Delta engineering roles sums it up in two phrases:
Dev (software engineer). Works on "one capability, many customers."
Delta (forward deployed engineer). Works on "one customer, many capabilities."
The same post is clear on how this differs from advisory work: "A Delta does significantly more engineering and technical work than a consultant."
Jina Yoon's explainer on the PostHog blog, WTF is a forward deployed engineer?, adds the trade-off: "FDEs still do software engineering, but they spend way more time talking to customers."
That is the right model for a fractional AI engineer. You want someone who writes and ships the build, and who also spends real time with your sales, support or ops team to understand what the work involves.
Fractional vs full-time vs agency vs freelancer: which should you hire?
Hire fractional when you need senior judgment on a handful of workflows and want to own the result. Hire full-time when AI work is constant and core to the product. Use an agency or a freelancer for well-defined builds you can spec yourself.
Fractional AI engineer | Full-time AI engineer | Agency | Freelancer (marketplace) | |
|---|---|---|---|---|
Cost model | Monthly retainer for set days or hours, or a fixed fee per phase | Salary, benefits and recruiting cost | Project fee or monthly retainer, often with account management on top | Hourly or fixed price per task |
Speed to start | Days to weeks | Usually the slowest, because of the hiring process | Weeks, after scoping and contracts | Can be fast; Toptal advertises hiring "within 48 hours" |
Ownership | Should be fully yours: written into the SOW | Yours, but knowledge sits with one person | Often sits in the agency's accounts unless the contract says otherwise | Varies; depends on the brief and handover |
Main risk | Too few hours for the scope | Hiring before you know what to build | Junior staff on delivery, lock-in to their tools | Strong builder, weak on discovery and process |
Best for | First AI workflows, an audit, then a few builds | Ongoing AI product work | Large builds with a clear spec | One well-defined task |
What do marketplace rates look like?
Upwork's page on what AI engineers cost lists median hourly rates of $35 to $60 on its platform, with expert-level engineers at "$75 to well over $100 per hour." It also notes that "location will have a significant effect on the rate."
Toptal's AI engineer hiring page does not list rates. It does offer "hourly, part-time, or full-time" engagements and a trial of "up to two weeks."
Those are rates for building. Fractional work is usually priced on outcomes and senior time, so compare cost per finished workflow, not hourly rate.
A good fractional engineer starts by sorting work by structure: what people keep, what is conditional, and what can be delegated to an agent.
When does hiring a fractional AI engineer make sense?
When you know manual work is expensive but you do not yet know which workflows to automate, or how. That is a judgment problem first and a build problem second.
Good signs it fits:
No AI owner yet. Nobody on the team has shipped an agent into production with tests and logs.
Tools bought, little use. Licenses for Claude or ChatGPT exist, but usage is ad hoc and nobody knows what data goes where. The guide to rolling out Claude to a team securely covers that gap.
A handful of workflows. You have three to five clear candidates, not fifty.
You want to own it. You plan to run the workflows in house once they are built.
It is a poor fit if you need someone in every standup, or if the work is new AI features inside your own product. That is a full-time hire.
How should you scope the first 30, 60 and 90 days?
Scope it around one workflow and one number. The first month finds and costs the work, the second ships one build behind a human approval step, and the third hands it over and picks the next build.
Days 1 to 30: discovery and baseline. Interview the people doing the work, time each workflow, and rank them by yearly cost. The manual-work leak audit guide covers the method. Deliverable: a costed list and one chosen workflow, with a baseline for time per task and error rate.
Days 31 to 60: build and test. Build the first workflow with a person approving every output. Write the eval set from real past examples, including edge cases. Deliverable: a working build that passes an agreed share of test cases.
Days 61 to 90: handover and next build. Move logins to your accounts, write the runbook, train the owners, and measure time saved against the baseline. Deliverable: a signed-off handover and a scoped second workflow.
The AI automation maturity ladder is a useful frame for day 90. Most first builds should still sit at the level where a person approves each output.
Every agent the engineer hands over should come with the same four clauses: an ownership boundary, an escalation trigger, a sign-off owner and a rollback condition.
What should a statement of work include?
Everything Zapier's statement of work template guide lists, plus a few items specific to AI. Zapier defines an SOW as "a formal document that clearly defines the scope, tasks, deliverables, timelines," and lists sections from objectives to "a payment schedule."
Use this checklist for an AI engagement:
Objective and baseline. The workflow, its current cost, and the number you expect to move.
Scope and exclusions. Which workflows are in, and which are explicitly out.
Deliverables per phase. For example, a costed list, a tested build and a runbook.
Acceptance criteria. The eval set and the pass rate that counts as done.
Data access and security. What systems the engineer can touch, under whose credentials, and what data may go to which model.
Human approval rules. Which outputs a person must approve before they send.
Ownership. Prompts, code, workflows, docs and test cases belong to you, built in your accounts.
Running costs. Who pays for model usage and tools, with an expected monthly range.
Time commitment. Days or hours per month, response times and meeting cadence.
Handover and training. Sessions, recordings and a named internal owner.
Exit terms. Notice period and what happens to access on the last day.
What questions should you ask in the interview?
Ask about process and failure, not tools. Anyone can list platforms; you want to hear how they decide what not to build and how they know a build works.
"How would you pick our first workflow?" Listen for timing, cost and risk, not "we'll start with an agent."
"When would you use a plain automation instead of an agent?" A good answer matches Anthropic's simplest-solution advice.
"How do you test an agent before it goes live?" Ask to see an example eval set with edge cases.
"Where do the logins and code live during and after the project?" The answer should be your accounts.
"What does handover look like?" Expect a runbook, recorded training and a named owner on your side.
"Walk me through a build that failed and what you changed." Vague answers here are a warning.
"What will this cost to run each month?" They should estimate model and tool costs before building.
What are the common mistakes when hiring a fractional AI engineer?
The most common mistake is hiring for tools instead of judgment. The others come from vague scope, missing tests and unclear ownership.
Starting with a tool, not a workflow. "Set up agents" is not a scope. "Cut reply drafting time on inbound leads" is.
No baseline. Without the before number, nobody can say whether the build worked.
Skipping evals. A demo that works on three examples will fail on the fourth kind of input.
Builds in the contractor's accounts. If their login holds the workflow, you do not own it.
Too few hours for the scope. Two days a month will not cover discovery, a build and training at once.
No internal owner. Someone on your team must be named to run it after handover.
Red flags to watch for
Guaranteed results before they have seen your workflows or data.
One favorite platform recommended for every problem.
No mention of testing, logs or human approval.
Framework talk without the basics. Anthropic warns that "incorrect assumptions about what's under the hood are a common source of customer error." Ask how the framework they like works underneath.
Vague handover, or pushback on writing ownership into the SOW.
What does this look like in dollars?
Here is the worked example from my AI Workflow Install page: a 12-person team where each person spends 8 hours a week on manual work, at a $60 loaded hourly rate. That is $299,520 a year, and in the example one workflow accounts for half of it, $149,760.
That one workflow is what the first 90 days should target. Even a partial cut in its hours is a clear, measurable result to set against the engagement fee.
To run it for your team, multiply people by weekly manual hours, by the loaded hourly rate, then by 52. Then compare the fractional fee to the share of that cost the first build removes.
Track the result the same way you set the baseline: hours per task before and after, and errors caught in review. If the numbers hold for a month, the second workflow gets cheaper, because the knowledge base, logins and approval steps from the first build already exist.
FAQ
Is a fractional AI engineer the same as an AI consultant?
Not quite. A consultant often recommends; a fractional AI engineer also builds, tests and hands over the working system.
How many hours a month does a fractional AI engineer work?
It depends on the contract. Agree days or hours per month in the SOW, sized to the phase you are in.
Do I need a fractional AI engineer or a GTM engineer?
There is overlap. A GTM engineer focuses on revenue workflows, while a fractional AI engineer may work across sales, support, ops and finance.
Who owns the work after the engagement ends?
You should. Write it into the SOW and make sure everything is built in your accounts from day one.
How do I know the build works?
Agree an eval set and a pass rate before building, then measure time per task against the baseline.
Should we hire full-time after a fractional engagement?
Sometimes. If the work grows past a few workflows and needs daily attention, the fractional engineer can help write the role and hand over to that hire.
See what one workflow is costing you
If you are weighing a fractional AI engineer, start with a free 30-minute Leak Call. We estimate what manual work in one area costs per year, and you get a costed workflow list within 48 hours. You can also see all my offers on the services page.
About the author: Kevin Payne is an AI engineer and GTM operator who installs AI workflows for B2B teams. He has 10+ years in B2B SaaS demand generation and RevOps across Techstars, a16z and YC portfolio companies, and his writing has appeared in HubSpot, GetResponse, Outbrain and more.
