What a forward deployed AI engineer actually does

What a forward deployed engineer does in AI: embedded with the customer, owning the problem from a fuzzy ask to production. Daily loop, skills, examples.

A forward deployed engineer works embedded with the customer and owns the problem, from a fuzzy request to a system running in production. In AI work, that means taking a business process and turning it into an agent, an integration or a data pipeline that people actually use. I don't hold that title at any company, but it is the most accurate description of how I work as an AI engineer at DockPlus AI.

Why the role is showing up now

On Google Trends, searches for "forward deployed engineer" grew about 6x in the US over the last 12 months. The term also shows up as a rising related query (+300%) for people searching "AI engineer".

The reason is simple. Language models got good enough to solve real problems, but calling the API is the easy part. The hard part is figuring out what the customer needs, wiring the model into the systems they already run, and making sure the output stays correct after launch. Someone has to do that work close to the customer.

The role is also open to remote engineers in Latin America. Listings from Puente Talent Partners, Assistant Launch, Artefact and South advertise roughly US$3k–10k/month, according to the listings themselves.

What an AI forward deployed engineer does

The short version: you sit inside the customer's world and you are accountable for the outcome, not for one slice of the code.

In practice that breaks down into three jobs:

• Understand the problem in the customer's context. The request arrives as "we want an assistant that handles quotes." Your job is to find out what data exists, who approves what, and what must never go wrong.
• Build the whole thing. Backend, integrations, agent, deployment. There is no other team to hand the missing piece to.
• Stay until it works. The job doesn't end at handoff. It ends when the system runs on real data and someone notices when it breaks.

How it differs from a software engineer and from a consultant

A typical software engineer gets the problem already scoped: a ticket, a spec, a product with a roadmap. They own a piece of the system. A forward deployed engineer gets the problem before it's scoped and decides what to build.

A consultant also starts from the customer's problem, but usually delivers a diagnosis, a recommendation or a plan. A forward deployed engineer delivers code in production and answers for it.

Put simply: the consultant says what to do, the classic engineer builds what was defined, and the forward deployed engineer does both and then runs the result.

The daily loop: discover, prototype, ship, measure, harden

The work follows a short cycle that repeats.

1. Discover. Talk to the people who run the process, look at real data, list the integrations. This is where the constraints no document mentions come out.
2. Prototype. A minimal version running on real data, so the customer reacts to something concrete instead of a description.
3. Ship. Put it in production with authentication, permissions and a repeatable deploy.
4. Measure. Watch what happens: logs, cost, errors, the cases where the agent did something odd.
5. Harden. Turn each failure into a rule, a test or a limit, then go back to step 1 with the next problem.

The skills that matter for an AI engineer in this role

Integrations. Almost every real project is AI wired into systems that already exist: accounting, CRM, SMS, calendars. Reading a poorly documented API and handling its failures matters more than knowing the newest model.

Data. An agent is only as good as the data it can query. Many projects start with collecting and cleaning data that lives in scattered places.

Evals and observability. Without measurement you can't tell when the system got worse. At DockPlus I use Langfuse to track latency, token cost and answer quality, alongside automated tests and audit logs.

Communication. Explaining to a business owner why an action needs a confirmation step, or why two numbers aren't comparable, is as much part of the job as the code.

Examples from my work

At DockPlus AI, where I'm CTO and co-founder, I work with clients in Brazil and the US, from requirements to deployment and monitoring. I build with Claude Code. Three projects show the loop well.

LedgerJob: an AI agent and MCP server for US contractors

LedgerJob is a SaaS for US construction contractors. Owners run leads, quotes, projects and invoices by chatting with an agent, and the same 66 tools are exposed through an MCP server.

The part most relevant to this role is the boundary between the agent and the customer's business. Irreversible actions, like sending email or SMS or deleting data, never run inside the agent loop. The agent creates a pending action and the user confirms it on a card. Sixteen tools work this way. Identity comes from the API key, never from the model, and the MCP server acts with that user's permissions.

One example of the harden step: the assistant managed to book an appointment from 6 pm to 5 pm. The time rule moved out of the HTTP route and into the service layer, with a test, because the agent and the MCP server skip the HTTP validators. The system also integrates Stripe, QuickBooks Online, Twilio, Google Calendar, EagleView, Hover and CompanyCam.

Cape Cod Permits: a data pipeline built for agents

Cape Cod Permits started as a data problem: Massachusetts building permits are spread across six municipal systems with no common API. I built one collector per platform, all writing to a single PostgreSQL database that now covers 74 towns.

The operations side matters most here. Every raw response is stored with a hash and the parser version, so the database can be rebuilt without re-downloading anything. Failures are isolated per platform. The health check tracks progress, so a real stall surfaces within 20 minutes.

The MCP server is read-only, and its tool descriptions tell the agent to check each town's coverage before comparing towns. It's the same caveat I would give a human analyst, written for the model.

Client websites: a process the team can repeat

For client websites the problem was different: delivering sites for small businesses without each one becoming a handcrafted project. I wrote a Claude Code skill that goes from the client's Instagram and Google Business Profile to deployment, in phases with a human approval at the end of each one. WCAG contrast and JSON-LD are checked by scripts. The DockPlus team uses the same process.

Is this role a fit for you?

If you like leaving the ticket queue to talk to the people who use the system, don't mind touching the backend, the integration and the deploy in the same week, and want to see the result running on real data, the forward deployed engineer role makes sense. If you prefer a well-defined scope and depth in a single component, classic product engineering is probably a better fit.

More about my background is on the about page.

Hiring or have a project in mind? get in touch