AI Engineer World's Fair 2026

How Forward Deployed Engineering is done at Decagon

Sunny Rekhi· FDE CTO,

Decagon18:09

Read the talk

How Forward Deployed Engineering is done at Decagon

Decagon’s deployment model connects agent configuration, customer advice, and reusable product capabilities so each enterprise deployment improves the next.

From a talk by Sunny Rekhi

1:02 ↗

Start with the support interaction

Call a brand for help and the first task may be navigating a phone menu: press one for billing, two for membership. Email about an urgent problem and the response may take two or three business days. Decagon replaces those interactions with an AI customer-service agent that answers calls and replies to emails immediately, with human-like conversation across languages and channels, around the clock.

The initial deployment targets complex support workflows that would otherwise require a human. Once the agent has learned about customers and established a relationship with them, the same deployment can support revenue-generating communication. The transition depends on what the agent already knows and which business systems it can access.

Sunny Rekhi’s example is Hertz. It initially brought Decagon in for complex inbound support. Rekhi describes how the existing backend integrations then enabled another workflow: proactively contacting a customer when it was time to renew or extend a car lease, with the customer able to complete that process within Decagon. Inbound support established the connections; those connections made outbound action possible.

Open full source frame

Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

2:56 ↗

Configure the agent and improve the product

Deployment varies with both enterprise size and industry. A financial institution and a technology brand bring different requirements; a large enterprise and a mid-market customer need different deployment motions. Across those differences, Decagon separates the work into two activities.

  • Configure the agent. Establish how it responds to user requests, what brand tone it uses, which actions it takes, and what success means for the enterprise. Decide which user intents should go to a human. Much of this configuration happens in the UI.
  • Build reusable product capabilities. Treat customer requests as evidence of missing product functionality. If enterprise A needs something today and enterprise B is likely to need it soon, solve the problem in a way that also serves C, D, and E.

The first activity makes the agent work for a particular customer. The second brings what the team learns from that customer back into the shared product.

Open full source frame

At Decagon, forward-deployed engineering is product engineering. Rekhi describes the same engineering bar, the same reporting structure, and often the same team. A Fortune 20 customer’s pain point can become a product feature that needs prioritization. The person discovering the requirement and the person building the product are therefore not necessarily separate roles; that overlap is reflected in the organization.

Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

6:03 ↗

Split the generalist role as the organization grows

Rekhi reports that Decagon grew from roughly 50 to 500 people over a year. Earlier in that growth, agent software engineers handled the entire deployment. They sat beside customers to configure the agent, including both its literal voice and its speaking style. They also integrated backend systems: even a password-reset workflow requires access to the customer’s authentication system so the agent can take action. The same engineers brought customer feature requests into the platform.

At the larger scale, Decagon divided that generalist work into two specialized lanes:

Role Primary work Product feedback
Agent builder Configure agents, largely through the UI Flag needs the UI cannot yet handle
Agent software engineer Build capabilities requested by enterprises Incorporate those capabilities into the product

Agent builders develop intuition for the models powering the platform and how to make them work for an enterprise’s use case. When configuration requires going outside the UI, that boundary becomes a signal for product development. Agent software engineers remain at the front line of enterprise product requests.

Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

7:58 ↗

Exercise restraint when custom code is easy

An important customer wants a feature immediately. With Codex or Claude Code, an engineer can quickly produce a one-off implementation. Rekhi identifies restraint as the scarce skill in that situation: before building, consider how the solution will extend to future customers. Faster code generation makes that architectural decision more consequential.

Customer ownership gives this restraint a concrete purpose. Decagon intends customers to own their agents. A black box of prompts and patches is brittle for both the customer and the vendor, and it undermines that ownership. The engineering task is to satisfy the immediate request through a capability that future customers can also use, rather than accumulate exceptions that only the original implementer understands.

Open full source frame

Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

9:11 ↗

Agree on success before implementation

Requirements gathering starts in the first deal-scoping conversations. The team needs to establish what success means for the customer and, ideally, put that agreement in writing. The questions are specific:

  • Metrics: Which measures must the deployment improve, and what targets matter?
  • Channels: Is the initial scope phone, email, text, WhatsApp, or some combination?
  • Outcome: What pain point is being addressed, and what would the desired result look like?

