How Forward Deployed Engineering is done at Factory

When a software company embeds engineers inside a customer’s organization, what are those engineers there to deliver: a customized installation, a finished project, or a better product? Forward-deployed engineering grew out of Palantir’s practice of putting engineers close to customers’ real-world requirements. The track introduction places OpenAI, Anthropic, and Google DeepMind among the companies expanding these teams, alongside a program featuring Anthropic, Cursor, Factory, Ramp, and Decagon. Factory’s perspective comes from co-founder and CTO Eno Reyes, whose previous work includes machine learning and software engineering at Hugging Face and Microsoft.

The job title does not settle the question. A deployed engineer might sit closer to product or engineering, work on behalf of customers or alongside them, and spend more time writing code or coordinating people and strategy. Historically, embedding was often an access requirement: the codebases, data streams, and integration points lived behind the customer’s organizational boundary. But that arrangement now covers several distinct businesses.

Titles such as forward-deployed engineer, deployed engineer, and applied AI engineer can conceal these differences. Understanding the delivery model matters more than choosing the title.

Consider a customer who has obtained consulting quotes for modernizing a codebase and asks Factory to take on the migration. Factory’s goal is not to perform that project as a service—even if its engineers would use Factory’s own product. Reyes’s reason is economic and technical: consulting can generate revenue without improving the product enough to support a much larger business.

Deployed engineers are a customer-to-product feedback channel. Reyes calls them the “tip of the spear of the product.” They gather information from both engineering leadership and engineers doing the daily work at Factory’s largest and most critical customers: how development actually happens, how people use AI, and where the product fails to fit. That information flows back into rapid product changes. The desired result is a product that effectively assembles itself inside the customer’s environment, rather than requiring a continuing supply of embedded labor.

This still requires substantial customer work. Someone must understand the environment, map its workflows, and establish why changing those workflows creates a return. Factory supplies building blocks for a software factory; the deployed engineer helps connect those blocks to the customer’s actual development process and business outcomes.

Every software organization already operates an implicit factory. Customer conversations, bug reports, Slack or Teams discussions, and executive directives enter as signals. Those signals carry different weights; people prioritize them, triage them, and turn some into plans. Developers then translate plans into changes to a source of truth, usually a codebase or engineering system.

Changes pass through validation: code review, QA, security assessment, static application security testing (SAST), linters, and type checkers. Once the checks pass, the organization ships and deploys. Monitoring the deployed software produces more signals, closing the loop. Reyes describes this loop as poorly instrumented in most organizations: the stages exist, but the transitions and feedback are not understood well enough to automate reliably.

The autonomy target is an uninterrupted path from signal to deployment. That does not remove humans from engineering. It changes where they intervene: people construct and improve the system through which work flows, rather than necessarily interrupting each individual change. Reaching that state requires understanding and transforming each stage, including the handoffs between them.

A platform can supply the harness, but the organization still has to invest in constructing its factory. Reyes identifies three foundations for that investment:

• Model independence: A factory tied to one model risks both higher costs and dependence on a provider’s decisions about what can be built.
• Access to data and traces: The customer needs the information flowing through the system to understand it and evolve it.
• Enterprise governance: Centralized controls must determine where information may flow.

Factory’s Droid is the agent harness intended to provide these foundations. Access to data should not be confused with automatic recording of every message: Factory’s current data-flow documentation describes message-content traces as optional and customer-configured.

Reyes reports that customers in finance, healthcare, and government run Droid in air-gapped environments. A colleague’s submarine example makes the intended boundary memorable: the software factory can be entirely contained. In practical terms, current deployment documentation requires internal model endpoints and telemetry collectors, with artifacts imported offline, for fully air-gapped operation.

The deployed engineer must understand the building blocks well enough to help a customer construct its factory, while improving the product toward one-click self-assembly. Reyes invokes organizations with tens of thousands of people, potentially hundreds of thousands of engineers, and tens of thousands of codebases. At that scale, manually installing and adapting every instance cannot be the operating model. Self-assembly is the product direction, not a reason to skip understanding the environment.

The outcome story must be clear from the beginning. Reyes offers an illustrative scenario in which changes receiving AI code review, QA, and security analysis are 87% less likely to encounter a bug. He then follows the proposed causal chain: reduce the bug rate by some amount, improve customer satisfaction, and connect that improvement to revenue, growth, or new business. The percentage is hypothetical; the useful requirement is to connect engineering interventions to business goals. Doing that requires both engineering judgment and business knowledge.

Teaching the operating model is another part of deployment. Many organizations lack an autonomy maturity model or a roadmap for becoming an autonomous software organization. Engineers must learn to evolve, refine, and scale a system that builds software, rather than directly manipulate every piece of software themselves. That increase in abstraction has a learning curve even for experienced engineers.

Developer-experience practitioners already think about enabling other developers. Product managers willing to become deeply technical can also fit this work, as can engineers accustomed to high-quality development environments. Workflow design extends the feedback channel across the whole product: enterprise controls, Droid, orchestration workflows, observability, cost controls, automatic model routing, and harness quality can all improve through close work with varied customer organizations.

Agent readiness begins with deterministic feedback. A linter, type checker, security scan, or end-to-end test produces a result the agent can act on: the change passes or it fails. Reyes describes readiness in terms of how many of these validation loops exist in a codebase. More feedback lets agents work for longer on more complex tasks without needing a human to tell them whether they are on track.

