Decagon splits forward deployment between configuring the agent for an enterprise and turning repeated customer requests into product features.
2
As Decagon grew from 50 to 500 people, it separated agent builders from software engineers and put more emphasis on restraint, requirements, and reusable systems.
3
Forward deployed teams should prove value quickly, advise customers using patterns from other deployments, and turn custom integrations into self-serve capabilities.
Summary
Sunny Rekhi explains how forward deployed engineering works at Decagon, which provides an AI customer service agent for calls, email, and other channels. The work has two parts. Agent builders configure instructions, tone, actions, and human handoff rules for each enterprise. Software engineers handle the product problems that appear during deployments, with the expectation that repeated requests become platform features. Rekhi says this boundary has become thin enough that forward deployment and product engineering often have the same standards, reporting structure, and people. Decagon's growth from 50 to 500 employees led it to split the original generalist role into specialized lanes. The talk also covers defining success in writing, assigning industry knowledge to new deals, proving value before expanding the relationship, and resisting brittle one-off fixes. Rekhi's operating rule is simple: every manual or custom solution should move toward a capability that customers can configure or use themselves.
Decagon lands with support automation and expands into revenue work
Decagon provides a 24/7 AI customer service agent that handles calls and email with human-like replies. Forward deployed teams first help enterprises move complex support workflows away from human staff. After the agent has learned the customer's systems and established a relationship, the team looks for other customer communications it can handle. Rekhi gives Hertz as an example. Decagon first addressed complex inbound support, then used its backend integrations to contact customers proactively when it was time to renew or extend a car lease. The deployment therefore starts with support deflection and can expand into communications that make the customer more money.
Forward deployment has an agent-configuration side and a product-engineering side
One part of the job makes the AI customer service agent work for a particular enterprise. The team defines instructions, brand tone, actions the agent can take, and the user intents that should go to a human. Much of this configuration can happen in the UI. The other part handles product requests that emerge in customer conversations. If enterprise A asks for something, the engineer considers whether enterprises B, C, D, and E will soon need it too. Rekhi says this happens with 'stunning regularity.' At Decagon, forward deployment engineering and product engineering often have the same bar, reporting structure, and team because the distinction has become blurred.
Growth from 50 to 500 people led Decagon to split a generalist role
When Decagon had about 50 people, agent software engineers handled configuration, backend integrations, and platform work for customer requests. At 500 people, the company divided that work into two lanes. Agent builders, including Decagon Pros, develop intuition for the models powering the platform and configure them for enterprise use, mainly through the UI. Agent software engineers remain the frontline for enterprise product requests and bring those needs back into the product. The change reflects a need to design the system for scale rather than have every engineer handle every part of a deployment.
AI coding makes restraint a scarce engineering skill
Rekhi warns against accepting a customer's urgent request and immediately using tools such as Codex or Cloud Code to create a one-off fix. The engineer has to ask how the solution will work for future customers. Decagon wants its agents to be owned by customers, so a black box made of prompts and patches would be brittle and hard to maintain. A forward deployed engineer should resist the easy custom solution and design the work so that other enterprises can benefit. The company also wants customers to configure the agent through natural language, which means manual engineering work should eventually move into the product.
A deployment should define success before implementation starts
Decagon tries to establish the customer's definition of success during the first deal conversations. Rekhi recommends narrowing down the metrics, the support channels involved, the pain point, and the desired outcome, then getting those details in writing. The channels might include phone, email, text, or WhatsApp. This preparation reduces disagreement about what has to be built. Rekhi says large companies create a temptation to start immediately, but AI coding has increased the value of requirements gathering and alignment before implementation. Decagon also assigns industry specialists to new deals so knowledge from similar financial services or other vertical customers carries into the next deployment.
Forward deployed engineers should advise customers using patterns from many deployments
The job includes deciding which problem will create the most value, rather than executing every request exactly as submitted. Decagon ingests historical support data and can recommend automating one workflow before another because it expects a higher return. That recommendation may differ from the issue the customer originally raised. Rekhi says forward deployed people gain domain knowledge by working across companies, and customers should be able to use that knowledge. The engineer remains an executor, but also acts as an advisor who can identify a better starting point based on repeated patterns and the customer's data.
Custom work should become self-serve product capability
Decagon repeatedly moves manual work upstream into the platform. Rekhi describes integrations as an example. Early in the company's history, engineers built custom CRM integrations one at a time. After roughly the 25th integration, the team decided to make the process self-serve. Customers or the agent-building team can now do work that previously required custom code from an engineer. This is also a way to spread knowledge across deployments. When the agent improves through an interaction with customer A, the platform should carry that improvement to customer B. The field supplies information to the product, and the product makes later deployments faster.
"Your job isn't just an executor. It is of course to be an executor, but it is also an advisor."13:58
Who should watch
You are building an enterprise AI product and need to decide what forward deployed engineers should own versus what belongs in the platform.
Your team is growing quickly and custom customer work is starting to create one-off fixes, repeated integrations, or unclear ownership.
You need a practical approach to defining enterprise success, proving value early, and using deployment knowledge to advise customers.
