Forward Deployed Engineers: the future of enterprise AI is built inside the customer

When I joined Avra, an ex-Palantir gave me a piece of advice: if you can, don’t build FDEs into your go-to-market strategy. The main argument was about scalability, plus the risk of building a business model that depends on a profile that’s notoriously hard to find. The “if you can” wasn’t taken for granted. But we couldn’t.

Almost a year later, I decided to write about why we have FDEs, and why I believe this was the winning decision for Avra.

The Forward Deployed Engineer role has become the most sought-after position in the AI market in 2025 and 2026. OpenAI, Palantir, Ramp, Anthropic, and Google are all hiring FDEs at full speed. a16z called it “the hottest job in tech.” Sequoia published an entire thesis arguing that services are the new software. But we didn’t follow a hiring trend from Silicon Valley. I became deeply convinced, through pain, that enterprise AI in Brazil simply wouldn’t work any other way.

The problem#

There’s a chasm between a model that works in a notebook and a model that changes decisions in production. In credit, fraud, and B2B marketing — the domains where Avra currently operates — that chasm is especially wide.

The reason is that relational AI models don’t operate in a vacuum. They depend on customer data that arrives in unpredictable formats, with schemas that change every quarter, in regulatory environments that demand traceability. In Brazil, add to that the complexity of integrating with legacy systems at banks, fintechs, and corporations.

When Palantir created the FDE role (internally called “Delta”) in the early 2010s, the company recognized that its product only generated value if someone went to the customer, sat next to the analysts, understood the operational context, and built the bridge between the platform and the real problem. Palantir’s FDEs worked on Airbus’s assembly line, in airgapped government agency environments, and on factory floors.

OpenAI replicated the model in 2025, with Colin Jarvis leading a team that now operates in 8 cities. OpenAI’s FDEs work in 3 phases (scoping, validation, delivery) and one of their most emblematic projects was with John Deere in Iowa, where the team literally went into the field to work with farmers to calibrate a model for personalized equipment interventions.

The lesson is the same in every case: the last mile of implementation is where enterprise AI delivers value or dies. And that last mile, we learned, can’t be covered with API documentation alone.

What an Avra FDE actually does#

At Avra, the FDE is an engineer or statistician who lives in the full deployment cycle — from problem definition to impact analysis in production — and who feeds back what they learn in the field into the product.

Scope of Work: what’s the “hair-on-fire problem”?#

A year ago, it wasn’t unusual for our Research team to run a PoC knowing which variable would guide the training process, but not what the data actually meant in real life. The FDE’s first responsibility is, therefore, to deeply understand the customer’s pain and write about it in detail.

Avra’s SoW is the result of that conversation: a structured document to formalize use cases with customers. It defines the assumed conditions for the project to work (data access, customer availability, etc.), details exactly what will be done and what the project is expected to achieve, in specific and measurable terms. It’s not only important for validation — it’s also an invitation for the customer to think deeply about their own problem and expectations, which are essential for engagement.

Responsibilities for both parties, the key business KPIs to be impacted by the model, and success criteria — marking how successful the PoC was, in objective metrics — are all defined together.

Data contracts: the handshake#

It sounds bureaucratic, but it’s the most important technical decision in the cycle. Every project at Avra starts with a data contract.

The data contract defines the customer’s data schema, the refresh cadence, residency rules, and validation criteria. The FDE is the one who “negotiates” this contract, because the FDE is the one who will live with the consequences.

In practice, this means sitting with the customer’s data team, understanding how their pipelines work, where the data breaks, which fields are reliable and which aren’t. It’s work that requires presence, patience, and the ability to translate the customer’s data engineer’s vocabulary.

Our pipeline is automated (bucket receipt, validation, tasks, data contract, execution) — but automation only works when the input is clean. Cleaning the input is FDE work.

Relational learning: where the GFM meets the real world#

Avra operates a Graph Foundation Model pre-trained on the graph of the Brazilian economy: 65 million companies, over 1 billion edges, 99% of economic entities covered. This model generates embeddings and default probability predictions across five horizons. But the GFM alone doesn’t solve the customer’s problem.

