Inside this article
- A forward deployed engineer builds inside your environment, alongside your team, in your tools and under your access rules.
- The platform carries permissions, approvals and the record. The engineer builds what is specific to your MSP: integrations, workflows, screens and compliance requirements.
- Your side provides the work, the access and the decisions. The engineer stays until your people can run what was built.
"Forward deployed engineer" has become a common job title in AI, and it is used loosely. For an MSP leader deciding how to staff an AI build, the title matters less than the answers to a few plain questions. Where does this person work? What do they build? What do they need from my team? What is left when they go?
This article answers those questions from the point of view of an MSP service or operations leader.
What is a forward deployed engineer?
A forward deployed engineer is a hands-on delivery engineer who is embedded with the client. They own the technical work of an implementation from start to finish: they turn your workflows, your systems of record and your operational problems into working AI systems.
Two parts of that description carry the weight. "Embedded" means the work happens inside your environment, with your people, on your real work. "Owns" means there is no handoff between a person who understood the problem and a different person who writes the code.
Part of the job is judgment. A good engineer in this role will tell you when something should not be built, because the process is not settled or the volume does not justify it.
What does the engineer build?
It helps to look at the whole stack and see which part is theirs.
At the bottom are the systems you already run: PSA, CRM, ITSM, project tools, email and files. They stay. Above them are the connections that let agents reach those systems. Above that is the platform, PRESHos, which carries permissions, the digital twin, approvals and the record.
The top layer is what the engineer builds for you:
- Integrations. Connections to the systems you run, including the ones no connector covers yet.
- Workflows. Agents and Automations shaped to how your team does the work.
- Screens. The views your team needs where the standard product does not have them.
- Compliance. Your compliance requirements, treated as part of the build so they can be audited.
Because the platform already handles permissions, approvals and the record, the engineer's time goes into the parts that are yours alone.
What does the work look like day to day?
Take an MSP that wants help with ticket intake and routing. The engineer does not start with a specification written elsewhere. They sit with the service desk and watch how tickets arrive, how a dispatcher reads them, and where the exceptions are.
From there the work runs through working sessions with the people involved: the service desk manager who owns the workflow, the person who administers the PSA, the technicians who will review what the agent proposes. The engineer builds against real tickets, shows the result, and changes it based on what the team says.
Two habits define the role. The first is raising problems early. An access request that will take time, a field that is used three different ways, a scope that is quietly growing: the engineer surfaces these when they appear, while they are still cheap to fix. The second is building for the day after go-live. Error handling, visibility into what the agent did, and a clear route to a person when the agent is unsure are part of everything shipped.
How is that different from a build delivered from outside?
The difference shows up in four places.
A build made elsewhere meets your systems for the first time at delivery. That is when you learn that the sample data left out the messy cases, that the service account cannot see a board, or that the dispatcher's real rule is different from the documented one.
A build made inside your environment meets those facts in the first working sessions. It is tested on real work by the people who own that work. And because your team watched it take shape, they already understand it when the time comes to run it.
What does the MSP need to provide?
Less than a full project team, but more than a kickoff call. Three things matter.
The work. Someone shows how the work is done today. For a service desk workflow, that is the manager and one or two people who do it every day.
Access. Someone names the owner of each system and grants access. In most MSPs this is the PSA administrator and whoever manages identity.
Decisions. Each phase has one decision that stays with you: the first workflow, its owner and its measure; what each agent may read and change; when a workflow goes live; what to extend next; and how much you run yourselves. The engineer does the work, and nothing moves on until you have made the call. Who does what in each phase lays this out in full.
How does the engineer handle access to client data?
This question matters more for an MSP than for most businesses, because your systems hold your clients' information as well as your own.
The engineer works under your access rules, through the sign-on and approval chain you already use. What each agent may read and change is your decision, made during the Connect phase, before any workflow is built on top.
In production, each agent has a role and can read and change only what that role allows. Anything it wants to change waits for a person. A record shows who did it, which agent, which tools and what changed. The governance page describes how roles, Approvals and the record fit together.
A practical rule for MSPs: keep a person approving anything client-facing or risky. The agent drafts the client update. The technician sends it.
When does the engineer leave?
When your people can run what was built. Training is part of the role. An engineer who has shipped a system nobody uses has not finished the job.
In the Transfer phase, your team gets documentation, training on the workflows they now use, and a handoff packet for each part they take over. How much you run yourselves is your choice. If you want the rest looked after, Managed AI keeps it running and improving.
Where to start
Pick one workflow on your service desk and name its owner. Then ask anyone who proposes to build it where their engineer will work, whose access rules apply and who will be able to change the workflow a year from now.
To see how PRESHai staffs a build, read forward deployed engineering, or tell us the workflow and the systems it runs through. We will talk through what our engineers would build with your team.
