Forward-deployed engineering means putting senior engineers inside the customer's environment to build a working system against the customer's real data, systems and constraints, instead of building elsewhere and handing something over. It is spreading across enterprise AI because AI systems only create value once they are wired into messy, specific workflows, and that work cannot be done from a distance. This post covers why the model is growing, what forward-deployed engineers (FDEs) do day to day, and how they compare with consultants and staff augmentation.
Why the forward-deployed model is spreading
The term comes from enterprise software companies that sent engineers to sit with customers and make complex platforms work in practice. What changed recently is that AI companies adopted it at scale. In June 2025, Andreessen Horowitz called the forward-deployed engineer "the hottest job in startups," arguing that AI companies win by doing the hands-on implementation work that makes their software indispensable (a16z, "Trading Margin for Moat"). Hiring followed: eWeek, citing Financial Times research on Indeed data, reported that job postings for forward-deployed engineers rose by more than 800% between January and September 2025, with OpenAI, Anthropic and Cohere all building out these teams (eWeek).
The reason is practical. A model that performs well in a lab is not a working system inside an enterprise. Every company has its own data quirks, security rules, legacy platforms and business logic. Someone has to sit inside that reality and build. Enterprises are reaching the same conclusion from the other direction: the AI work that reaches production is usually built by engineers who are inside the environment, not by teams working from a requirements document.
What a forward-deployed engineer does day to day
An FDE is not a sales engineer and not a project manager. They write production code. What makes the role different is where and how they do it. A typical week looks something like this:
- Sitting with the people who do the work. Watching a compliance reviewer, a claims handler or a support agent work through real cases, to understand the decisions the system needs to support and the exceptions that break naive designs.
- Getting into the data. Pulling real records through approved access paths, finding the fields that are wrong or missing, and designing retrieval and pipelines around what is actually there.
- Building and shipping in the customer's stack. Opening pull requests in the customer's repos, going through their CI and code review, and deploying to their cloud accounts.
- Running evaluation. Maintaining the test set of real cases, measuring quality, latency and cost on every change, and reporting results in terms the business owner cares about.
- Working the integration. Connecting the system to the platforms where work happens: case management, CRM, ledgers, document stores, ticket queues.
- Clearing the path. Answering security questions, writing architecture notes, unblocking data access requests, and joining the customer's standups and demos.
The defining trait is ownership. A good FDE owns the outcome, not a ticket. If the model is fine but the integration is failing, they fix the integration. If the evaluation set is wrong, they fix the evaluation set.
FDEs vs consultants vs staff augmentation
Engineering leaders often ask how forward-deployed engineering differs from the two models they already know. The short answer: consultants advise, staff augmentation adds capacity you direct, and FDEs own delivery of a system inside your environment.
These are not mutually exclusive. A common pattern is to bring in an FDE team to build the first production AI system, then use staff augmentation to add specialists, such as AI engineers, to the internal team that will run and extend it.
When forward-deployed engineering is the right call
FDEs are worth it when the hard part of the problem is the environment, not the algorithm. Signs that you need them:
- Your data cannot leave your cloud, and every component needs security approval.
- The system has to integrate with core platforms that only a few people understand.
- A pilot exists but has stalled between demo and production.
- Your internal team is fully committed to the roadmap and cannot absorb a new system.
- You want to own the result, not rent a platform.
FDEs are a poor fit when you mainly need a decision rather than a build, when a packaged product already does the job, or when you only need one more pair of hands on an existing team.
What to look for in an FDE team
If you are evaluating partners, a few questions separate real forward-deployed teams from rebadged consulting:
- Will they work in our environment from week one? Ask specifically about repos, CI and cloud accounts.
- How senior is the team? FDE work needs engineers who can make architecture calls and talk to business owners without a layer of managers in between.
- Who is the technical owner? There should be a named tech lead on your standups, not an account manager.
- What have they shipped? Ask for production systems, with results, not demos.
- What does handover look like? You should be able to run the system without them.
- Are they in your time zone? Same-day code review and real-time debugging matter more than almost anything else.
Our roundup of forward-deployed engineering firms compares the main providers on these points.
How Ryz runs forward-deployed engineering
We run FDE work through AI pod teams: dedicated teams of around seven senior engineers, typically a tech lead, an ML engineer and backend engineers, working in your time zone. Engagements follow four steps. In Talk, we scope the problem, data and constraints. In Match, we assemble a team fitted to your stack, whether that is AWS or Azure, GitHub, Postgres, and models from Anthropic or OpenAI. In Embed, the team works in your repos, CI and standups, with weekly demos of working software. In Grow, you add people or disciplines, or we hand the system over to your team.
Production examples include an AI fraud detection system for a global fleet company that surfaced $5.94M in confirmed fraud across 244K+ scored invoices, validated by the client's fraud team, and an AI marketing compliance system for a global capital management firm that cut review of 8,000+ documents from days to hours.
How Ryz can help
If you have an AI system that needs to be built inside your environment, or a pilot that has stalled, our forward-deployed engineers work alongside your team until it is live. Tell us the workflow and we will come back with a scoped plan, a price and the names of the people who would do the work.
FAQ
What is a forward-deployed engineer?
A senior software engineer who works inside a customer's environment, against its real data and systems, to build and ship a working system. The role blends production engineering with direct work alongside the business users the system serves.
Is a forward-deployed engineer the same as a solutions engineer?
No. Solutions and sales engineers mostly support pre-sales demos and technical evaluation. Forward-deployed engineers write and ship production code and stay accountable for the system working after launch.
How is FDE work different from staff augmentation?
With staff augmentation, you add engineers to your team and direct their work. With FDEs, a team led by its own tech lead owns delivery of a specific system, while still working inside your repos and rituals.
How many engineers does an FDE engagement need?
It depends on the system. Our pods are usually around seven senior engineers, sized to the problem, and can grow or shrink as the work changes.
