Factory's forward deployed engineers carry customer signals back into the product instead of doing consulting work on a customer's behalf.
2
A software factory turns signals into plans, code changes, validation, and deployments, with the aim of allowing that flow to run without human interruption.
3
Agent autonomy depends on codebases having enough deterministic checks to verify long-running work, and deployed engineers help customers build those checks at a workable pace.
Summary
Eno Reyes describes forward deployed engineering at Factory as product engineering carried out close to major customers. The deployed engineer learns how an organization builds software, feeds those observations into Factory's product, and helps the customer assemble a software factory around Droid. That factory takes in signals such as bug reports and executive requests, turns them into plans and code changes, validates the changes, and sends them to deployment. Reyes argues that customers need to own a model-independent harness, their traces, and their data, especially when Droid runs inside an air-gapped environment. He also explains that autonomy depends on agent readiness: linters, type checkers, security scans, tests, and other checks give agents feedback while they work. The role therefore combines engineering, systems design, business judgment, and communication. Factory wants examples that show what is possible without creating an isolated showcase that customers cannot apply to the rest of their codebase.
Factory keeps forward deployed engineering focused on improving the product
Factory does not want its deployed engineers to perform consulting migrations for customers, even when those migrations use Factory's product. Reyes says that work may produce revenue, but it does not improve the product enough to scale the business. Instead, deployed engineers become the product's "tip of the spear." They collect information from large and important customers, including how tactical engineers think about software development and AI in practice. That information flows back into Factory so the product can fit customer environments better. The product should eventually self-assemble inside those environments rather than require a team to install and customize every part by hand.
A software factory turns scattered signals into a repeatable path to deployment
Reyes defines a software factory as the process already present, implicitly or explicitly, in every organization. Signals can come from customer conversations, bug reports, internal Slack or Teams messages, or an executive decision to build something. People prioritize those signals and create plans. Developers turn plans into source-code changes, which then pass through review, QA, security assessment, SAST tools, linters, and type checkers before deployment. Deployed software produces more signals, creating a feedback loop. AI can transform each stage once the organization understands how its workflow moves from one stage to the next. The goal is a signal-to-deploy flow that is not interrupted by a human, while humans still build and maintain the system.
Customers need to own the harness, traces, and data behind their software factory
Reyes says a software factory is "built, not bought." Factory provides what he calls a model-independent agent harness, so a customer is not tied to one model provider or limited in what it can build. The customer also gets access to the data flowing into and out of Droid, along with enterprise governance and controls for deciding where information goes. This ownership matters as the factory changes over time. Some customers in finance, health care, and government run Droid entirely inside their own environments. Reyes says they can air gap it, and jokes that a deployed engineer claims Droid could run in a submarine.
Forward deployed engineers connect technical changes to business outcomes
At a large organization with tens of thousands of codebases and many thousands of engineers, a product cannot be installed manually everywhere. Deployed engineers help make the product self-assemble and help teams construct the software factory around it. They also need to define the outcome from the start. Reyes gives the example of measuring whether AI code review, QA, and security analysis reduce the chance that a code change creates a bug, then connecting that change to bug rates, customer satisfaction, revenue, growth, or new business. This requires both engineering knowledge and business knowledge. The role includes teaching the customer what an autonomous software organization could look like and creating a plan to get there.
Agent readiness comes from deterministic feedback loops in the codebase
Reyes defines agent readiness by the number of deterministic validation loops in a codebase. These include linters, type checkers, security scans, and end-to-end tests that give a clear pass or fail result. With more of these checks, agents can work longer on harder tasks without human intervention. Factory's Missions product is an elaborate harness for difficult, bounded knowledge-work tasks whose completion can be verified. Reyes says the output of a long-running agent harness depends directly on how well the work can be validated. Some improvements are straightforward, while others require workflow changes because people may resist automated checks they experience as overly exacting.
Long-running agents work best when completion can be verified
Reyes describes Missions as a harness where a person defines a bounded task and the conditions that count as completion, then lets inference continue until those conditions are met. This approach works well when a problem can be expressed through verification systems. He says Factory has seen it applied to codebases with 30, 40, or 50 million lines, deep learning work in biomedicine and health care, and financial workflows that analyze equities. These examples still depend on preparation. A customer cannot simply install an agent and press play. The environment must provide enough verification signals to keep the agent on track during a long task. Reyes connects this to model training, where dense reward helps models pursue complex goals.
A customer example must be advanced enough to teach without becoming a theme park
Reyes uses Epcot as a warning about how to demonstrate an autonomous codebase. Walt Disney originally imagined it as a planned city that could model future transportation and urban life, but it became a theme park. Other cities still borrowed some of its ideas. Factory wants a working example that customers can copy into other parts of their codebase. If the example is too far ahead, customers may see it as a theme park that does not resemble their current way of working. The deployed engineer has to find a pace that proves the future is possible while keeping the cost and practical path visible to the organization.
The deployed engineer's work shifts from writing software to designing the system that writes it
Reyes says engineers at an autonomous software organization move from directly manipulating software to maintaining and managing a system that builds software. That shift is difficult, even for thoughtful software engineers. He sees DevEx practitioners, technically minded product managers, former founders, strong communicators, and systems thinkers as good candidates for the role. They need to design workflows, close loops, model data, explain AI to different levels of an organization, and connect technical choices to business goals. Autonomy also has limits. Factory has an internal legal workflow that Reyes describes as fully autonomous, while visual problems such as flickering in a terminal-based harness remain difficult to verify automatically.
"If you can frame any problem as the set of verification systems that need to validate it, then you can solve that problem with AI today."14:47
Who should watch
You are building enterprise AI software and need to decide whether forward deployed engineers should do implementation work, product work, or both.
Your team wants agents to handle longer software tasks, but your codebase lacks reliable tests, linters, type checkers, or other pass/fail checks.
You need people who can connect customer workflows, agent infrastructure, and measurable business outcomes without turning the role into consulting.
