(See original post in my personal Website)
Over the past two years, we’ve spent an enormous amount of time (and energy!) debating which model to use: GPT here, Claude there ... But I’m increasingly convinced that, where model capability is already sufficient for the task, the model is no longer the main bottleneck. Today, you can get access to extraordinarily capable models practically overnight. What a time to be alive. Yet, the hard part comes afterwards.
Engineering moves closer to the business
As intelligence becomes widely available, engineering value moves more and more into making it useful inside an organization. A capable model gives a company something to work with, but turning that power into reliable (and profitable) operations requires people who understand business, processes, data, architecture, and of course, AI. I explored the first part of this argument in What happens when intelligence becomes a utility?. In this new piece, I want to examine its organizational consequence: if more of the value lies in applying intelligence, engineering responsibility has to extend further into the environment where that intelligence is applied.
There’s a professional role you already heard about that embodies this shift: the Forward Deployed Engineer (FDE). This is a very special role to fill, combining enough business acumen to work closely with a customer’s teams to discover the operational problem with the right technical chops to build an AI solution against their real systems and constraints. I find the approach interesting because it brings implementation and responsibility for its consequences closer together, though its lasting value depends on what the organization can do after that particular engineer leaves. But more on this later.
Forward deployed engineering predates the current generative AI wave though. In a 2020 account of the role, Palantir described engineers embedding with customers, configuring platforms, writing software, and bringing field knowledge back into product development. While AI gives this established approach renewed relevance, the title itself tells us little about whether a team has the conditions to succeed.
A recent example of investment in this approach came on September 8, 2026, when Accenture and Google Cloud announced a new business group with plans to establish a 1,000-person FDE workforce. Accenture’s Forward Deployed AI Engineer role description assigns responsibility for time to value, adoption, reliability, and scalability. Although these are statements of investment and intended responsibility rather than evidence of successful outcomes, the scope of that responsibility is worth examining.
I find it useful to think of this work as three connected feedback loops.
- The agent evaluation loop helps us learn whether AI behaves correctly.
- The operational feedback loop tests whether AI actually improves the work.
- The product learning loop turns what we discover with one customer into reusable AI capabilities we can use with other customers.
Each needs its own evidence of progress. For example, an agent can pass its evals while making a workflow worse, and a successful customer deployment can still be entirely bespoke. Forward deployment is interesting to me because it puts engineers close enough to connect all three.
Owning the outcome inside the organization
Consider a hypothetical distributor whose customers sometimes complain that an invoice charges more than the agreed price. The company wants AI to help its billing team respond faster.
An engineer working alongside the team might discover that writing the reply is the easy part. However, most of the time goes into finding the price the customer was promised and comparing it with the invoice. Until someone does that work, there’s little useful to say.
That discovery changes what the engineer builds. An AI agent could bring the invoice from the ERP and the agreed price from the CRM together, show the difference, and suggest a correction for the team to approve. The person handling the complaint could then review the evidence in one place instead of searching through systems and emails.
Even this modest capability requires engineering decisions grounded in how the business works. The agent needs access to the right customer’s records, and when it cannot find the agreed price, it needs to ask for help. If a correction would reduce what the customer owes, the software must require approval before applying it. Those rules have to work reliably in the systems the team already uses.
To me, this is where proximity is a key differentiator: seeing the team work changes both the problem we choose to solve and the AI-based software we build. The test is whether the team can resolve the complaint with less effort and fewer mistakes. A faster reply alone tells us very little.
Measuring outcomes and acting on the evidence
As I argued in The Discipline Behind Good Agents, agent evaluations, or evals, test agent behavior against explicit criteria, combining executable checks with judgment where the task requires it. That's why evals should be a key practice for FDEs building AI agents. In our hypothetical deployment, the engineer and the operations team could use representative disputes (including incomplete records or requests involving the wrong customer account) to examine how the agent retrieves appropriate evidence and, especially, how it escalates uncertainty.
The agent evaluation loop closes when the team investigates a failure (offline or online), changes the agent or its surrounding system (e.g., skills, system prompt, or the model, and reruns the evals to see whether the change helped without breaking something else. Failures found in production become regression cases for the next released version, so actual usage and experience changes what the team tests before releasing again.
The operational feedback loop asks a different question: does this capability move the needle? And if it does, what needle is it moving? In our example, the question would be whether an AI agent improves how disputes get resolved, measured in reduced costs and higher customer satisfaction. Speed itself could be a vanity metric, since faster processing is useful only if the apparent gain compensates the review effort and the cost of correcting mistakes. Otherwise, we may celebrate time saved in one step while creating more work in the next.
Adoption belongs inside that feedback loop too. If the billing team keeps using its spreadsheet because the new system hides the source documents behind several clicks, the deployment may be technically healthy while making the job harder. Working close to users allows the FDE to see that behavior, understand it, and revise the product before treating low usage as a training problem. Acting on that feedback may require changes to policies or processes, so the FDE needs to work closely with the people who can make those decisions.
This is what I think outcome ownership should mean in practice: staying involved long enough to learn whether the AI capability improves the work for end users, and using that evidence to evolve the capability.
Turning customer knowledge into lasting capability
The product learning loop extends that learning across customers. Each difficult case can teach the FDE something about where the product’s abstractions fail, and Palantir’s role description explicitly describes feeding that knowledge back into product development. To me, the real test comes when we take the resulting improvement into another customer deployment and discover whether it holds up under different conditions. A solution that worked for one customer is a promising starting point for that loop.
In our distributor example, the engineer might discover that the same invoice correction can accidentally be applied twice. Building a check that prevents this gives us an improvement to test with other customers. The protection can become part of the shared product, while each customer keeps its own pricing agreements.
There’s a tradeoff here: putting every customer request into the product makes it harder to maintain, while keeping what we learn in the FDE's head makes the customer dependent on that person. The former produces a product burdened with local exceptions, while the latter produces an apparently capable system that depends on one person remembering how it really works. This connects well with some thoughts I captured in the article Agent-Ready Software vs. Software-ready Agents, where I claimed that operational knowledge can become more durable when its mechanically verifiable parts move into software artifacts. Once the software prevents duplicate corrections, the team no longer has to rely on the FDE remembering to check for them.
What remains after the engineer leaves?
The strengths of forward deployed engineering can turn into a weakness when the context an embedded engineer accumulates (e.g., knowing which data is unreliable or whom to ask about an exception) makes it easier to solve problems personally. Over time, the customer's team may rely on that person’s knowledge to keep the system running, and the organization may then mistake the engineer’s effectiveness for the capability of the system.
To me, the ultimate test begins when someone else has to operate it. Can the distributor’s team use the available evidence to review a correction the agent suggested? Can they recover when the billing system goes down without calling the original FDE? When an approval policy changes, can the responsible team update the rule, run the relevant evaluations, and understand the consequences before releasing it?
These are stronger tests than the existence of documentation or a completed handover meeting because they show whether the receiving team can run and change the AI system on its own. Maintaining the system integration requires someone with the access, time, and competence to do so, just as changing the workflow requires someone with authority and business knowledge to make that decision.
This departure does not require all external support to disappear, since a technology partner may continue maintaining the platform and responding to incidents under an explicit agreement. What matters is whether the dependency is understood and supportable, and whether the organization can make informed decisions without relying on the original engineer’s personal memory. However, the FDE’s departure provides an opportunity to test both continued reliability and the ability to adapt when people, policies, or systems change. A capability that remains stable only because nobody dares to touch it has a limited future.
How I would build an AI business today
If I were starting an AI business as a self-employed engineer in 2026, I would look for a specific business problem where AI could make a difference, and where I could measure that difference. I would work directly with the people experiencing it to build an AI capability into their workflow, taking responsibility for whether it actually improved their work. The FDE title would matter much less to me than the principles behind it: proximity, ownership, and accountability for the outcome.
Starting alone would put discovery, implementation, and the consequences of my decisions very close together, which is exactly what I would need at this point. I would have to understand why someone kept using a spreadsheet after I had supposedly solved their problem with an AI agent, or why an integration that worked yesterday needed my attention again today. That is valuable product knowledge, provided I did something with it beyond solving the next support request.
That leaves an open question: what would I charge for? A recurring fee to run and improve the capability, or a price per successful outcome? I would want a model that rewards better customer results as the product needs less of my time.
I would use each engagement to test which parts of that knowledge travel. Does another customer have the same underlying problem? Can the capability I already built solve it with different configuration, or does it need a different design? The temptation would be to turn the first customer's way of working into the product's architecture. I would want to resist that long enough to learn which constraints are shared and which belong to that particular business.
As the business grew, I would hire people who are deeply curious about AI and love getting into the technical details, making room for different ways of thinking and working. Alongside them, I would want people who can earn a customer’s trust and turn a messy business problem into something we can build. Some people would bring both strengths. I would build the team around that partnership, with everyone sharing responsibility for customer outcomes and bringing what they learn back into the product.
Over time, I could imagine looking up and realizing that we had become a product company. The product would have emerged through the work, with customers teaching us what it needed to do. But that transition would still require deliberate decisions about what to generalize, what to keep customer-specific, and which requests to decline. Keeping the three loops connected would be part of that discipline: evidence from agent evals would inform what we could deploy, operational feedback would tell us whether it helped, and product learning would test how much of that improvement could travel to the next customer. Each engagement should leave the product more capable and the next deployment less dependent on individual intervention. That is the kind of compounding I would want to build a business around.
Top comments (0)