I had a long conversation this week with a founder building governance software for agentic systems. The product does what that category has converged on: scoping what an agent is permitted to touch, keeping a trace of what it did and on what basis, raising an alert when a run goes somewhere it shouldn't. It is a sound product thesis and the problems it addresses are real. On the technical side I had nothing to argue with.
What he could not tell me, when I asked, was who inside a customer would be holding it. Not which title signs the contract, which he had a clear answer for, but who sits with the thing on a slow Tuesday afternoon when it flags that a procurement agent has started approving a class of invoice it wasn't approving last month. That question turned out not to have been asked, and I don't think that is particular to him. Most of the governance and observability products I've looked at this year are specified in detail against the agents and not at all against the organisation they land in.
Every one of these products assumes an implicit org chart, and ships it without saying so. Observability assumes somebody is watching, and that the person watching can stop a run without opening a ticket. Explainability assumes a named party accountable for the explanation and a second party being explained to. Scoping assumes somebody with the standing to decide that a department's agent may read the contract repository but not write to it, which is a business judgement that arrives at the buyer as a technical setting. All three produce findings, and a finding is worth exactly what the person receiving it can do with it.
That part has a track record. Enterprises have been buying tools that produce findings for twenty years. The ones that worked had a named owner occupying a role with enough context to read the output and enough authority to act on it. The ones that didn't produced a dashboard, a queue that grew, and eventually an informal agreement to review it quarterly. A good deal of DLP alerting went that way, and so did large parts of GRC, and in almost every case the software was not what failed.
There is a commercial consequence here that probably matters more to the founder than the product one. If the role that would use the tool doesn't exist, the budget comes from wherever budget does exist, and in most enterprises that means Risk or the CISO. That is a sale without a renewal, I can guarantee you. It also decides what the product becomes. A governance tool bought by Risk gets used to say no, because saying no is what Risk is measured on, and within a year the teams building agents treat it as the thing standing between them and production. The same tool bought by the function that owns the agents and answers for their output gets used to ship instead, because the person holding it needs the agents to work.
The other half of this is the customer's problem, and it is the more interesting one, based on what I am seeing inside enterprises partly because most large enterprises already have half the answer sitting in a role nobody thinks of as strategic. The IT business partner is usually a director or senior manager, sitting inside a business function rather than in IT, part of that function's management team. The job is to see demand coming before it arrives as a request, hold the portfolio of what is running and what is queued, and explain to a head of finance or supply chain what their technology costs and why. It is an unglamorous role and a good one, and the companies that staff it properly have noticeably fewer arguments.
The role was built for work that ends. A project has a go-live, a benefits case and a point where it stops being a project and becomes something operations runs. The portfolio is a portfolio of those, and the cost conversation is mostly about what to start and in what order. A portfolio of agents has no such shape. Nothing goes live and then stops needing attention, because the thing that decays is not the code. I wrote in the last post that maintaining code has become cheap while maintaining context has become the expensive part: the encoded exceptions, the process logic, the evaluation sets, the recorded reason a particular step exists at all. That work does not finish, because the business does not stop. So what the business partner holds is no longer a list of projects with end dates. It is a book of running positions, each carrying an ongoing cost of ownership that very few companies currently budget for and fewer still measure.
The second role is the one that does not exist yet, and it is the one the founder's product needs in order to be usable. An embedded AI engineer, sitting inside a department, close enough to the work to see which parts of it are worth automating, building those, and then owning what was built: the maintenance, the evolution, and the afternoon when a policy change means four workflows are now encoding something that is no longer true.
That description is close enough to the forward deployed engineer that the difference needs to be made explicit. A vendor's forward deployed engineer learns your context once, during implementation, at your expense, and then takes it to the next account. An employee accumulates it. They are in the room when the priority shifts rather than reading about it in a change request six weeks later. They will still be there when the thing they built breaks, which changes what they build in the first place. And they hear the exception that never got documented, because they sit near the person who handles it.
I argued in the fifth post that the forward deployed engineer is the wrong answer, and that what enterprises need is somebody with the domain standing to say that a step should not exist. Moving the engineer onto the payroll does not fix that by itself. A capable engineer three years into their career still cannot tell a CFO that a control introduced after an audit finding is decorative, and should not be the one attempting it.
Which is why these are one answer rather than two roles that happen to be adjacent. The business partner brings the standing, the management-team seat and the portfolio view. The engineer brings the hands and, after two or three years, a better working knowledge of how the department actually operates than anyone hired to study it from outside. Between them they cover the two things a finding requires: somebody who can read it and somebody who can act on it. Separately, neither is enough, which is roughly what most companies are about to discover by staffing one of them.
Anyone who has spent a decade in a large company will have an objection ready at this point: This has been tried. Between roughly 2016 and 2019 a great many enterprises embedded data scientists into business units for precisely these reasons, and got precisely the responsiveness they were promised, for about eighteen months. Then it went the same way almost everywhere. The embedded people drifted from the practice, their tooling diverged from everyone else's, what they built was held to a standard that could not survive contact with production, and their work was appraised by a manager with no way to judge it. Central teams re-formed to repair the damage, and a fair amount of the output was written off.
The resolution the survivors arrived at is well understood and worth copying rather than rediscovering at your own cost. The embedded person reports into the business for what they work on, and to a central AI engineering practice for how they work: standards, shared tooling, code and evaluation review, and an appraisal by people competent to judge the craft. That second line is what makes embedding survive its second year, and it is the part that gets left off when the org chart is drawn quickly.
The obvious objection to any of this is headcount. A group with fourteen departments does not want fourteen new engineers, and if the role is defined as a builder it will eventually need more than fourteen. But most of what I have described as context maintenance is not engineering work. Deciding that a warranty exception now applies to a product line introduced last year is a job for the person who owns warranties. The engineer's job is to make it possible for them to do it, which means keeping the judgement encoded in the agent legible and changeable by the people whose judgement it was.
That produces a test for whether the role has been set up correctly: Can the department change what its agents do without the engineer in the room? If the answer is still no at the end of the first year, the role has been staffed as a bottleneck, and what the company has built is departmental IT with a better title and an identical change request queue.
Which brings it back to the founder. The question I would want their sales team asking in the second or third meeting, rather than their customers discovering post go-live, is who by name will hold this. Every customer will say yes to needing governance. Considerably fewer will be able to name the person, and where the answer is a committee, or a function three floors away from the work, the product gets bought, deployed, presented once in a steering committee and used by no one in particular.
For anyone likely to be on the other side of that meeting, the useful move is to have the answer ready before the vendor asks for it. The tooling is arriving regardless. Whether it does anything depends on two roles that do not appear in most companies' AI budgets, because the budget was written for software.
That's the thirteenth pattern.