When AI work needs to happen and the team is full, three options get quoted. They are usually compared on day rate, which tells you almost nothing about how the engagement will go.
For the role that popularized this model, see the forward deployed engineer guide.
Compare them on where the understanding ends up instead.
You describe an outcome, a team you mostly do not meet builds it, and a delivery arrives. There is an account manager between you and whoever is writing the code.
This works when the scope is fixed and separable. A marketing site, a defined integration, something with a clean edge around it.
It goes wrong when the scope needs to move, which for AI work it usually does. Every change becomes a conversation with someone who is not building it, then a conversation between them and someone who is. The lag is the product.
You hire an individual, they build the thing, they leave.
Faster than an agency and cheaper than both alternatives. The structural problem is the exit: most contracts are written around handing over code, and code is the least valuable thing being handed over. The reasoning does not transfer. Six months later the retrieval pipeline is a black box that works, and nobody wants to touch it.
Contractors are a good fit when the work is finite and you accept that you are buying an artifact rather than a capability.
Someone joins your existing team. Your channel, your spec, your repo, your review process. You direct the work and you review what ships.
The knowledge stays because your people were in the loop the whole time. They approved the plan and reviewed the code, so the reasoning is in the building rather than in a leaving contractor's head.
The cost is that it demands something from you. Somebody internal has to be able to direct and review. If nobody can, embedding does not fix that, it exposes it.
Answer one question honestly: after this work is done, does your team need to be able to change it?
If no, and the scope really is fixed, an agency or a contractor is a reasonable buy and you should not overpay for embedding you will not use.
If yes, the only model that leaves you able to change it is the one where your people were involved in building it. That is not a sales position, it is just how knowledge works. Nobody understands a system they watched arrive.
The useful anchor is not the three options against each other. It is any of them against the cost of a local hire, including the months the role sits open, the recruiting spend, and the ramp before that person is productive.
Measured against that, the day rate conversation usually turns out to have been the wrong conversation.
The same five questions work on all three models, and the answers separate them faster than a proposal does.
Embedding is the wrong buy in three situations, and they are worth naming.
If you have no technical person able to direct and review the work, embedding puts the judgment burden back on someone who cannot carry it. That is worse than an agency, because at least an agency expects to lead.
If the work is a closed, one-off artifact with no maintenance future, you are paying for continuity you will never use.
If the budget only supports a few weeks, do not embed. The model needs enough time for the knowledge transfer to be the point, and a short engagement collapses it back into contracting with extra ceremony.
We do the embedded version, and we are deliberately a bad fit for some of the cases above. If you want a handover and no ongoing relationship, a contractor will serve you better and cost less. We say which teams we work well with for that reason.
If the work needs to outlive the engagement, put your people in the loop. Any of the three models can produce working code. Only one of them leaves you able to maintain it.
Maxpertise is an AI-native engineering company. We embed native AI engineers inside your team, live in about 10 days. Please enable JavaScript to view the site, or email contact@maxpertise.net.