The gap nobody owns

Most AI projects don't fail at the model. They fail in the gap between a good demo and a system a business relies on every day. Someone has to learn how the work is really done, connect the model to the tools the team already uses, and stay until it holds up with real users. That is the job of a forward deployed engineer. I'm Abdul Qudoos, an AI automation engineer in Islamabad, Pakistan, and this is how I work with clients. Below is the loop I run, using a voice agent I helped build as the example.

1. Map the real workflow first

The voice agent had to handle three kinds of calls: customers rescheduling, teammates reporting they were late, and outbound verification calls. Each sounds simple. In practice each has its own script, its own data to look up, and its own "what if" branches. Before writing any prompts, write the workflow down: who calls, what they want, which system holds the answer, and what "done" looks like. For us, "done" meant the calendar was updated and the customer had a confirmation text.

2. Decide what is code and what is AI

An LLM doesn't need to decide who is calling. A phonebook lookup does that reliably, for free, in milliseconds. So the first routing step is deterministic: customer, teammate, or unknown caller. The LLM does the part that really needs language understanding: classifying what the caller wants (we used GPT-4o-mini) and running a multi-turn conversation. We modelled that as a LangGraph StateGraph with one node per path and conditional edges between them. Each path can be tested on its own, and the model can't drift from "reschedule" into "cancel" halfway through a call.

3. Integrate into the stack they already have

Forward deployed work is mostly integration. This agent touched:

• Twilio Media Streams for live call audio over WebSockets, and Twilio SMS and WhatsApp for confirmations
• Deepgram streaming speech-to-text with voice-activity detection
• Azure Speech for text-to-speech
• Google Calendar for fetching, shifting, and cancelling appointments
• MongoDB for call outcomes and team memos

I built the outbound customer-verification workflow and the teammate delay workflow. Most of that work wasn't prompt writing. It was keeping call state consistent across the WebSocket, the graph, and the calendar.

4. Make it reliable

Two rules made the difference: Confirm before side effects. The agent only moves an appointment after the caller says yes. An AI should never silently change someone's schedule. Hide latency you can't remove. We measured the slow steps: a Google Calendar update took about 2.19 seconds and a fetch about 617 ms. On a phone call, two seconds of silence sounds like the line dropped. We couldn't make Google faster, so I added pre-generated filler phrases like "Let me update your calendar with the new time" that play while the tool runs. The wait still happens, but the caller doesn't notice it. Then there are the unglamorous parts: detecting when a conversation is really finished, ending the call gracefully, sending the SMS a second later, and logging the outcome so someone can follow up.

5. Ship, watch, iterate

The biggest improvements came from reading real transcripts. For example, a caller saying "I need help rescheduling" and then "yes" once dropped out of the workflow. We fixed it with a better intent example, not a bigger model. Forward deployed engineering is mostly a steady stream of fixes like that.

Why this matters to clients

If you hire someone to "add AI", you'll get a demo. If you hire a forward deployed engineer, you should get:

1. A written map of the workflow being automated
2. A clear split between deterministic code and LLM calls
3. Integrations into your real systems, not a sandbox
4. Confirmation steps, fallbacks, logging, and human handoff
5. Someone who stays through the first weeks of real usage

That is the standard I hold myself to. If you have a manual process you'd like to automate, get in touch.