A small validation entry point illustrates the mechanism. In a project that already defines these scripts, the shell exposes a single pass/fail result while preserving the individual checks:

#!/usr/bin/env bash
set -euo pipefail

npm run lint
npm run typecheck
npm run security:scan
npm run test:e2e

A failed command stops the sequence and exposes a concrete problem to repair. Passing means these checks accept the change; it does not establish properties the checks never examine. That distinction becomes increasingly consequential as the agent’s task grows longer.

Missions applies this principle to difficult, validatable knowledge work through a long-running harness. Reyes describes output quality as directly proportional to the ability to validate the work. The practical implication is to invest in verification capacity as part of increasing autonomy, rather than treating validation as an inspection performed only after the agent finishes.

Factory provides tools to scan for readiness gaps. Reyes estimates that Droid can fix roughly 30–40% of low-hanging readiness issues on request, while describing roughly 60% as potentially requiring workflow changes. These are rough estimates without a defined evaluation population. Some of the harder changes involve people: stricter automated checks may feel excessively nitpicky, and introducing them carelessly can interrupt the human development flow. Deployed engineers have to improve the feedback system while understanding the team that already works inside it.

Missions moves most human involvement toward planning. Its operating sequence is straightforward:

1. Specify a bounded task worth solving.
2. Define what a completed solution means in verifiable terms.
3. Let the harness continue working against those conditions until the task is complete.

The decisive property is not merely that the task can be described, but that completion can be checked. Reyes makes the broad claim that problems expressible through the verification systems needed to validate them can be solved with contemporary AI. Current Missions guidance is more operationally bounded: it calls for scriptable validation and discusses errors, intervention, and recovery.

Reyes reports fully autonomous migrations of codebases containing 30 million, 40 million, and more than 50 million lines. He does not supply customer identities, validation criteria, durations, or details of human assistance, so the examples establish the scale of his claim rather than a reproducible migration benchmark. The accompanying slide expands from bounded tasks through multi-step missions to all knowledge work, with custom skills, orchestration files, validation as context, and human checkpoints beneath the progression.

The other applications he describes extend beyond code migration: advanced deep-learning work on biomedical and healthcare problems, and financial institutions using agents for equity research. In the latter, the work includes building and comparing models of equities and constructing systems that can backpropagate and/or trade on top of them. These are separate examples of knowledge work organized around evaluable outputs.

None of this is simply a download, installation, and start button. The necessary investment shifts from manually solving the task toward preparing an environment that can verify its solution. Without agent readiness, a customer may fail to benefit from even a highly capable system. Reyes connects this to dense reward in model post-training: frequent verification signals help keep work directed toward a long-term goal. Runtime checks provide feedback here; that explanation does not imply the deployed harness is training model weights online.

A deployed team cannot personally transform every repository. The scaling strategy is to establish the model in a few places, then let the customer’s own team spread it across the company. Reyes uses Disney’s Epcot as an analogy: an intended exemplar city became a theme park. In his telling, its urban-planning and transit ideas nevertheless influenced later cities, including cities built during the preceding half-century.

The useful software equivalent is a working codebase that makes a different way of developing software visible and achievable. Other engineers can recognize the pattern and bring it into their own part of the organization. But an example can become too advanced or too exceptional. If colleagues see a theme park rather than a plausible version of their own environment, they will not copy it. The deployed engineer must demonstrate meaningful progress without making the cost and pace of transformation seem impossible. That is the practical force of Reyes’s observation about an unevenly distributed future: isolated examples matter only if others can adopt them.

Reyes reports roughly 15–20% autonomy at Factory and an autonomy ratio in the upper-80% range. His accompanying explanation refers to human and AI actions before interruption, but does not define the denominator clearly enough to reconcile the two figures. The current software-factory product page instead defines autonomy ratio over merged work completed end-to-end by agents without human touch; that newer definition should not be applied retroactively to these reported numbers. Reyes also says some customer codebases are more autonomous than Factory’s because their work is more constrained.

That constraint points to where complete autonomy may arrive first: contained internal tools. Reyes describes Legal Droid, Factory’s internal legal workflow, as effectively 100% autonomously maintained. Its contrast with the core Droid harness is instructive. The terminal-based harness still has visual problems for which Factory lacks adequate validators, particularly flickering. Without a reliable way to detect the defect, the system cannot close the repair loop.

The remaining work is an engineering problem in its own right: build systems that can verify difficult properties. Human visual perception and knowledge of the outside world remain valuable precisely because they help identify and formalize what the current checks miss.

This scope explains the profiles Factory seeks. Former founders can help define emerging product areas rather than merely implement a predetermined installation. Reyes sees individual stages of the software development lifecycle—code review, incident response, QA, and testing—as potential billion-dollar businesses. That is his assessment of the opportunity, not reported revenue.

The role combines several capabilities:

• Builder: Turn customer problems into working systems and product improvements.
• Teacher: Be fluent in AI, communicate with people at every organizational level, and connect technical decisions to business concerns with executive presence.
• Systems thinker: Design feedback loops, model data, and understand how work should flow through a complex organization.

These skills meet in the same task: helping a customer build a system that can increasingly maintain and improve software, while feeding what is learned back into the product.

Reyes closes by inviting interested engineers to contact him directly or apply for the role he calls “Engineer, Deployed.” The current listing is titled Software Engineer, Deployed. The work is to make the next customer deployment more repeatable, the next workflow more verifiable, and the customer’s own team more capable of extending the system.