Forward-deployed engineering

Engineering close to customer work

At Palantir, “forward deployed” described where an engineer worked as well as what the engineer did. Natalie Meurer’s slide reproduces Palantir job postings from around 2016. The same engineering title appears beside Helsinki, Canberra and other cities. Much of the software ran on customer premises, so the engineer who sat with the people using an installation was also there to investigate when it went down. Meurer’s account [1][2][3]

Technical customers can need this work too. At Sierra, Natalie Meurer and Sonos technical staff scoped the speaker-connection problems a customer-facing troubleshooting agent would encounter across the Sonos portfolio. Their product knowledge determined what the agent had to help a listener do. Sierra calls the role agent engineer. Its engineers “work with our customers to design, build, and ship agents.” At Cursor, Pauline Brunet describes another reason to embed. A programmer can adopt a coding tool individually, yet getting several teams to use it across planning, review and deployment requires people who can change those practices together. The relevant question is how much the customer can put into use with the product it has. Brunet on FDE at Cursor [4][5][6]

Cognition’s Jia Wu describes the deployed engineer’s two obligations in her own words. Alongside solving the customer’s problem, “we also need to solve for our product.” When engineers match Devin to work in a customer’s backlog, a local workaround can reveal a gap that other customers will face. On Wu’s slide, follow the arrows between “Solve the Problem” and “Solve the Product.” The overlap represents work the product can already do that customers need. A customer can accept a fix today while the product team is still deciding whether to support it more widely. Choosing which market to enter is a separate decision. Wu on FDE at Cognition · Choosing a reachable customer problem [7][8][9]

How the responsibilities accumulated

The gap between buying a technical product and putting it to work predates enterprise AI. In the 1970s, Intel’s applications engineers helped customers design systems around microprocessors. Example circuits, development tools and programming instruction equipped customers to do subsequent designs themselves. Scandinavian participatory design addressed a different question in the same decade. Workers wanted a say in how computerization changed their jobs. In the early-1980s Utopia project, graphic workers could act out newspaper production with physical mockups when drawings had given them little basis for judging a proposed tool. [12][13]

Early work on contextual design at Digital Equipment Corporation in the 1980s brought designers into the workplace to ask about decisions as people made them. A further difficulty arose when the tools people used came from different suppliers. IBM’s retrospective on the early 1990s describes customers needing someone who understood their business and could make separately purchased systems work together. These practices illuminate three enduring responsibilities in field engineering: teaching people to apply a product, learning how they work, and connecting the systems their work crosses. [14][15]

Palantir’s field and product engineers

Palantir was using the title Forward Deployed Software Engineer by about 2012, judging from one engineer’s seven years in the role at the time of a 2019 interview. Nabeel Qureshi joined in 2015 and worked alongside Airbus manufacturing staff. His team brought work orders, missing-parts records and quality issues into one interface. Where field engineers built a view for a particular job, product engineers looked for tasks that recurred across deployments. Qureshi traces Foundry’s tools for importing data, exploring it and building applications to those recurring needs. Palantir’s engineering interviews · Qureshi’s recollection [16][10]

Palantir’s Project Frontline gave product engineers direct experience of customer work. Vinoo Ganesh recalls sending engineers on rotation, where shipping a small fix could earn the trust needed to investigate a harder problem. Engineers remained responsible for their fixes after leaving the site. The growth of Foundry also changed who could build the next application. On Airbus’s Skywise project, training Airbus engineers to build on Foundry became part of the deployment team’s work, alongside maintaining the platform and its integrations. Ganesh’s account of Project Frontline in Latent Space · Meurer on training customer engineers [17][18][19]

Dedicated deployment companies

In 2026, model providers also formed companies dedicated to deployment. On May 4, Anthropic, Blackstone, Hellman & Friedman and Goldman Sachs announced a services venture to help mid-sized companies use Claude in core operations. It launched on July 15 as Ode with Anthropic, a standalone firm whose operating team drew from Fractional AI and Anthropic. On May 11, OpenAI announced the OpenAI Deployment Company, or DeployCo, as a majority-owned company under OpenAI’s control. Its stated mandate included selecting workflows with customers and connecting models to their data, tools and operating controls. These were commitments about who would organize delivery. Establishing customer benefit still required following the work inside each engagement. May partnership announcement · Ode launch · DeployCo launch [20][21][22]

