AI Engineer World's Fair 2026
How Forward Deployed Engineering is done at Decagon
Read the talk
How Decagon Turns Forward Deployment into Product Engineering
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
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
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.
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.
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.
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
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.
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.
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
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.
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.
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 ProceduresDocumentation
Decagon's overview of natural-language agent workflows, customer control, and technical guardrails.
- AOP CopilotArticle
The 2025 introduction of Decagon's in-product workflow assistant; the page notes that its functionality is now part of Duet.
- Decagon integrationsDocumentation
Overview of connectors and self-service tools for accessing customer data, executing actions, and escalating conversations.
Read the complete timestamped transcript
- 0:00
[upbeat music] [clapping] How it guys?
- 0:16
Can you hear me just fine? All good? Okay, awesome. Just so I can contextualize this talk a little bit, can I get a show of hands of who here is an engineer or is a forward-- in, in a forward deployed motion at all?
- 0:28
Okay. Okay, so I'm a minority. Okay, awesome. Uh, sounds good. So yes, um, I'm Sunny. I'm the, uh, CTO of Forward Deployed Engineering here at Decagon. And today I'll talk about what it is that we do, why we have a forward deployed motion, how it has changed over time as we've gone from fifty people to five hundred
- 0:46
people over the course of a year, um, how it changes if you're working with a Fortune twenty versus a more mid-market brand. Uh, thank, thank you all for coming.
- 0:55
I hope it's useful. And, um, yeah, let's get started. So...
- 1:02
Great. Uh, okay, so just to give context on what Decagon is. Um, for those of you unfamiliar, Decagon is a twenty-four/seven AI customer service agent. So we've all had the experience of calling into your favorite brand and being told to press one for billing, press two for membership options, et cetera.
- 1:21
Or you email into your brand because you need urgent support, and you hear back in two or three business days. Decagon replaces all of that. So instead, you pick up and you call your brand of choice, and you get a human-like agent who is helping you.
- 1:34
You email in, you get a human-like reply right away. So that's what Decagon does in a nutshell. Um, multilingual, omni-channel, et cetera.
- 1:47
Um, and then importantly, and again, I, you know, I, I, I say this to, to help contextualize what our forward deployed motion does. But, you know, we land in our customers to help them with the kinds of complex support workflows that today have to go to humans.
- 2:05
Um, but once we are there and our agent is learning about the customers and has a relationship with the customers, then we also work with our customers to figure out, hey, how can we actually make you more money?
- 2:15
So one example, you'll see this in the bottom of the slide here, but Hertz, you know, we're all familiar with. Hertz came to us because they had these kind of complex inbound support workflows that had needed to be offloaded to an agent.
- 2:26
But once we were there, uh, it turns out, hey, we already have, like, these integrations to your back-end systems. What other communications are you doing with customers? And one that Decagon now does for them is to reach out proactively to a customer when it's time to renew their car lease or extend it or whatever, and they can
- 2:42
do that from within Decagon. So it is you land-- We typically would land and help them deflect these sort of inbound support cases, and then we expand into, you know, how do we make you more money?
- 2:56
Um, now we work cross-vertical. We also have really large enterprises, more mid-market brands. These are a subset of what I was approved to talk about. Uh, there were way more I wanted to add in there, but our, our marketing head got mad at me.
- 3:11
We have, you know, the, the top left, we have our financial institutions. The bottom right, we have our, you know, your favorite tech brand. Uh, and this is relevant because, as I'll talk about briefly, uh, the kind of forward deployment you have to do is vastly different based on both the size of the enterprise and also the
- 3:30
vertical. Okay. So I imagine this is the case for a lot of agentic companies, but Decagon has effectively two kinds of forward deployed engineering. Number one is taking that AI customer service agentic brain and making it work for your enterprise.
- 3:50
So the same way that you train a human, you give it instructions on what to do when a user asks X, how you respond back to it, what sort of brand tonality you have, what actions do you take on behalf of the user.
- 4:04
All of this, like, configuring of that human-- of that, of that agent brain is one form of our forward deployment motion, where we work with the customer, we figure out what does success look like for you?
- 4:14
How do you want the agent to speak? What sort of user intents do you actually want the agent to hand off to a human instead? That's the left half of this diagram.
- 4:22
And we have a team, which I'll talk about briefly, who is, like, really good at configuring the agent. Largely, this can also happen within the UI.
- 4:30
And then on the right side is, um, the, the previous speaker alluded to this as well. F-forward deployment-- forward deployed engineers are the front line for customer product asks.
- 4:43
And it is their job to figure out, hey, enterprise A made this ask. I know in two weeks, enterprise B is also going to have the same ask, and this happens with stunning regularity.
- 4:55
So I wanna make sure when I solve enterprise A's problem, I'm solving it for B, C, D, and E before they've even had a chance to express it. So those are the two kinds of forward deployed engineering that we have internally.
- 5:05
Configuring the agent and then making sure all the problems that you interact with the enterprise that, that come up in that-- in, in, in the context of that conversation also get brought back into the product.
- 5:16
Which brings me to a really important point. In fact, it's so important, I wish I had a slide for it. But, uh, at Decagon, forward deployment engineering is identical to product engineering.
- 5:27
Uh, it's the same bar. It's the same reporting structure. Uh, often, like, the same team. Because the, the, the, the delineation between what is historically forward deployment versus product engineering is super, super blurred now.
- 5:42
Uh, when I'm speaking with a Fortune twenty and they express a pain point, that is often a product feature that needs to get built and prioritized. And so that line between I'm a forward deployed person and I'm a person who works in the product, um, is gone.
- 5:57
Uh, it's the same, it's the same person and, and that's represented in our, in our, in our org chart.
- 6:03
So, um, early on, I mean, Decagon is, is an example of sort of canonical hypergrowth. A year ago, we were at fifty people, now we're at five hundred and, uh, the scale is not slowing down.
- 6:19
So actually, shameless plug, if you are interested in, uh, a new role, [REDACTED:email_address] is my email. Please let me know. I'll make sure your, your resume/profile gets in front of the right people.
- 6:31
Anyway, back to the, back to the talk. Um, so historically, we had agent software engineers, and they did it all. They did that configuring of that agent brain sitting side by side with our customer.
- 6:42
Uh, this is again, things like what is the tonality of the agent? What sort of voice do you want it to have? Both literally the voice, but also the, the way it speaks.
- 6:52
Um, how do I integrate it into your backend systems that it could take action on behalf of the users? This can be something simple, like I wanna reset my password, so the agent needs to have backend access into your, you know, authentication system, and it can be something sort of far more complex than that.
- 7:08
And they also did some of that, like, platform work, like customer A has this feature request, and then building that back into the product. Now that we're five hundred people, uh, we start thinking a lot more about how do we design the Decagon system so that it can scale.
- 7:24
And effectively, we, we, we broke apart this agent software engineering role into two specialized lanes. One is the agent builder, and these are, like, Decagon pros. They have a lot of intuition for the various models that power our platform.
- 7:37
How do you make them work for the use case that the enterprise requires? Um, largely living within the UI to the extent possible, flagging when things need to go off UI, and how do we bring that into the product.
- 7:48
And then secondly, we have agent software engineers, and again, these are the frontline enterprise makes product request, making sure that gets incorporated back into the product.
- 7:58
And, um, this is, I think, like a, a super, super, uh, important insight, uh, which is there is routinely this temptation of, okay, customer A made this request, and they're so important to us, and they want it done ASAP, and maybe I'll just go prompt Codex and Claude Code to just do it for me.
- 8:16
But the scarce skill, now that AI coding is so good, the scarce skill is actually exercising restraint, uh, and saying, you know, really thinking about how is this going to scale to sort of future customers.
- 8:29
And part of this is our ethos. Like, we, we build agents to be owned by the customer. And so if it turns into a black box of, like, prompts and patches, then that's not good for us or them.
- 8:39
It's far too brittle. Um, but also, uh, when you're a forward deployed person, this is, this is kind of, um, this is incumbent upon you to, to be exercising this restraint of, like, let me not do the easy one-off thing, but rather make sure whatever I am building is architected in a way that future customers benefit from.
- 8:58
So this will come up in, in the remainder of my ten minutes here, which is, uh, always thinking about, how do I make this one ask benefit the remainder of the customers?
- 9:11
Um, so I, I, I put this slide here not to sort of toot our own horn, but to actually talk about what it looks like to achieve success. Uh, and in, i-in our case, we've learned, like, early on when you're scoping the deal, like literally with the very first conversations, you want to figure out ahead of time
- 9:31
what does success look like for the customer? And really narrowing that down, ideally getting it in writing so that there is, like, no miscommunication along the way. Like, and when I say what does success look like, I mean, what are the metrics you're trying to hit?
- 9:42
What sort of channel that you want support on. Maybe that's a phone call, maybe that's email, maybe that's text, maybe it's WhatsApp, whatever. But really narrowing, like, what is your pain point?
- 9:52
What is the ideal outcome you want? And then we can race to go build that out. Um, but I think, again, back to sort of lessons for forward deployed folks, uh, there, especially when you're dealing with a large company, there's this temptation to just get started.
- 10:06
And, uh, and this is partly a reflection of how AI coding has changed engineering generally. But now there's a lot of effort that has to go upfront in requirements gathering, making sure you're aligned on what actually has to get built, uh, before, before going to do it.
- 10:22
Uh, this has been a really good learning for us. So, uh, we try now, given that we have, like, a t- a ton of customers across various verticals, we have found it's really helpful to have industry experts that get staffed to the same kind of deal.
- 10:36
So if I am working on financial service A, B, and C, when financial service D company comes around, ideally, I have a core f- core group of folks who have experience with those customers, uh, working with this new logo.
- 10:51
And the idea here is, like, a lot of that knowledge compounds. Like, A, you can, like, speak in the lingo of this customer, and therefore there's a lot more credibility there.
- 10:59
There's a lot more-- There's a lot, like, a much faster ramp-up and, uh, a lot of the agent building, sort of the way you think about success carries over.
- 11:07
So, uh, this has been very helpful for us and, and ultimately, it's all about, you know, uh, making every deployment, uh, faster than the last one.
- 11:17
Um, I mentioned earlier that as a forward deployed... And, and by the way, I say forward deployed engineering, but really it's just, like, all forms of forward deployment. I mentioned earlier that one of the big things you have to do is to always think about, how do I solve this customer problem in a way that extends to
- 11:34
other customers? The other thing that I think is always helpful to keep top of mind is, how do I make it so that I am empowering the rest of the business to solve this problem?
- 11:44
And this is specifically if you're in engineering. So for example, uh, Decagon's ethos is you should be able to configure this agent completely via natural language. And so if you ever have an engineer needing to do something, that needs to get upstreamed back into the product.
- 12:00
Uh, and so this is sort of a funnel that we have of, like, look, dec-- f-forward deployed engineering, they're the front line for customer asks. Um- But really, it should get, it should get sort of scaled across the business.
- 12:11
And one example of this, and I mention it later as well, is, like, let's take an integration. Let's say Decagon needs to integrate into, like, some, some CRM. Uh, early on in our history, we were actually just, like, building custom integrations time and time again.
- 12:22
And then we thought enough is enough after like the twenty-fifth one, we're like, "We don't know how many more are coming up, uh, so let's just, like, build it a self-serve way."
- 12:30
And now what took an engineer custom code writing can now be self-served by the customer or built by our agent-building team. So it's all about how do you scale the work that you're doing.
- 12:41
Um, also very relevant, depending on the kind of forward deployment work you do, is, especially in the enterprise, wanting to prove value as fast as possible. For those of you who work, especially in the Fortune five hundred, you're going to get hit with the entire, uh, what's the expression, kitchen sink or the entire kitchen, something like this.
- 12:58
Uh, but the, the idea is how do you prove value as fast as possible? So in our case, Decagon can become arbitrarily complex. You can support all sorts of channels, all sorts of very complex user intents.
- 13:11
We try to figure out, how do we demonstrate value ASAP and not have, like, a multi-month deal or, sorry, multi-month, uh, time to prove value? And once we're there and we're, we're adding value, then we expand, right?
- 13:25
Because ultimately, all of our customers are a multi-year partnership. And so we want to make sure we're, we're helping you across your entire support flow and, and your revenue-generating workflows.
- 13:34
But it's important as a forward deployed person to figure out, how do I prove value right away, and build your, build your motion around that.
- 13:44
Um, so customers will often come to, come to folks and say, uh, "I want you to do X, Y, Z." And, and often they're right, but I think as a forward deployed engineer or forward deployed person of any sort, you're-- you should treat yourself as an advisor rather than just an executor, right?
- 14:06
You're, you're both. So, um, you're also on the front line of, "Hey, how do I make AI work for the enterprises?" And you have so much knowledge because you're seeing it repeated across every single customer.
- 14:18
And so what we do at Decagon is we actually ingest your historical support data, uh, and we tell customers that, "Hey, like, if you automate this first or this first, this is where actually you'll see the highest ROI."
- 14:32
Um, and sometimes that's not actually what the customer had reached out about. Uh, and I imagine there's analogs to this across all sorts of verticals. But it's important to keep in mind that your job isn't just an executor.
- 14:43
It is of course, to be an executor, but it is also to be an advisor, uh, and to not underrate the fact that you have this domain expertise by being forward deployed across many companies, so that you have this knowledge base that's really valuable for the customer to tap into.
- 15:03
Every time at Decagon, someone has to do something manually, we try to make sure it gets upstreamed back into the product. So I mentioned the integration earlier, but this is, I think, a good mental model for folks to have if you're on the front lines.
- 15:17
How do we smoothen out that path? Custom becomes self-serve. Custom becomes self-serve. Um, this has become like a guiding ethos for us, uh, and I suspect it is the case across every kind of forward deployed motion.
- 15:30
So I'd encourage everyone in this audience to, to, um, to, to keep this top of mind. It's like, "Okay, I'm doing this, I'm doing this one-off thing." Presumably other people in the company also are.
- 15:39
Bring it back into the product. Okay. So, um, Decagon is really interesting [REDACTED:age] that it was started by... I think now they're [REDACTED:age], but it was, I think, at the time they were [REDACTED:age] [REDACTED:age] [REDACTED:age] [REDACTED:age]
- 15:53
Oh, sorry, [REDACTED:age]. Um, and so what did, what did we do right, uh, to, to sort of deserve the place that we have? And I think, one is we're known in the industry to move really, really fast on customer asks.
- 16:06
And part of this is just like it's a very hardworking group of folks. Um, so that's, like, a big reason that we got here, uh, is that we've just moved really fast deal by deal.
- 16:17
I think number two, we've earned trust with customers that we are advisors, not just executors. So we'll, we'll, we'll, we'll, we'll be able to tell you based on what we're seeing across other customers, based on the data you give us, um, what is going to be the highest ROI for you.
- 16:32
And then number three, we've been really good at, um, making sure we productize custom work. But the way we think about this has changed a lot in the last year because, again, a, a year ago, we were fifty people.
- 16:43
Could all fit on, you know, a, a lengthy lunch table, and now we're five hundred. So now we think a lot about designing the system. So every time-- Now, now we're very rigorous about sharing knowledge across deployments, but, uh, making sure you extend, uh, the field, the people in the field, feed information back to the platform, making
- 17:04
sure the agent compounds every single time it interfaces with the customer. So if the agent interfaces with customer A, you improve that for customer B. And it's all about sort of taking knowledge from the field and bringing it back into the product.
- 17:18
Uh, and so just to wrap up here, um, sort of a, a few of the, few of the themes. Number one, obviously, you have to make sure you can figure that agent, do whatever the customer wants.
- 17:29
But number two, uh, make sure that it gets fed back into the product. And three, mind that funnel that I mentioned earlier. You're on the forward, you're on, you're on the field, but you want to make sure it scales and make sure it improves, uh, every, every, uh, future customer interaction.
- 17:44
Uh, again, my, my email is [REDACTED:email_address]. I'll also be out here if folks have questions. Thank you for coming to the talk, and I hope this was helpful. [outro music]