The last three years have felt like a decade.

When I started our Generative AI team, customers were pushing us toward experimentation. In the first year, we delivered close to 500 pilots across APAC. The use cases ranged from simple prompt engineering to RAG-enabled assistants, to actionable agents.

It was an exciting period, but it also exposed a growing gap between serious adopters and “me too” enterprises. We saw three broad approaches: build the platform and expect use cases to follow, embed AI into existing workflows, or drive adoption one use case at a time.

No single approach worked everywhere. What became common, however, was the change in customer conversations. Questions moved from “What can the model do?” to “How will we run this?” Cost, security, governance, manageability, and runtime control started taking more time than the demo itself.

At the beginning of this year, I formed a team focused on production deployment. This month, we scaled it threefold and formalized the mission as AI Forward Deployed Engineering.

These are still early days, and our thinking continues to evolve. But after hundreds of pilots and a growing number of deployments, three qualities consistently stand out: deep tech, business value, and deployment bias.

Contrary to popular belief—and to the model practiced by many consulting organizations—an AI FDE is not simply a software engineer, architect, and consultant bundled together. The AI FDE owns the gap between technical possibility and production value.

Deep tech

In the early pilots, model choice and prompt engineering received most of the attention. As projects moved closer to production, the problems became less glamorous.

An identity integration did not work. The source data was inconsistent. Retrieval quality dropped with real documents. A security rule blocked access. Latency that looked acceptable in a demo frustrated users in a live workflow.

This is where technical depth made a visible difference. The strongest engineers could move across the model, data, application, infrastructure, and security layers until they found the actual issue. They did not know every layer equally well, but they stayed with the problem and brought in specialists without losing ownership.

AI systems also made diagnosis harder. A poor answer could come from the model, prompt, retrieval, source data, tool selection, permissions, or workflow design. We became more disciplined about establishing baselines, building evaluation sets, and inspecting the execution path before changing the solution.

Another challenge has been pace of technology and the product team catching up to customer demands, the FDE would accelerate the product feedback and partially own new function features.

Business value

We never had a shortage of use cases. The harder part was identifying which ones were worth pursuing.

Some technically impressive pilots struggled because the business problem was marginal or poorly defined. In other cases, a relatively simple solution moved quickly because the customer understood the economic value and was willing to work through the deployment friction.

We gradually changed our discovery conversations. Instead of starting with “Where can we use an agent?”, we spent more time understanding the decision or action we wanted to improve, who performed it today, where the cost or delay existed, and what evidence would justify scaling.

An objective such as reducing claims-processing time had to become a specific workflow with users, data, exceptions, controls, and measurable outcomes. Technical metrics also needed business context. Retrieval accuracy mattered because it affected trust. Latency mattered because it changed whether someone would use the system. Inference cost mattered because it could undermine the economics of the use case.

Our biggest learning is that business value cannot be added at the end as an ROI calculation. It influences the scope, architecture, evaluation criteria, and deployment choices from the beginning.

Deployment bias

For me, this is what most clearly separates an FDE from adjacent roles.

In successful engagements, someone kept asking: what is the minimal architecture path to real use?

We did not make progress by avoiding security, governance, architecture, or operational questions. We made progress when those teams became involved early enough to shape the solution.

Our approach evolved toward smaller end-to-end workflows, representative data, early evaluation, and faster exposure to real users. We found that a narrow workflow running under realistic constraints taught us more than a broader demonstration operating in a controlled environment.

Agents reinforced this lesson. An agent may perform well in isolation, but its value depends on permissions, tools, context, exceptions, human escalation, and the consequence of a wrong action. Most of that becomes visible only when the agent enters a real process.

We used to initially think of deployment as the step after build, but we learned from successful deployment that the building block need to be aligned to deployment from early phases itself.

Bringing the three together

Technical depth without business context could produce a strong solution to a weak problem. Business understanding without technical ownership created too many handoffs. Speed without deployment discipline produced pilots that were difficult to operate or scale.

We also expect each deployment to make the next one easier. In our model, reusable assets, evaluation sets, and recurring field issues flow back into engineering and product teams. The field is not only where the product is used; it is also where we learn how to improve it.

Our own model is still developing, but the foundation am working on

Deep tech. Business value. Deployment bias.