Learning from work as it happens

Discovery investigates a customer’s problem while the choice of intervention is still open. Ganesh puts the limit of an interview precisely: “You cannot infer from a discovery call how a specific company closes its books.” Ask someone to walk through a recent case with the records and tools they have permission to show. Asking questions as work unfolds is called contextual inquiry. A wait, a lookup in a second application or a call to a colleague gives the engineer a specific decision to ask about. Ganesh’s field account · Contextual Design [17][14][23]

Keep the stated procedure, the observed action and your interpretation distinct. Suppose a reviewer says they approve a report, then opens a source record before signing. You saw a lookup. Whether the reviewer distrusted the report, needed a missing detail or had an obligation to inspect the source remains open. Ask what they checked and what would have changed their decision. Ask the recipient what they needed from the approval. If the obstacle was finding the evidence, try a mockup that opens the source beside the report and let the reviewer replay the case. [24][14]

Sometimes the uncertainty concerns what an existing system does. In Cognition’s account of a refactoring project at Itaú, bank experts traced tax identifiers through programs and found several representations. Their findings went into the playbook used to change the code. A request to update an identifier had become an implementable requirement once the engineers knew which representations the change had to accommodate. Cognition’s migration account [25]

Who does the work and decides

A workflow is the set of connected tasks and judgments that produces a useful result. Follow one result to its recipient to find the people affected by a proposed change. These stakeholders can have different interests and authority. An operator can show where time goes. A domain expert can resolve a question of meaning. A process owner answers for the overall result, while a system owner can authorize access to the records it depends on. The buyer may hold one of those roles or none of them. [26][27][28]

Consider failure triage, the investigation that helps an engineer decide what to do about a failed test. Cognition reports an RV Tech workflow in which an issue in Slack leads to log retrieval, diagnostics and a structured report for engineering review. That identifies the report’s recipient. It leaves questions for the customer about who may read particular logs and who may authorize a corrective change. Cognition’s automotive engineering account [29]

Have participants correct the map. If the buyer wants an earlier decision and the reviewer needs stronger evidence, both requirements belong on it. If nobody can authorize the data access, faster diagnostics cannot remove that constraint. Workflow redesign addresses changes to the process itself. Enterprise AI covers adoption across the wider organization. [30][28]

Making business meaning explicit

A domain model describes the facts and rules of the business that matter for a particular task. Eric Evans calls the vocabulary that engineers and domain experts develop from that model a ubiquitous language. Its value appears when an expert can read a term in a design and correct the behavior it implies. A bounded context is the scope within which a meaning holds. Two teams can legitimately use the same word differently. Evans’s Domain-Driven Design Reference [32]

A system of record is authoritative for a particular fact. In this example the runner can establish execution time, and the queue can establish acceptance time. Agree on how a case refers to its run, including what happens when a test runs again. Preserve both events. Copying the earlier timestamp into the review record would make a waiting case look accepted. Apply the same care to amounts, units, time zones and absent values. Ask an expert for a case where unknown and inapplicable require different actions, then encode the distinction where the systems meet. Software Engineering Fundamentals [33][34][32]

Defining success with the customer

Once people agree on what happened, they can specify what improvement would look like. The baseline is the credible current alternative. Observe it before changing the work. If a team wants to reach a decision sooner, measure from the event that opens the case to the decision reaching its recipient. Keep cases that waited for evidence, needed correction or remained open visible in that account. Timing only the preparation of a report could suggest a gain even if every decision still waits until the same weekly meeting. Comparison baselines [35][28]

Brunet describes Cursor customers participating in scoping, implementation, validation and comparison with the baseline. One way to organize that work is a short agreement naming intended users, eligible and excluded cases, the comparison period, quality requirements, operating duties and the person who can change the scope. Write acceptance criteria as observable conditions for a decision. Brunet on customer participation · Cases and outcome boundaries [36][28][37]

