business|Jun 30, 2026

Forward deployed engineers: who owns both ends of enterprise AI

Alan Descoins

Chief Executive Officer (CEO)

Alan Descoins

Chief Executive Officer (CEO)

You picked the model. You built it. You deployed it. But old habits die hard, and three months later the team still works the way it always has, the tool sits there unused, and you are the one who has to explain why.

After 16 years building AI, I can tell you this is a common pattern. The model is almost always fine. What should keep you up at night is why a technically correct solution can sit in production and change nothing about how the business runs.

The build is rarely where it goes wrong. The two ends are. Figuring out the right thing to build for your operation. Getting your team to actually use it. That is where AI changes the business or doesn't, and it is exactly the part nobody owns. That gap is the whole reason Forward Deployed Engineers exist. Here is how we run them.

The two ends nobody owns

A few years ago the hard part of enterprise AI was access: scarce talent, months of data work, real conviction just to build anything. That constraint is mostly gone. Starting to build is easier than it has ever been, which is exactly why deploying changes so little. The work that decides whether anything changes moved to the two ends around the build.

The first end is discovery. Not the "gather requirements" kind, but figuring out what to build for your operation. The specific thing your business needs, which you only find by being inside it, watching how the work actually happens and where it breaks. Most of the time nobody can hand you this on day one. It has to be discovered, from the inside.

The second end is adoption. The solution has to become how the team works, not a tool sitting next to how the team works. That means being there when people hit friction, when the workflow does not fit, when the internal champion goes on vacation and momentum stalls. It means staying until the new way is the default.

Here is the part that stings. Your instinct is to cover both ends with your own people, and on paper you should be able to. But the people who know the operation well enough to discover the right thing are rarely the ones who can build it. The ones who can build it are buried in their own roadmap and treat your deployment as one more ticket. And nobody on the inside has the mandate to stay with a single initiative until the org actually changes its behavior. Discovery, build, and adoption end up owned by three different people who answer to three different priorities. That is the gap. It is not that your team is not good enough. It is that the work falls between them.

Hire it out and the gap usually gets wider, not narrower. A consultant runs a discovery and hands you a strategy, then leaves before a line of code is written. A contractor builds exactly what is on the ticket, but will not tell you the ticket is wrong and will not stay to see if anyone uses it. One owns discovery without delivery. The other, delivery without ownership.

None of this is really a technology problem. It is organizational, which is the harder kind. I wrote about that in AI won't fix your business. This post is about the role that exists to close the gap.

How we run them

The early weeks are discovery, but the working kind. The FDE sits with the people who do the work, maps how things actually happen versus how the org chart says they happen, and finds the friction nobody documented. This is where the real thing to build gets defined, and it routinely surfaces problems the client did not know they had. When you work that close to the real systems, you see things a quarterly audit never would.

Then they build, in your environment, against your real constraints and your real data, not a sanitized version of it. They deploy. And then comes the part most engagements skip: they drive adoption. They run the workshops, they debug the workflow when it does not fit how people actually operate, they flag the blocker before it becomes the reason the project quietly dies. They train the internal champions who keep it alive after the engagement ends.

The handover is the test. When an FDE leaves, your team is more capable, not more dependent. You keep the working solution, the documentation, and the people who know how to run and extend it. The metric we hold ourselves to is not whether it shipped. It is whether it is still in use after we are gone.

Why Tryolabs

When you have been in AI services as long as we have, you watch the same thing get renamed every few years. "Forward deployed engineer" is the current name. We have been working this way for 16 years, before the market had a name for it at all. Senior engineers embedded with the client, on the hook for the outcome and not just the build. The label is new. The work is not.

I want to be precise about that, because "we have experience" is what every firm says. Our FDEs are senior engineers first. Discovery and adoption are what set the role apart, but the build is what earns you the right to operate at the ends at all. You cannot discover the right thing to build if you do not know what is buildable, and you cannot drive adoption of something that does not work in production. The engineering in the middle is not the easy part we skip past. It is what makes the two ends credible. An FDE who cannot build at a high level is just a consultant who stayed longer. We did not adopt the forward deployed model because it became a category. We arrived at the category from the other direction, by working this way long enough that the market eventually caught up and gave it a name. When Google selected us for its Gemini Enterprise Transformation practice, it validated a model the team had already been running for years.

The model, under real constraints

One of our FDEs landed on-site with a global pharmaceutical group and had Gemini Enterprise agents built and deployed within 48 hours of arrival. Inside a tightly governed environment, with the compliance constraints a regulated industry brings.

This was a company that had committed to Gemini Enterprise and needed the depth to turn that commitment into working tooling, fast. The FDE embedded with their IT and compliance teams. Production tooling and governance protocols shipped by week three. Along the way, the FDE found and closed a critical security vulnerability that had gone undetected precisely because no previous partner had worked close enough to find it. Full ownership transferred to the client's team ahead of a 20,000-user rollout, and they asked us back for a second engagement.

The point of the example is not the speed, though the speed matters. The point is that every part of that outcome came from being embedded: the discovery that surfaced the vulnerability, the build that fit the governed environment, and the adoption that handed a working system to 20,000 people instead of leaving one more deployed tool nobody used.

The last thing

If you have deployed AI and watched it change nothing, the instinct is to look at the model, the vendor, the next tool. Look at the gap instead. Almost certainly, nobody owned the discovery of what your operation actually needed, or stayed long enough to make the solution stick. That is rarely anyone's fault inside your org. It is just nobody's job.

The question worth sitting with is not which model to buy next. It is who, on your next initiative, is going to own it end to end: the discovery, the build done right, and the adoption. If the honest answer is no one, that is the thing to fix first.

If you want to see how we run that, take a look at how our forward deployed engineers work.