How Forward Deployed Engineering is done at Ramp

What does forward deployed engineering own when its job is to help an enterprise customer succeed? At the time of this talk, Leo Mehr described himself as a director of engineering at Ramp. He had joined when FDE consisted of two engineers; his organization had since grown to roughly 30 engineers across FDE, developer API and AI services. That broader organization matters: the headcount was not an FDE-only team.

Ramp’s answer starts with where FDE sits. It belongs to engineering, with a mandate to help Ramp win upmarket by making the core product and new agentic features work well for its largest enterprise customers. Mehr rejects the idea that FDE is simply the final promotion in a sequence of technical go-to-market roles. The work carries responsibility for the product itself.

Two principles guide that responsibility: always be scoping and scale with tokens. The first determines what deserves to be built. The second changes how much of the work engineers can accomplish through models and agents.

Saying yes to every request is not the same as helping a customer. Mehr illustrates the difference with a horse that has rockets strapped to its legs: an accumulation of requested improvements can produce something very different from a well-designed vehicle. An FDE should look for a way to help while still delivering good software. Customer success requires deciding what the right thing is, not merely agreeing to build it.

Consider a recurring scenario at Ramp: it is Friday night, and an enterprise sales representative says a strategic deal will close only if the team builds an SAP S/4HANA integration. The engineering reflex is to find the SAP API documentation and start figuring out the implementation. A well-trained FDE pauses before accepting that framing.

The scoping conversation works through several questions:

1. What is driving the urgency? A quarter-end sales quota can create pressure that does not originate with the customer.
2. Who will use the integration? Identify the actual users and the work they need to accomplish.
3. What alternatives already exist? Check workarounds and whether a temporary manual process would solve the immediate problem.
4. Can the customer build the connection? A customer with technical resources may be able to use the Ramp Developer API without requiring Ramp to build the integration.
5. Who else would benefit? Look across existing customers and the prospect pipeline before deciding the scope of a reusable capability.

These questions turn a demand for a particular implementation into context for a product decision. The result may still be an integration, but the team can now explain why that integration is the right investment.

An early mobile reimbursement project made the cost of missing context concrete. A large enterprise customer needed a reimbursement feature on mobile, but Ramp’s mobile team was overloaded. Two FDE engineers stepped in, learned iOS and Android development, and spent a couple of weeks building the feature on both platforms. The team was excited to have pushed through the implementation bottleneck.

Then they asked the customer for Android beta users. The customer explained that it mandated iOS devices for all employees. Only after completing both versions did the team discover that the Android work was unnecessary for the requesting customer.

The mistake was not a failure to execute. It was a failure to validate a basic assumption before execution. Even a requirement as apparently straightforward as mobile support needs a question about which devices the customer actually uses. Engineering enthusiasm and the ability to learn a new platform cannot recover time already spent solving the wrong part of a problem.

Good scoping alone does not address the changing capacity of models. Mehr argues that FDEs must continually reconsider which parts of their knowledge work models and agents can perform. Scaling with tokens means applying that question to the whole job, rather than treating AI assistance as something that begins when coding starts.

The lifecycle provides a useful decomposition:

1. Gather context.
2. Scope the request.
3. Write a specification.
4. Implement the feature.

Each stage is a candidate for agent work. Replacing the entire lifecycle is an ambition, not a completed system in this demonstration; breaking it into stages makes it possible to improve one part at a time.

Ramp’s internal FDE Requests Slack channel receives significant customer and prospect blockers from account managers, solutions staff and sales representatives. The example on screen is a submission from Greg, a customer success manager. It comes through a Notion workflow; opening the request in Notion reveals its details.

Those details vary widely. Some submissions thoroughly describe the customer’s situation; others amount to a single line asking for an SAP integration. Previously, an FDE would read the request, understand what the product already supported, and go back and forth with the customer to establish what was necessary. The time-consuming work was precisely the questioning that prevented the mistakes in the first half of the talk.

Ramp’s first version used Notion agents to take a request and ask a couple of questions. It did not need to automate the whole lifecycle to be useful. After a couple of weeks, Mehr reported that reply latency in this intake workflow had fallen from hours or days to seconds. Representatives could start engaging with the agent immediately instead of waiting for an engineer’s initial response.

A later iteration adds a friendly penguin persona and continues through several rounds of questions with the submitter until the agent considers the request ready for a specification. The screenshot shows the FDE Intake Agent asking about the customer outcome, current workflow and available data. The important progression is from a small set of initial questions to an exchange that can develop the request before an engineer takes it further.

Mehr informally estimated that the assistant saved roughly 20% of the time spent scoping these requests. That estimate concerns this scoping workflow, not an organization-wide productivity gain. The demonstrated benefit is a faster start to clarification and less manual effort developing incomplete requests.

The intake assistant advances the first part of the lifecycle. At the other end, Mehr says frontier models can produce medium-sized features in one shot from well-shaped specifications, making implementation easier. This is his capability assessment; the talk does not define a feature benchmark or give a success rate.

The difficult middle remains: turning gathered context and an initial request into a specification good enough to drive implementation. Mehr describes that work as unformed and difficult, and identifies it as a focus for further investment. Ramp’s proposed agent factory would connect agents across the stages, but the working intake assistant is not evidence that the whole path from request to product has been automated.

Looking six to twelve months ahead from the talk, Mehr expects more FDE effort to move toward applied AI problems in this pipeline. Three responsibilities stand out:

• Agent operation: Keep the harness running each stage working smoothly.
• Output evaluation: Use evals, rubrics and human feedback to judge the quality of each stage’s output.
• Context delivery: Ensure that each LLM call receives the information needed for the decision it is making.

This is a forecast of how the role could develop as the team builds out the system.

Context delivery is especially difficult because product knowledge is not confined to documents. Historical decisions and the understanding a product manager carries in their head can change what a good specification looks like. Notion documents, knowledge bases and help articles capture only part of that understanding. Skills, memories and tools may help, but Mehr does not prescribe a particular implementation for them.

FDEs retain responsibility for taste and judgment over the final output. Moving work into agents changes how engineers produce a result; it does not remove their obligation to decide whether that result is good.

An agent factory inherits the quality of its scoping. If the system never establishes what the customer needs, faster execution produces more poorly directed work—what Mehr calls a “token maxing slop cannon.” The rocket-powered horse problem survives automation; it simply becomes easier to manufacture.

The opposite failure also matters. In Mehr’s view, a team that scopes brilliantly but does not invest in agents risks being overtaken by competitors that do. Scoping and token-driven capacity therefore have to develop together: one keeps the work pointed at a useful outcome, while the other expands the team’s ability to deliver it. The future of FDE needs both.