Choosing a bounded change

A vertical slice carries one narrow class of work all the way to a result someone can use. Choose its scope by finding the step that holds up that result. If a reviewer spends most of the time finding the source record for a report, a lookup that joins the two by identifier may be enough. The reviewer can then check the evidence and make the decision. A model that drafts reports would address time spent writing, leaving the lookup untouched. Depending on the obstacle, the useful change might be removing a redundant step, applying a fixed rule or helping someone interpret the evidence. Allocating work and authority · Bounding a dynamic decision [38][39][40]

In the RV Tech case, proprietary test software made integration part of the field work. Follow the evidence in the figure. The Slack issue identifies an investigation, the logs supply diagnostic evidence, and the report puts the findings in front of an engineer. Delivering a reviewable diagnosis is a defensible endpoint. Claiming a repair would require following a further decision, change and verification. [29]

A proof of concept tests feasibility. A pilot admits limited real work to learn what happens when people rely on the result. Production commits someone to operating it on continuing terms. Before a pilot, name the reviewer and exception owner, make sure they can handle the incoming volume, and decide what failure would require restricting use. Narrow the class of issues if review capacity is limited. Defer if the essential records are inaccessible. Stop if an existing, supportable change meets the agreed objective at lower effort. [41][42][39]

Preserving meaning across integrations

An integration contract is an agreement about what crosses a system boundary and what each side owes the other. With the customer’s system owner, identify authoritative fields, identifier scope, units, missing values and how current a record must be. Agree on permitted reads and writes, where the connection may run, operating limits, who notices a broken feed and who responds. These obligations extend beyond a schema. The Open Data Contract Standard, for example, includes quality, service levels, roles and support channels. Open Data Contract Standard v3.0.0 [43][33][34]

Consider a proposed update to the review queue. Once execution finishes and the required diagnostic report exists, the case may become ready for review. An adapter translates the source identifiers and milestone into that update on the linked case. A separate decision belongs to the customer: which identity may record readiness, and who may accept the diagnosis? Grant the integration only its required permissions and enforce them at the receiver. Even perfectly translated data can be submitted by someone without authority. Privacy and Data Governance · Preserving meaning across applications [34][44][31]

Check the effect on the intended case against the source evidence. A successful response to a write on the wrong item still leaves the right case waiting. Conversely, the receiver may commit a correct write after the caller’s deadline expires. Keep the operation identifier, query authoritative status and leave the case open while the effect is uncertain. Resend only under a retry contract that prevents duplicate effects. Recovery after external effects [45][37]

Containing customer variation

Configuration selects a behavior the product supports. Customization extends behavior beyond those choices. Separate the reason for the difference from the code that connects the systems. A region name may need translation, a connector may need to read the region from a customer record, and a policy may prescribe different treatment in that region. Sierra describes translating policies that vary by region or customer plan into agent behavior. A change in customer policy should be possible to inspect separately from the mechanics of reading the record. [46][47][34]

Making a difference configurable creates a support promise for the combinations users can select. Test how the new review rule interacts with existing ones, including which reviewer receives a case when both rules apply. A bounded local extension may be easier to sustain if the requirement belongs to one customer and has a capable owner. If neither team can maintain the variation through an upgrade, narrow or decline it. Evidence for a shared requirement can be collected while the local arrangement is in use. [48][50]

Testing a complete working slice

A test of the slice begins with the input the customer actually receives and ends where the recipient can verify the agreed result. In an automotive customs migration reported by Cognition, the customer supplied existing input and output cases. Devin produced a Python implementation. When a case produced a different result, the team had a concrete discrepancy to investigate and used what it learned to refine the migration playbook. The customer’s examples made behavior in the old system available for comparison. Customs migration case [25]

Ask an operator and a domain expert to choose an ordinary case, a case whose interpretation people dispute and an exception with a consequential outcome. For each, inspect the source, the behavior under the customer’s configuration, the reviewer’s decision and the recipient’s record. When evidence is missing, the exception owner needs the case identifier, what was checked and what decision remains. Confirm that the person received it. A successful referral can coexist with an unresolved original task. Case assessment · Software Engineering Fundamentals [37][51][31]

