Forward Deployed Engineering for AI Agent Products
Why AI companies put engineers inside customer operations, what that work looks like when the product is agents, and how it sits next to fractional CTO work.
A forward deployed engineer works for a product company but spends their time inside one customer's operation. The job is to get the product doing real work in that business, against that customer's data and people, and to leave it in a state they can run. AI companies have been hiring for the title because agent products tend to stall somewhere between a good pilot and daily use.
In my experience the model is rarely why. The stall comes from two harder questions. Which piece of the customer's work should an agent own? And how do you connect it to systems that were never built to be called by software? Neither question can be answered from the vendor's office, which is the whole case for embedding an engineer with the customer.
I work this way through Red Leg Dev, alongside fractional CTO engagements. The rest of this post is what the work looks like when the product is agents, with examples from systems I've built and run.
Discovery means reading what the system does
The people running a workflow usually have a theory about why it underperforms, and the theory is usually part of the answer. The rest tends to turn up in the code and config, and the same few things come up often enough that I look for them first.
The process document describes a manual step that the code has quietly automated, or the reverse. A default config setting excludes the case the business cares about most, so the system reports healthy while skipping the work that matters. Failures are recorded with a reason, but only in a database table, and the screen operators use doesn't show it, so the people closest to the problem are guessing.
None of that appears in a requirements document or a kickoff call. I think finding it is the main thing an FDE is for. The written description of a workflow and the running system drift apart, and any agent you build will be built against one of them. You want it to be the second. So the first stretch of an engagement is reading code and logs, and sitting with the operators who know where it breaks, before proposing anything.
The first agent should own one small outcome
Support email for Esferas, a product I co-founded, runs through an agent. It pulls the ticket, finds the relevant help article, drafts a reply, and posts the draft to me. Nothing goes to a customer until I approve it. The agent owns the draft. I own the send.
That's a deliberately boring scope, and I'd argue for something like it as the first agent in almost any customer deployment. The pull on these projects is always toward a general assistant that handles everything, because that's what demos well. A narrow agent with a human checkpoint fails in ways you can see, and it gives you a clean before-and-after to measure. You widen it once the customer's people stop rewriting its drafts.
Most of the engineering in this phase is the tool layer: MCP servers against the customer's real APIs, with their real auth and their data quirks. I wrote up the patterns separately in What Broke in My Production MCP Servers, so I'll skip them here.
Hardening is mostly telling held apart from broken
UseFireApp, my outreach product, stages AI-drafted messages for a person to approve, and approved sends only go out inside the account's send window. A message approved on a Saturday for a weekday-only account sits in the queue with the status outside_send_window. That's a hold, and the system records it separately from a failure, because whoever reads the queue on Monday needs to know which is which.
The monitoring had to learn the same distinction. The first version of the idle-account check counted every queued message as work that should be moving, so messages scheduled for the 8 a.m. window looked like a stalled dispatcher and generated alerts all night. The fix was to count only work that was actually due. Even then, the check still raises a warning the minute the window opens, when the overnight holds come due at once against an account that already hit its daily limit yesterday. That warning doesn't page anyone.
Neither problem involved the model. I've come to think that's typical of hardening an agent system. Logging and cost limits are necessary, and then most of the remaining work is making sure the system's statuses mean what an operator will assume they mean.
Handoff
After a few weeks inside someone's operation you build up a private vocabulary, and agents pick it up from their instructions. I've had an agent's customer-facing messages start using our internal names for features and statuses, words that meant something to the operators and nothing to the person reading. The fix was a rule in the agent's instructions listing the internal terms it may not use in customer-facing output and saying what to ask for in plain language instead. Read every outbound template the way its recipient will.
The rest of a handoff is less interesting and matters more: runbooks, a named owner on the customer's side, and failure reasons visible on the screen operators already use, so nobody has to query a database to find out why something didn't happen.
Handoff doesn't always mean leaving. AiVersary, a threat-intelligence product that produces OSINT reports and attack scenarios, is owned by Sittadel. I built it, and I still run it. Whether the customer's team or the engineer keeps operating the system is worth deciding at the start, because it changes what you build.
Where this sits next to fractional CTO work
I offer both, and they are peers. Forward deployed engineering fits an AI product company whose bottleneck is getting into its customers' workflows: I work inside the customer's operation with your product and ship there. Fractional CTO fits an SMB that needs someone to own technical decisions part-time, usually around which workflows should get agents at all. That engagement and its pricing are covered in What a Fractional CTO Does for Agentic AI.
The overlap is the engineering. Most of my eighteen years in software has been inside other companies' businesses: banking at JPMorganChase, dealer software at AutoLoop and DealerTrack, payroll at CertiPay, and now principal architect at InContext Solutions. The agent work is newer, built mostly on Claude Code, custom MCP servers, and agent skills.
If you're building an AI product and one customer is stuck in pilot, start with that customer. Tell me what the product is supposed to do there and who on their side would own it afterward, and I can tell you whether it's a problem I'd take on.
Want help putting agentic AI to work in your business?
I embed with AI product teams and SMBs through Red Leg Dev LLC.