Every company has its own definition of risk, of what a good customer is, its own internal variables, its own data history. Relational fine-tuning is what transforms the GFM’s generic signal into a downstream model calibrated for that specific customer’s context.

The FDE is the one who orchestrates this process. They define with the customer which targets make sense (FPD? Over30MOB6? Conversion?), configure temporal validation to avoid leakage, run the calibration cycle, and present results in a format the customer can interpret.

It’s an applied engineering process where the FDE writes code, configures pipelines, and debugs data issues in real time. But they do all of this with the customer’s business context in mind — a context that a researcher doesn’t have — knowing that the executive team needs an explanation in terms of risk bands or opportunity, not ROC AUC curves.

Shadow deployment: trust is built in parallel#

Perhaps the most underestimated step in our deployment cycle. Before any model goes into production, it runs in shadow — or with controlled volume — in parallel with the customer’s incumbent system, with controlled financial and operational impact.

Shadow deployment does two things. First, it validates that the model works with real data in real time, not just in offline backtests. Second, and more importantly, it builds trust. The customer sees, week after week, that Avra’s model identifies signals the current system misses, or confirms existing decisions with greater precision. When it’s time for roll-out, the decision-makers are making an informed choice.

The FDE manages this entire period. They monitor performance, communicate results, adjust calibration, and resolve the inevitable edge cases that only surface with live data. It’s the most intense and most critical moment in the cycle.

Why this is especially critical in Brazil#

The global FDE thesis is already strong, but our experience in Brazil revealed two additional factors that made our consultative deployment process not just useful, but indispensable — sorry, Tales, I swear I tried to follow your advice!

Heterogeneous data maturity. Some Avra customers have modern cloud data lakes. Many others have CSVs generated by COBOL systems. This can’t be a blocker. The FDE needs to operate at both extremes and everywhere in between. There is no one-size-fits-all for data ingestion in the Brazilian market.

Conservative decision culture. Brazilian financial institutions, even the most innovative ones, have credit committees, risk departments, compliance teams, and governance structures that need to be convinced. That doesn’t happen with a slide deck. It happens with an FDE who sits with the head of risk, shows the shadow results, explains how the model handles cold-start (companies with no history), and demonstrates that the risk bands are monotonic and calibrated.

The feedback loop: the upside we didn’t see coming#

One thing that sets FDEs apart from traditional consultants — and that Avra takes seriously — is the feedback loop into the product. When an FDE discovers that a data schema is recurrent across customers, it becomes an auto-detection template in the pipeline. When a type of results visualization drives more adoption at the customer, it goes back into the dashboard roadmap.

Avra’s GTM has an explicit principle: “if a customer would need an FDE to use a feature, it should go on the roadmap.” The FDE’s role isn’t meant to be permanent; it’s to be the pioneer who clears the path so that, eventually, the process becomes self-serve.

This is the same pattern OpenAI follows with its FDEs contributing to the Agents SDK, or that Palantir followed when the Deltas’ learnings became Foundry features. The difference at Avra is that, in a smaller and more concentrated team, the feedback cycle is faster. The FDE who found a problem on Tuesday is discussing the solution with the research team on Wednesday.

Services-led growth: not a dirty word#

There’s a bias in the software world against services. The default VC narrative is that software scales, services don’t — that service margins are bad, that the ideal company is self-serve and zero-touch.

Sequoia published a thesis that challenges this head-on: “the next $1T company will be a software company masquerading as a services firm.” The argument is that for every dollar spent on software, six are spent on services, and that AI is making it possible to capture the services budget with software margins — because every improvement to the model makes the service faster, cheaper, and harder to compete with.

Avra operates exactly at this intersection. We don’t see the FDE as overhead, but as the entity that transforms a horizontal platform into vertical, customer-specific value. And as the pipeline becomes more automated, the FDE’s role evolves: less manual configuration, more solution design and use-case expansion.

In 2025, we learned that plug-and-play doesn’t work for enterprise relational AI. Customers need a data contract, backfill, and evaluation cycle — and that cycle needs to be fast and legible. The FDE is the one who makes that cycle happen in 45 days or less, which is our operational north star.