The FDE boom is a product gap
Enterprises are hiring engineers to teach agents how the business runs. The lasting fix is letting operators own that knowledge themselves.
Eugen AlpezaSeptember 29, 20266 min read
The industry is hiring its way around a missing product.
Every enterprise trying to put agents to work runs into the same problem: agents don’t know how the company operates, and the operators who do, have no easy way to teach them.
There are two fashionable approaches to this problem. The first is to hire forward deployed engineers. The operator sits with an FDE, who translates how the company works into instructions the agent can follow. That is why FDEs are everywhere. The operator teaches the FDE and the FDE teaches the agent. That has always been a premium service, and keeping an engineer in the middle of every operating change doesn’t scale.
The other approach is to build a context graph, connecting the company’s records and decisions so agents can draw on its accumulated experience. This is more scalable, but if connecting an agent to the company’s history were enough, FDEs would not be in such demand.
The challenge is translating the operator’s judgment into a form agents can follow, and keeping those instructions current as the business changes.
For years, the people doing that translation were us. Yannis and I led forward deployed AI engineering at Palantir.
A large telecom once gave us the data behind tens of billions of dollars in supply chain spend. They wanted automated controls to identify equipment orders that deviated from how the business should operate. Identifying trends was easy. Elucidating the subtle distinctions that mattered was not.
In one equipment family, units of a certain voltage were getting replaced most of the time, but not always. Which equipment orders were outside of policy, and which were productive ways of working that had never been written down? We took the pattern to the people who owned the work. They confirmed the voltage rule and explained why some orders departed from it. Some were mistakes: people had not followed the procedure, often because they did not know it existed. Others reflected legitimate regional requirements that the written procedure had never captured.
The telecom’s order history was a context graph already! It indiscriminately recorded both mistakes and legitimate exceptions. FDEs could find the pattern; only the operators could decide which practices should stop and which should become part of the official procedure.
AI has both dramatically lowered the cost to build and maintain an agent-friendly knowledge base, and increased the return on owning such a knowledge base.
Ask a company whether it has a current account of its procedures detailed enough for a smart new hire to follow. Most people would laugh at the idea.
Keeping one current account up to date used to be brutal. The payoff was better documentation that people still had to read, remember, and apply, one case at a time. Most organizations never got close to a complete, current account.
No single person knows the whole process in a large organization. Agents, however, can read across thousands of cases, surface candidate rules, identify contradictions, and put proposals in front of the people who own the process to parse mistakes from legitimate, undocumented protocols. Agents make the work of assembling and maintaining the knowledge cheaper.
Agents can execute approved procedures at scale. Maintaining those instructions, then, becomes part of maintaining production infrastructure.
Consider how the telecom engagement could have worked with this newfound capability.
This time agents read the order history and identify the voltage pattern. They draft a proposed rule, attach the cases that support it, and flag the ones that do not fit. The supply chain owner confirms the voltage rule, marks the first group of exceptions as non-compliance, and the regional group as legitimate, adds a line explaining why, and approves it.
The resulting written procedure captures the general rule, the regional exceptions, and the circumstances that require human judgment. It is tested against representative cases before being deployed.
The process owner can now change the operating instructions without an FDE translating every revision.
Every escalation can improve the next case
This delivers the most impact in recurring operations (e.g. equipment requests, incidents, claims, customer support, anywhere you have a team of people doing the same work). A case arrives, an agent finds the applicable procedure, and it uses tools to do the work.
Those procedures need to evolve as the business changes and new cases reveal gaps. Operators should be able to review proposed updates from the work being done, introduce policy changes directly, and test their effect before deploying them.
We call the discipline of running this continuously ContextOps: turning operational evidence and expert judgment into tested, approved instructions, and maintaining those instructions as the business changes.
The process owner is accountable for what the instructions say. AI helps assemble and update them, while engineering maintains the systems that execute them.
What is your executable coverage?
Executable coverage is the share of cases in a process that an agent can handle correctly using current, approved procedures, without someone supplying missing operating judgment.
Take a representative sample of a hundred equipment requests. How many meet that standard? That is your starting point.
If you cannot answer it for a process you already want agents to run, you have not established how much of your operating model is explicit enough for an agent to use.
The learning loop is what compounds
The biggest benefit of running ContextOps effectively shows up a few cycles later.
Suppose an equipment request arrives from a region the procedure does not cover. The agent escalates it to an operator, who resolves the case and records the reasoning. As similar cases accumulate, agents propose an update to the procedure, with the supporting evidence and any contradictions. The responsible operator reviews it, decides which judgments should become standing instructions, and approves the change for testing and deployment.
The procedure now covers a set of cases that previously required someone to supply missing judgment. Every agent using that procedure can benefit from what the operator taught it.
The updated procedure expands executable coverage for every agent using it.
Escalation, resolution, updated procedure: that is the learning loop. What once required an FDE to return and translate new operating judgment becomes a continuous process the operators can run.
The enterprise now owns the learning loop instead of renting it.
“Why don’t we just fine-tune our own model?”
But isn’t there an obvious shortcut? Why take all this trouble of creating agents with learning loops when you can just train the model on your company history?
Sadly, this fails for much the same reason the context graph does. You can never be sure that the people in your history were doing the right thing, so you may simply be training your model with bad habits. Plus the business never stands still. Every new supplier, region or policy means gathering fresh examples and retraining the model.
You can ask a supply chain operator to maintain a written procedure. You cannot ask them to fine tune a behavior out of a model.
A development life cycle for context
Organizations should treat the knowledge produced by the learning loop the same way software teams treat code.
Agent instructions need an owner and a version. Proposed changes come with evidence. They are reviewed, tested, deployed, and can be rolled back. You should be able to see which version governed an agent’s decision.
GitHub provides a useful model for that discipline. But the workflow for operators is different.
A proposed rule may have been synthesized from decisions made by many people across hundreds of cases. A text diff shows what changed. To approve it, the operator needs to see the tickets, logs, and judgments behind it: which cases support the rule, which contradict it, and which were one-off exceptions.
Operators should be able to contribute, challenge, and approve the instructions their AI follows. Those instructions must reach the agents doing the work and remain with the company as it changes models, adds agents, and expands into new processes.
Edra is building the Github equivalent for operators: one centralized interface to create, review, test, deploy, and improve the instructions behind every agent. Our mission is to let every company run ContextOps: turn the judgment of its operators into knowledge every agent can use and every expert can improve.
The knowledge of how your company runs is its most valuable IP. It deserves more than scattered tickets, outdated documents, and whatever your best people remember.