What Is A Forward Deployed Engineer?

Forward deployed engineering is having a moment. Every AI company suddenly wants FDEs, and the reason is simple. With agents, context is the whole job. You can't build a good agent for a workflow you've never watched happen. So the FDE sits inside the client's company and works next to their team. Not on a discovery call, not over a recorded demo. In the building, watching the actual work, so they understand the problems people run into on a normal Tuesday.

What the job actually is

In revenue cycle management, that embedding is what makes the difference. You sit inside a practice or a billing operation and map the workflows that actually move money. The repetitive ones. The ones where a claim sits in a queue for eleven days because nobody owns it. The work itself comes down to three things: running the assessment, building evals so you know the agent is doing the job, and handling deployment. None of these are one and done. Every design decision you make early has consequences that show up months later, so you make them carefully.

Moving Past automation, toward a system that improves

The real function of an FDE is understanding which outcomes actually drive the business. We want to get past building one-off automations and start building an operating system that gets better over time. This creates a self-improving revenue recovery system and not just one off automations.

That said, plenty of jobs don't need an operating system. A lot of work is a handful of tool calls, and an automation is the right answer. Part of the job is knowing the difference and not over-building something that wanted to stay simple.

The Revenue Integrity Framework

At ClearCycle we run our FDE interviews through what we call the Revenue Integrity Framework. It keeps the questions pointed at money instead of feature wishlists. A few of the ones we always ask:

Understand the actual work. Walk me through what happens from the moment a denial arrives to the moment it's resolved or written off. Who touches it? In what order? Where does it wait? This is where evals earn their keep. Watching the real path is how you find the gaps where an agent would miss what a human is actually looking at.

Find the revenue leaks. What percentage of denials never get worked? Be honest. Not the target, the reality.

Understand the data. If I ask for a single patient's full status, claims, authorizations, balance, last interaction, how many systems do I have to open to answer?

Separate judgment from rules. For each step in the workflow, does it need judgment, or is it following a rule? If a new hire had a written checklist, could they do it?

Treat the agent like a new hire

Treat every agentic system like you're onboarding a junior member of the team. You wouldn't hand a new analyst the keys on day one with no checklist and nobody reviewing the work. An agent is no different. It earns trust by doing the small jobs well first.

This is also where the 10-20-70 rule from BCG holds up. Ten percent of the value is the algorithm, twenty percent is the tech and data, and seventy percent is people and process. At the end of the day, its about change management to get the system going and implemented. This is where On an agentic project that ratio holds. You can ship a technically perfect agent and watch it die because the team kept working the old way. Most of the success isn't the model or the code. It's the people adoption piece.

Evals, and why we built the CYCLE framework

Without good evals you're guessing at what success looks like. Evals are also how an FDE builds something that generalizes instead of turning into one more consultant who leaves and takes the knowledge with them. The difference between an FDE and a consultant is a system. At ClearCycle, that system is the CYCLE framework, which is how we capture value across every client we work with.

Why technical PMs are built for this

I think technical product managers are the best fit for this role. They already spend their days understanding customer problems and turning needs into solutions. And a big part of FDE work is exactly that last step: taking something technical and explaining it to a practice owner who doesn't care about the architecture, only about whether the money shows up…

(This is Part I of our series of Forward Deployed Engineering in revenue cycle management)