Before admitting real work, have an operator deploy the slice, locate a failed case, restrict the affected operation and contact the person responsible for recovery. Keep resolved failures as regression cases with an owner who can update the expected result when policy changes. Passing these checks gives the customer grounds to try the slice within its tested limits. Whether it improves the work becomes observable during use. [52][51][41]

Making everyday use workable

Adoption means sustained use for the work the customer intended to change. Provisioned accounts tell you who can start. First attempts tell you who tried. Follow the share of eligible work actually handled through the system over successive periods, then watch a case that went around it. Brunet describes the difference between one programmer trying Cursor and a team changing how it plans, reviews and deploys software. A local champion can help an engineer reach the other people whose work must change. Brunet’s enterprise deployment interview [53][54][55]

Compare a case before and after introduction. Who gathers the evidence now? Who checks and corrects the output? Who fields questions when the original engineer is away? A reviewer who remains accountable for an amount may still have to repeat the lookup that the preparer has stopped doing. Training can help with an unfamiliar control. It cannot grant missing access or remove a requirement to check a source. This attention to the work of incorporating a practice into daily life is central to Normalization Process Theory. Collective action in everyday work [55][36]

To find out whether a direct link would help reviewers, time the step from opening the report to finding the supporting entry. Let the same reviewers try the same cases with and without a link, varying which view they see first to limit the advantage of a familiar case. Check that they find the right entry and reach the same decision. A shorter search would support adding the link. To judge its value in everyday use, include the work of preparing the reports, maintaining the links and reviewing the evidence once it is open. Design Engineering and AI Interfaces · Enterprise AI [56][57]

Establishing customer benefit

Measure the workload covered by the customer’s decision. In Generative AI at Work, support workers at one software company could use, edit or ignore suggested responses and documentation links. They remained responsible for the messages. The researchers studied a staggered introduction of access and examined issues resolved per hour alongside handling time, resolution rates and customer satisfaction. They found an average productivity improvement that varied across workers. Including work regardless of whether a suggestion was accepted made the question relevant to someone deciding whether to offer the assistant. Selecting only accepted suggestions would answer a narrower question. Generative AI at Work [58]

A team can produce more accepted work with the same staff and budget. That is a throughput gain. To claim released capacity, show that comparable work takes fewer total staff hours and identify what those hours can now accomplish. If they produced the extra output, counting both as separate benefits would count the same gain twice. A cash saving requires evidence of lower spending after delivery and operating costs. For an automation claim, also specify where human involvement ends. A report drafted automatically and approved by a person still incurs review effort. Technical due diligence on automation claims [61][35][60]

Investigate what else changed. METR reported that shifts in who participated and which tasks they selected made a follow-up developer-productivity estimate unreliable. In an FDE pilot, easier cases, another process change or intensive help from the field engineer can likewise alter the result. Repeat the comparison under ordinary support. Expand where the agreed outcomes hold, restrict eligibility where they diverge, and revise or stop when the gain disappears after accounting for review and support. Causal comparisons · Testing a failure explanation [57][62][41]

Demonstrating operating ownership

Handoff is the acceptance of an operating duty together with the knowledge, access and authority to perform it. Name the receiving people while they can still participate in building and validating the system. Brunet recommends leaving documentation with customers who have taken part throughout. Those customers might own local policy and day-to-day review while the supplier continues to release the product and repair connectors. Specify support hours, known limits and escalation contacts for each duty. [36][52][28]

Exercise the transfer. Google’s internal service-onboarding practice pairs documentation and access with hands-on operating exercises and transition support. A customer team can adapt that idea using a runbook, the instructions for performing a recurring task. Ask the receiving owners to use their own accounts while the original field engineer observes. Record the duty each person performed, where assistance was needed and which obligations each team accepts. Google’s SRE engagement model [63]

If the receiving operator can identify a fault but cannot release its fix, their accepted duty can end at a documented escalation to supplier engineering. Retest any duty that still depends on the original engineer’s access. Once normal staffing takes over, recheck customer benefit under that arrangement. Assigning operating decisions [63][59]

