# How Forward Deployed Engineering is done at Ramp Leo Mehr, Ramp | AI Engineer World's Fair 2026 | 14:05 Source: https://www.youtube.com/watch?v=ITMXwI6QL6A Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks. Page: https://aietalks.com/talks/how-forward-deployed-engineering-is-done-at-ramp Published: 2026-07-28 Tags: agents, evals, human-in-the-loop, workflows ## TL;DR - Forward deployed engineers should pause and scope customer requests instead of automatically saying yes. - Ramp turns parts of the FDE request pipeline into agent-driven steps, starting with intake and specification. - FDE teams need human judgment for the final output and agents to handle more of the work volume. ## Summary Leo Mehr describes two principles from building Forward Deployed Engineering at Ramp. The first is to always be scoping. FDEs should understand what is driving a request, check workarounds and technical constraints, and compare one customer request with the needs of other prospects and customers. He describes a painful mobile reimbursement project where the team built for both iOS and Android before learning that the customer required iOS. The second principle is to scale with tokens. Ramp is applying agents across the FDE pipeline, from gathering context and shaping requests to writing specs and implementing features. Its first example uses Notion agents to question request submitters and create better-shaped specs. Mehr says the hard work is building the agent harness, evaluating output quality, supplying the right context, and keeping human taste and judgment over the result. ## Key ideas ### FDE at Ramp works inside engineering to make the core product fit enterprise customers [01:20](https://www.youtube.com/watch?v=ITMXwI6QL6A&t=80s) Ramp's FDE group sits within engineering and helps the company win larger enterprise customers. The team works on the core product and new agentic features so they work well for those customers. Leo Mehr says the group grew from two engineers when he joined Ramp to about 30 engineers across deployed, developer API, and AI services organizations. He frames the talk around two principles: always be scoping, and scale with tokens. ### Customer urgency is a reason to investigate, not an instruction to say yes [02:06](https://www.youtube.com/watch?v=ITMXwI6QL6A&t=126s) Mehr rejects the idea that an FDE's job is to say yes to every customer request. The goal is to find a way to help the customer while still building the right software. In his Friday-night example, a sales representative says an important customer will only close if Ramp builds an SAP S/4HANA integration. Rather than immediately searching for SAP API documentation, a well-trained FDE asks what is creating the urgency. The sales deadline may be driving it more than the customer's actual needs. ### Good scoping checks workarounds, constraints, and demand beyond one customer [03:59](https://www.youtube.com/watch?v=ITMXwI6QL6A&t=239s) Mehr says FDEs should ask who will use an integration, whether workarounds have been exhausted, whether a manual process can bridge the gap, and whether the customer has technical resources that can call Ramp's API. They should also examine the broader pipeline and other customers to see whether a request has wider value. This context helps the team decide what to build. Scoping is about understanding the request before engineering effort is committed. ### Unvalidated assumptions can waste weeks of FDE work [05:00](https://www.youtube.com/watch?v=ITMXwI6QL6A&t=300s) Ramp once worked with a large enterprise customer that needed mobile reimbursement. The mobile team was overloaded, so two FDE engineers learned iOS and Android development and built the feature for both platforms over several weeks. When they asked for Android beta users, the customer said all employees were required to use iOS devices. Mehr describes this as a painful lesson. Even a basic assumption about the target mobile platform needs to be checked before the team starts building. ### Agents can take over stages across the FDE lifecycle [06:29](https://www.youtube.com/watch?v=ITMXwI6QL6A&t=389s) Mehr says scoping alone is insufficient because FDE teams also need to scale with model capabilities. He describes the full lifecycle as gathering context, scoping a request, writing a specification, and implementing the feature. Each stage can potentially be replaced or supported by agents. He presents the problem as manageable when broken into smaller stages. Ramp started with request intake, where account managers, solutions engineers, and sales representatives submit blockers for large prospects or customers. ### Ramp's intake agent turns uneven requests into usable specifications [07:57](https://www.youtube.com/watch?v=ITMXwI6QL6A&t=477s) Ramp receives FDE requests in an internal Slack channel, with a Notion workflow containing the details. The submissions vary widely. Some are thorough, while others are a single sentence such as a request for an SAP integration. Previously, FDEs read each request, checked what the product already supported, and went back and forth with the customer. Ramp built a first version with Notion agents that asked a few questions. A later version conducts several rounds of questions until it decides the request is ready for a specification. ### The difficult work is the agent system around each pipeline step [10:48](https://www.youtube.com/watch?v=ITMXwI6QL6A&t=648s) Mehr says the intake stage has become easier, as has the final step from a well-shaped spec to a working product. He expects the middle of the pipeline to remain more difficult and less formed. Ramp's work will include building an agent harness for each step, checking output quality with evals, rubrics, and human feedback, and giving agents the right context. That context can include historical data, product information, Notion documents, help articles, skills, memories, and tools. ### Human judgment still decides whether the agent output is good enough [12:10](https://www.youtube.com/watch?v=ITMXwI6QL6A&t=730s) Even if Ramp builds an effective agent factory, Mehr says FDEs retain responsibility for taste and judgment over the final output. Poor scoping would produce a high-volume system that creates low-quality work. The reverse also creates a problem: a team that scopes well but does not build agents may be overtaken by agent-native competitors. His conclusion is that FDE needs both disciplined scoping and agent-based scale. ## Notable quotes - "Always be scoping and scale with tokens." (02:06) - "But what a well-trained FDE would do is pause for a second and say, "Okay. First of all, what's driving the urgency here?"" (03:40) - "And so, the whole point is that you have to do these both because the other way around is actually quite bad as well." (12:35) - "The future of FDE needs both." (13:21) ## Tools & references mentioned - Ramp - SAP S/4HANA - Notion - Waymo ## Who should watch - You run forward deployed engineering or customer-facing product work and need a better way to decide which requests deserve engineering time. - Your team receives customer requests through sales or account teams, and the intake process still depends on engineers reading and clarifying every submission. - You are building agents for internal workflows and need practical guidance on harnesses, evals, grounding context, and human review.