Lessons from building an AI Forward Deployed Engineer

We built AI FDE, an internal Slack agent that triages customer requests. It has access to all our code and databases, and builds its own memory to improve its understanding of how our systems work. Here’s how it looks in practice:

The Problem We Faced

Forward Deployed Engineering is extremely in vogue. The advantages are obvious: code has never been easier to write, but to maximize its value to large enterprises, you have to solve unique problems for each customer. Digesting huge amounts of data, learning a company’s unwritten conventions, and dropping everything to fix bugs in minutes are just a few of the ways FDEs eat pain and excrete product that are hard to efficiently replicate across customers.

This is a great way to make users happy, but providing 24/7 white glove service has its disadvantages. In particular, frequent context switching makes it hard for FDEs to ship core product features. This is harmful because it eats away at a core strength of the FDE: being the #1 expert at the company on what we ought to ship, and having the skills to ship it yourself.

We felt these problems deeply at Actively. Rapid customer acquisition left FDEs juggling 4-5 enterprise customers and 2-3 product features at a time. AI tools make this job easier, but they don’t get it done - FDEs still have to write long prompts explaining the ins and outs of huge organizations, and once they solve a (potentially very complex) issue, they have to distill it into a simple message that keeps the customer well-informed and happy.

The Solution

With these problems in mind, we wanted to build something that allows FDEs to triage customer requests without writing long prompts or heavily taxing their mental RAM.

Our first attempt was a set of bug-bashing skills that FDEs could plug into coding agents. The idea was that if everything you needed to know about the job was pre-loaded into these prompts, FDEs could do their jobs with the click of a button.

We had these skills write to a database whenever they were used, so we were able to watch in real time as they got little to no adoption. It turns out that everyone has their own habits in Claude Code and Codex, and it’s hard to convince everyone to try a set of skills they aren’t familiar with.

Slack As A Lever For Adoption

In an attempt to test the adoption of different surfaces, we plugged these skills into a managed agent harness, gave it access to the necessary tools, and plugged AI FDE into Slack. This was the key - usage skyrocketed (4 threads → 158 threads the weeks before and after we launched Slack) and has been climbing ever since. This is partially because Slack makes things visible. Teammates could see each other solving issues with AI FDE, and more and more gave it a try themselves. 

Even moreso, adoption increased because providing clear explanations in Slack solves half the problem of managing customer requests. When an APM asks an engineer “Can you look into this?”, what they’re really asking is, “can you look into this and provide an update in Slack so I can communicate it to the customer?” By posting its results in Slack, AI FDE solves this half of the equation. Soon after it was released, engineers began replying to “Can you look into this” with “@AI FDE please look into this”, leaving no further work on their part. Not much later, APMs took the engineers out of the equation entirely.

We also saw adoption expand to different roles. Instead of just reacting to customer requests, AMs and AEs use AI FDE to understand customer data and make plans.

Memory 

A useful component of AI FDE (and all Claude Managed Agents) is its memory. One of the hardest parts of an FDE’s job is keeping track of context for every customer you work with. We equipped AI FDE with a memory store for each customer (avoiding cross-contamination of data) to remember what you tell it about customers and avoid making the same mistake twice.

This is especially useful since the memory is shared across all users. When FDEs use their own coding agents, each individual has to fully explain what’s happening with the customer, and they might convey different information, leading to discrepancies and problems down the line. A shared memory store allows every user to benefit from each other’s work with AI FDE, and make use of the complete set of facts that no individual could have kept track of themselves.

The Self Improvement Loop

There is a nice property of working on an agent with access to your codebase and all of your databases — it has access to your codebase and all of your databases. Whenever AI FDE gets something wrong (which happened a lot in the early days!) you can simply start another session and ask “@AI FDE your last session was wrong in X way (perhaps missing data). Please look through the trace and propose a code change to yourself to correctly access that data and avoid this error in the future”.  Debugging has never felt easier.

How to Build This Yourself

AI FDE Runs on Claude managed agents (see our CEO talking about them here). They are remarkably easy to set up, and I can’t explain them better than the quickstart guide’s recommendation to run /claude-api managed-agents-onboard inside Claude Code. I am especially a fan of how easy it is to set up the memory and how well they adhere to their system prompt. It is quite fun to chat with (we kept it on Opus 4.6 for far longer than we should have simply because of its writing style), but it does a great job understanding its goals and staying on task. 

To conclude, I asked AI FDE what it wanted to tell the world. Here’s what it said:

Thanks to Anshul Gupta, Shivam Patel, and Michael Rivo for reading drafts of this post. Thanks to AI FDE for writing the last section.