The Interface Before the Agent

AI tools can help people build software, yet customers can still need a specialist to get that software working for their business. I have been thinking about how much of that help is technical implementation, and how much is understanding what the customer needs in the first place.

The forward-deployed engineer sits with the customer and helps implement the solution. The role raises a question for me: how much of that work requires a specialist, and how much reveals discovery that the product could support?

Consider the discovery involved: understanding workflows, translating ambiguous business problems and sitting with a customer until the real need is clear. Alongside the engineering work, there is a conversation the product does not yet know how to have.

For complex deployments, deep integrations and messy legacy systems, a specialist can be the right answer. My question is about simpler workflows where the implementation still depends on someone drawing out requirements by hand.

I have seen this even with relatively simple use cases: someone from the product team still needs to help the customer describe the workflow. That suggests an opportunity to build more of the discovery process into the product.

Many tools for building agentic workflows ask people to arrange components, attach instructions and define how information moves between steps. That structure helps specify the behaviour a business expects, particularly when a conversational agent will interact directly with its customers.

The structure also requires the customer to decide which components to use, what instructions they need and how information should pass between them. Choices that seem obvious to the team building the tool may be unfamiliar to someone using it, so the product needs to help them understand and test those decisions.

A customer can understand their own workflow and still struggle to express it in the tool’s terms. They may omit a condition, connect the wrong steps or pass incomplete context to the model. The product needs to help customers see and test those gaps.

Structure only helps when people can use it correctly.

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

A specialist often helps translate between the customer’s workflow and the system’s requirements. For simpler deployments, I would like to understand how much of that translation the product could support.

The demand for forward-deployed engineers may also reflect a preference for human support when customers are preparing a system that will speak on their behalf. Someone with relevant experience can offer reassurance, help resolve uncertainty and remain available when implementation becomes difficult.

I take that preference seriously because self-service needs to earn confidence, especially when a system will interact with customers. I would investigate where people want help, what makes them hesitant and whether a clearer discovery process changes those needs.

A tempting response is to replace the structured builder with an open field where a customer describes the workflow and supplies context for the model. That can make setup feel easier, but it does not remove the decisions needed to define how the workflow should behave.

Those decisions still need to be made and tested, whether the customer specifies them directly or the product helps draw them out. Otherwise, missing conditions and assumptions may only become visible when the workflow runs.

Watching a specialist work with a customer helped me understand what the product could learn from that conversation. The specialist asks what happens when a call arrives, what needs to be checked before an appointment is confirmed and which follow-up actions should happen afterward, drawing out the workflow until both people understand what completion means.

That discovery process raises a familiar design question about which requirements the product could help customers express, while engineers continue to handle integrations and implementation that require their expertise.

I would like the product to use follow-up questions to clarify a customer’s description, identify missing conditions and establish a goal that can be tested. Simulation could then help the customer examine the resulting workflow before it runs live.

Some of the questions a specialist asks could become part of setup. Customers would still need to review the result, test it and understand what to do when it fails.

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.

The need for specialists may reflect a combination of technical complexity, a preference for human support and opportunities to improve the product. Understanding that combination for a particular workflow would help us decide which parts of discovery and setup the product should take on next.

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.