The Interface Before the Agent

I have been thinking about something for a while now, and I cannot get it to sit quietly. AI was supposed to make software the most helpful it has ever been. Models write code, understand plain language, adapt to what you mean instead of what you typed. Building and deploying software has genuinely never been easier. If all of that is true, is it not counterintuitive that we need more and more humans to help people use these products?

Because that is what is happening. The forward-deployed engineer, a person who sits with the customer and implements the solution for them, has become one of the fastest-growing roles in AI. Palantir invented the model, and now the biggest AI labs are expanding entire teams around it. The companies selling self-serve intelligence are hiring, at record speed, humans to serve it by hand.

Look at what those humans are hired to do. Read the job descriptions and the role is majority customer-facing. The requirements lean on discovery: understanding workflows, translating ambiguous business problems, sitting with a customer until the real need is clear. We are hiring engineers, at engineering salaries, and what we are really screening for is the conversation.

There is a reason for the urgency. MIT research found that about 95 percent of enterprise generative AI pilots deliver no measurable business impact. The models work; the deployments stall. The FDE is the industry’s answer, and for complex deployments, deep integrations, messy legacy systems, it is a good one. That work will exist for a long time.

I have watched what happens even with simple use cases, though, and someone from the product side still ends up in the room. I have lived a version of this. It has made me wonder whether we are treating the FDE as the solution when, for everything below the truly complex line, it might be a band-aid. A very good band-aid, applied by very capable people, over a problem we have not properly named.

So let me try to name it.

The Problem We Haven’t Named

Most tools for building agentic workflows are built around structure. Components arranged into a flow, instructions attached to each one, variables captured at one step and used at another. The structure exists for a good reason. It is how you fight hallucinations. It is how you make an autonomous system predictable enough for a business to trust it, and nowhere is that trust more exposed than in conversational agents, where the system talks to real customers in real time with no undo.

Structure has a cost, though, and the cost is decisions. Which component goes at which step. What instruction each one carries. Where a variable gets extracted and how it gets passed along. Every one of those decisions is obvious to the team that built the tool and opaque to the person using it. The knowledge is well known, but still not known. It lives inside the building team and nowhere else.

So the customer, who understands their own workflow perfectly, gets lost in translation. The flow gets built wrong. A wrongly built flow is exactly the thing that hallucinates. The structure that existed to prevent hallucinations ends up producing them, because using it correctly costs too much.

That took me longer to see than I would like to admit.

The Counter-Argument I Take Seriously

Once you see it, the hiring wave reads differently. The gap those thousands of FDEs are filling is not a gap in intelligence on either side of the table. The customer knows their workflow. The system knows what it needs to hear. Neither can do the translation alone. So we put a human in the middle, one deployment at a time, and called it a go-to-market strategy.

I want to be fair to the other side of this, because there is one. Maybe the demand for FDEs is not only about product gaps. Maybe people simply want a human. When you are handing over a system that will speak to your customers, there is real comfort in having someone accountable across the table, someone who has done this before, someone to call when it breaks. Perhaps self-serve is something people only want up to a point.

I take that seriously. Then I remember we have heard it before. Nobody wanted to move money without a bank teller, until they trusted the flow that let them. Nobody wanted to book travel without an agent, until the product earned it. What reads as “humans do not want self-serve” is usually “self-serve has not yet earned their confidence.” The preference is not fixed. It follows trust. Trust is not a hiring plan. It is a design outcome.

Removing the Structure Doesn’t Fix It

There is also a tempting way out of the structure problem, and everyone building in this space has felt its pull. If structure creates the friction, remove the structure. One open field. Describe what you want, dump in your context, trust the model to take the load. I understand the instinct, because these models genuinely make structure feel optional.

It is not. What is optional is who carries the weight of it. The open field does not remove the decisions the workflow requires. It just stops asking them out loud, and the gaps surface later, in production, as behavior nobody chose. It is the difference between solving it now and solving it properly.

What the Human Actually Does

What changed my thinking was watching what the human in the middle actually does in that room. They do not hand the customer a blank page. They ask. What happens when the call comes in. Who is the appointment with. What gets checked before a slot is confirmed. What happens after, a confirmation, a reminder, a follow-up on another channel. They pull the workflow out of the customer’s head one question at a time, until the loop closes and both sides know what done means.

That is not engineering. That is discovery. It is the interview designers have been running in research rooms for decades. The job descriptions admit as much. When discovery skills are what FDE roles are hired for, the industry is already conceding that the hardest part of deployment is a research conversation. It is just choosing to solve it with headcount instead of with the product.

Moving the Interview Inside the Product

The products that get this right will encode that interview. When someone describes the agent they want, the system will not pretend the description is enough. It will ask follow-up questions. It will probe for the cases the person did not think to mention. It will ask for a goal, because an agent that does not know its goal cannot be tested against anything. Then it will prove the result through simulation before anything runs live, because trust in this category cannot be asked for. It has to be demonstrated.

The expertise does not disappear. It relocates. The conversation a human runs across a table moves inside the product. Design addresses both halves of the demand: the discovery interview closes the capability gap, while transparency, simulation, and honest handling of what goes wrong close the confidence gap.

I have believed for a long time that winning products are built with customers, not for them. This is that belief meeting the agentic era. The product cannot be built with the customer unless the product itself knows how to have the conversation.

So, is the FDE wave a permanent gap, a preference for humans that will not budge, or untapped potential? Honestly, I think all three exist, split somewhere along the line between complex and simple. That line is not fixed, though. Every piece of the translation we move into the product shifts it. Every bit of confidence the product earns shifts it further. I would rather be one of the people moving the line than one of the people assuming it cannot move.

If you are building in this space, or sitting in those rooms yourself, I would love to hear where you think the line sits. I suspect the people closest to this are all forming answers in parallel, and I would like to compare notes.