Architect, PM, FDE: The Three Roles Production AI Systems Actually Need

We've written about two AI roles already. The AI Systems Architect and the AI Product Manager. Both pieces hit a nerve. Both got the same response in the comments and the DMs: yes, but who actually lands the system inside a real workflow?

That third role exists. The industry is borrowing a term for it from Palantir's playbook: Forward Deployed Engineer.

So here's the trilogy that ships production AI. Architect designs it. PM specs it. FDE lands it. Each role fails differently. Most AI teams are missing one. The project tells you which.

Why three, not one

The common failure mode in AI projects is one person trying to do all three jobs at once. We see it on almost every engagement that's gone sideways before we arrive.

The architect who writes the eval set usually writes a bad one. They reach for technical metrics that don't capture product judgment. Their evals look rigorous and miss the things stakeholders actually care about.

The PM who picks the orchestration pattern usually over-architects. They imagine the full multi-agent future before the system has even shipped a single workflow. The engineering team builds the wrong thing competently.

The engineer who deploys without doing real workflow discovery ships a system that works in the demo and goes unused in production. The customer's actual process didn't look like the slide deck.

None of these failures are skill failures. They're seat failures. The architect is excellent at architecture. The PM is excellent at product. The engineer is excellent at engineering. They each fail at the parts of the job that belong to a different seat.

Production AI doesn't survive that. The work has to be split, not stacked.

What each role actually owns

A short pass at the taxonomy. One paragraph per role, written from where we sit running these engagements.

AI Systems Architect

Owns end-to-end design. Picks the model tier, the orchestration pattern, the storage layer, the integration points, the latency budget, the cost ceiling, the scalability boundaries. The architect is the seat that says no when a stakeholder asks for a feature that requires the wrong technical tradeoff. They draw the boundaries the rest of the work happens inside.

Failure mode without an architect: the system works in a notebook, costs a fortune in production, and falls over the first time a customer hits a non-happy-path. Architecture is the discipline that prevents the demo from being the ceiling. (See the AI Systems Architect roadmap for the full walk-through.)

AI Product Manager

Owns "good enough." Builds the eval set. Specs behavior across all four states (success, ambiguity, refusal, failure). Owns failure-mode UX. Owns the cost-latency-accuracy tradeoff as a first-class product decision, not a non-functional requirement.

Failure mode without a PM: engineers say it works, stakeholders keep rejecting it, and there's no shared definition of done. The team ships, the executive eyeballs ten outputs, says "not yet," and nobody can argue against the verdict because there's no eval to point to. (Full breakdown in the AI Product Manager roadmap.)

Forward Deployed Engineer

Owns landing. The FDE sits next to the customer's workflow long enough to know where the system breaks in real use, then ships changes fast enough that the gap stays closed. The work splits into roughly four buckets: workflow discovery, enterprise integration, in-field monitoring, and iteration from real usage.

Failure mode without an FDE: the architecture is clean, the evals look good, and the customer barely uses the system. The workflow assumptions in the design didn't match the workflow in the business. Nobody got close enough to the real work to catch it.

The role most companies underbuild

The FDE seat is the most underbuilt of the three, in our experience by a wide margin. A few reasons it gets skipped or pushed aside.

It looks like delivery. It looks like integration. It looks like field engineering. All of these are jobs that organizations are used to outsourcing to services teams or partners. The implicit assumption is that the hard work happens before deployment, and what's left is just plumbing.

That assumption is wrong for AI work. The hard work happens during and after deployment, because the system's behavior in production is a function of the customer's data and the customer's workflow, neither of which the architect or PM had complete information about.

The FDE is the seat that closes the loop between the system as designed and the system as used. Skip it and you ship a polished thing that nobody uses. Build it and you ship a slightly rougher thing that gets adopted and improves weekly.

The label varies depending on where you sit. Palantir says Forward Deployed Engineer. Some AI labs say Solutions Engineer. Consultancies sometimes call it Delivery Architect. The label matters less than whether the role exists with the authority to change the system in response to what they learn in the field.

How to tell which seat your project is missing

A quick diagnostic. Pick the symptom that matches your situation.

"Engineers say it works. Stakeholders keep rejecting it."
You're missing a PM. There's no shared definition of done, no eval set to argue against, and no specification of how the system should behave in the unhappy-path traffic. Build the eval set before you build anything else.

"Stakeholders love the demo. It costs $40 per session in production."
You're missing an architect. Cost, scalability, and latency are unowned. The system was designed for a demo, not a production envelope.

"Architecture is clean. Evals look good. Customer barely uses it."
You're missing an FDE. The workflow assumptions don't match the customer's actual workflow. Nobody on the team is close enough to the real work to notice.

"All three are happening at once."
You're past the point where one role can fix it. You need a partner who can rotate across all three seats and bring the project back to coherent.

The diagnostic is useful because it points at staffing decisions, not technology decisions. Adding more engineers won't fix a missing PM. Hiring more PMs won't fix a missing FDE. The composition of the team is the problem, not its size.

The collaboration rhythm

The three roles are not sequential phases. They're three concurrent seats with weekly handoffs.

The cadence that works in our experience: architect tunes the boundaries (model selection, scope of the integration, cost ceiling), PM tunes the evals and the failure-mode spec, FDE tunes the integration and feeds reality back. Each week one of the three is the loudest, and which one rotates based on what the system is doing in the field.

If your project runs a kickoff-then-handoff cadence, where architecture finishes, then PM finishes, then engineering builds, then someone deploys, you don't have a trilogy. You have a relay race, and the baton drops between every leg.

The trilogy runs as a small huddle, not a relay. The artifacts that flow between seats (architecture decisions, eval results, integration learnings) are weekly. Course corrections come from the FDE catching something in the field, the PM updating the eval, the architect adjusting the boundary, all in the same week.

How we run engagements

This piece is the third of three because the trilogy isn't a thought experiment for us. We staff engagements with all three seats represented from week one. The architect designs the system, the PM defines what good means and builds the eval set, the FDE sits next to the customer's workflow and ships the integration. They meet weekly and the system changes course based on what came back from the field.

The reason we run it this way is not that it's clever. It's that solo seats don't ship production AI. We've tried other configurations on prior engagements. The configurations that produced demos and not production systems are the ones where one role tried to do the work of another.

Most internal teams can't staff all three on a single project. They have engineers but no PM-with-AI-fluency. They have a PM but no FDE. They have an architect but no PM with eval discipline. That's the gap we step into.

The bottom line

AI projects are not failing for engineering reasons. The models work. Bedrock works. RAG works. Agents work. None of that is the bottleneck.

What's failing is the composition of the teams shipping these systems. The architect, PM, and FDE roles are the actual unit of execution for production AI. Each one fails differently when missing. The decision framework is staffing, not technology.

If your project is stuck, look at which seat is empty. If all three are empty, you're not building AI. You're hoping.

---

Written by Ramesh Nori. If this was useful or you have feedback, reach me at cloudbuckle@gmail.com.