Once those decisions are aligned, implementation can move quickly.

Large customers can create pressure to start building immediately. But when AI coding reduces the effort required to implement a request, more of the engineering work shifts toward establishing that it is the right request. Agreement about what must be built needs to precede the rush to build it.

Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

10:22 ↗

Let industry knowledge accumulate

Decagon staffs people with experience in a vertical onto subsequent deployments in that vertical. If a core team has worked with financial-services customers A, B, and C, that experience should carry into financial-services customer D.

The benefits begin with speaking the customer’s language, which builds credibility. They extend into a faster ramp-up because prior approaches to agent building and definitions of success carry over. The operational goal is for each deployment to become faster than the last through accumulated knowledge, rather than requiring a fresh discovery process every time.

Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

11:17 ↗

Make engineering work available through self-service

Reusability has a second dimension: who can perform the work? A solution may serve multiple customers while still requiring an engineer for every deployment. Forward-deployed teams must also ask how to enable the rest of the business to solve the same problem.

Decagon’s stated goal is to let customers configure an agent entirely through natural language. When a task still requires an engineer, that dependency identifies something to bring into the product. Engineering encounters the requirement first, then turns it into a capability that other teams and eventually customers can operate.

CRM integrations provide the concrete example. Early on, Decagon repeatedly wrote custom integrations. Rekhi recalls that around the 25th custom integration, the team decided to build a self-service path. Work that had required an engineer writing custom code could then be performed by the customer or the agent-building team. The product improvement changed both the implementation and the set of people able to deliver it.

Open full source frame

Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

12:41 ↗

Sequence the deployment around early value

A Fortune 500 customer may arrive with a request covering the entire support operation. With many channels and complex user intents, a Decagon deployment can become arbitrarily complex. The scope therefore needs to answer a practical question: what can demonstrate value first?

The sequence is to establish useful operation, then expand. Decagon tries to avoid a multi-month wait before the customer sees value. Rekhi describes its customer relationships as multi-year partnerships, leaving room to grow from the initial deployment into broader support flows and revenue-generating workflows. The long-term ambition does not require the first deployment to contain everything.

Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

13:44 ↗

Use support history to choose what to automate

Choosing that first scope is advisory work as well as execution. Customers often arrive with a specific request, but a team that has deployed AI across many enterprises has information the customer may not have. Repeated exposure to similar problems gives forward-deployed teams a basis for questioning the proposed priority.

Decagon ingests the customer’s historical support data and uses it to recommend which workflows to automate first for the highest expected return. That recommendation may differ from what the customer initially requested. The team still has to execute, but its domain knowledge also helps the customer decide where execution will be most valuable.

Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

15:03 ↗

Build a company that learns from every deployment

“Custom becomes self-serve” turns individual deployment work into a recurring product question. Whenever someone performs a manual one-off task, other people in the company may be doing the same thing. Bringing that work back into the product removes a repeated obstacle rather than merely completing another instance of it.

Rekhi credits Decagon’s progress to fast responses to customer requests, a hardworking team, and the trust earned by acting as an advisor. That trust rests on recommendations informed by other deployments and the customer’s own data. Productizing custom work connects those strengths: a fast response can improve the shared system rather than remain an isolated delivery.

As the company grows, informal knowledge transfer is no longer enough. Decagon has become more rigorous about sharing knowledge across deployments and making sure people in the field feed information back to the platform. Improving the agent for customer A should improve what customer B receives.

The responsibility of forward deployment therefore extends beyond making one customer’s agent work. It includes returning improvements to the product and moving capabilities through the organization so more people can use them. A deployment is also an input to the next deployment: the customer gets a configured agent, while the company gains a stronger product and a more repeatable way to deliver it.

Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

Resources

Further reading

  • Katherine Xiao explains how Decagon turns bespoke deployment work into shared capabilities and designs teams for repeatable delivery.
  • Agent Operating ProceduresDocumentationDecagon's overview of natural-language agent workflows, customer control, and technical guardrails.
  • AOP CopilotArticleThe 2025 introduction of Decagon's in-product workflow assistant; the page notes that its functionality is now part of Duet.
  • Decagon integrationsDocumentationOverview of connectors and self-service tools for accessing customer data, executing actions, and escalating conversations.

Transcript & slides

Loading transcript and slides…

Transcript download