Turning observations into product decisions

Give product engineers enough evidence to consider a different solution from the one the customer requested. Describe the intended task, what the operator did, the condition that blocked progress, the workaround and any intervention the field team tried. Include what happened afterward and what remains uncertain. Remove identifying details and credentials from shared examples. Two requests for an approval button can have different causes. One reviewer may be unable to find an existing control. Another may need to record a second decision the product cannot represent. [66][67]

Wu asks whether a workaround serves one user or reflects a difficulty across an enterprise. Answering that question informs a proposal. Authority to commit the product is another matter. In Palantir’s 2019 interviews, field engineers could contribute core code, product engineers reviewed proposed changes, and larger features needed validation against roadmap priorities. Leo Mehr describes Ramp’s field engineers embedding with its largest customers and shipping core product changes. The ability to implement a change tells the customer who can do the work. A commitment to maintain it still needs an authorized owner. Palantir’s division of responsibilities · Mehr’s Ramp account [67][16][68]

Classify the obstacle before routing it. A documented feature that fails warrants repair. A supported operation that is hard to discover may need better guidance or onboarding. A missing capability calls for a scope decision about a connector, setting, extension or shared behavior. GitLab’s published process separates malfunction reports from enhancements and gives product managers discretion over the latter. Return the decision and its reasoning to the field team, including the supported local option or the evidence needed to reconsider. GitLab’s feedback framework [66][47]

Validating a shared capability

Productization means accepting responsibility for a capability across a defined range of uses. Sunny Rekhi describes engineers at Decagon repeatedly writing connections to customer relationship management systems, or CRMs. Decagon made setup available through the product. For a supported connection, a customer or agent builder could now do work that previously required an engineer to write code. Builders could also identify where a requirement exceeded the interface and bring it to the engineers responsible for product changes. Rekhi’s account of FDE at Decagon [69][70]

Testing the boundary of reuse

Test a proposed shared interface where the original customer’s assumptions break down. Suppose a returns system stops reminders when a borrower hands an item back and lists it as available when staff receive it. At a returns counter, one transaction can establish both facts. For a mailed return, the borrower hands the item to a carrier days before staff receive it. If the interface exposes only a single ‘returned’ flag, setting it at pickup releases inventory too early. Waiting for receipt keeps sending reminders after handoff. A shared interface can represent both events and let each customer map its own records to them. [50][48][33]

Expand ⤢

A domain expert can replay those contrasting cases before a second live deployment. Test both when the shared interface changes. Name who maintains the common code, who updates local mappings, and who handles a new source that cannot supply the evidence. Plan migration for existing users too. Microsoft describes letting Dynamics 365 customers compare a replacement manufacturing-planning service in their sandbox environments and opt in before wider migration. For a field-built replacement, agree which comparisons justify moving each use and when it is safe to retire the older path. Microsoft’s Dynamics 365 account [50][48][49]

Identify who will use the reusable piece. Customers configuring their own connections depend on a supported product interface. Delivery engineers using a common connector service also need someone to operate that service. These promises can have different owners, even when they share code. Choosing platform service boundaries · Separating shared product from customer service [71][72]

Frequently asked questions

Open questions

1. 01

   Which benefits survive the transition to ordinary staffing? During a pilot, a field engineer may clear exceptions while early users select easier work. Following comparable eligible cases through handoff, including unresolved work and support hours on both sides, would help a customer decide what it can sustain. [57][59]

2. 02

   When does self-service reduce the total cost of deployment? Removing a coding task can introduce configuration, compatibility tests and new requests for help. Following the same capability into deployments with different policies would show which work disappeared, which moved and what the supplier now has to maintain. [69][48]

3. 03

   Which review arrangements catch consequential mistakes at an acceptable cost? In a study using fabricated proctoring alerts, trained reviewers accepted some false alerts. A later study emphasizing corroboration found higher rejection, but used different sessions. Comparing the same kinds of known errors with different evidence displays could help teams decide where human review actually improves the outcome. [78]