Two teams that don't share a vocabulary

A central AI platform team can build an agent that drafts invoice-processing logic, reconciles claims, or triages support tickets. They know models, retrieval, orchestration, and how to wire an agent into a CI pipeline. What they typically do not know is why the finance team routes invoices from three jurisdictions through different approval chains, why one supplier category can never be auto-approved, or why a particular ERP integration cannot change before quarter-end.

The business unit knows all of that. What they don't have is any way to turn it into something an agent can act on.

Neither side is missing skill. They are missing a shared object: a place where "this is how our business actually works" becomes something a coding agent can query before it writes a line, rather than something a person has to remember to mention in a meeting.

Concretely: an agent building the invoice-processing feature has no way to know that invoices routed through the EU entity require a second approver above €10,000, that the exception for the acquired subsidiary's legacy supplier codes expires at the end of the fiscal year, or that the "urgent" flag on a ticket means something different in procurement than it does in accounts payable. None of that lives in a schema. Most of it doesn't live in writing anywhere until someone is asked directly.

The role that bridges it is becoming formal infrastructure

This gap is now large enough that enterprises are building a role, and a program, around closing it. In 2026 ServiceNow and Accenture launched a joint forward-deployed engineering program, pairing ServiceNow's AI-native forward-deployed engineering team with industry-led Accenture forward-deployed engineers inside mutual customers' environments, specifically to take agentic AI from enterprise pilot to production at scale.

That is a meaningful signal on its own. Two large organizations did not create a joint operating program for a role that was a temporary staffing quirk. They created it because getting an agent from "works in the demo" to "works against this specific business" has become expensive and unreliable enough to warrant a dedicated function, embedded inside the customer, translating operational reality into system design.

That translation is the job. An engineer sits with the people who actually run the process, discovers the exceptions and constraints nobody wrote down, and turns them into something an AI system can be built against. It is close to what we described in the second piece in this series: inheriting the consequences of an architecture without inheriting the reasoning behind it, except here the "architecture" is a business process rather than a codebase, and the person doing the inheriting is explicitly tasked with fixing that gap rather than just working around it.

What makes this different from ordinary requirements-gathering is who the audience is. A requirements document is written for a person, who can ask a follow-up question when something is ambiguous. What a forward-deployed architect ultimately has to produce is legible to an agent that cannot ask, and will act on whatever it's given whether or not the given is complete.

The failure mode: the architect becomes another silo

Give this role a few weeks embedded with a business unit and it accumulates real knowledge. What must never happen. Which system is authoritative when two disagree. Which architectural choices were deliberate and which were accidents nobody fixed. Which exceptions are temporary and which quietly became permanent.

Where does that knowledge go? Usually into the same places it always has: Slack threads, ticket comments, a diagram in a deck, the architect's own memory. An agent working in that environment does not automatically inherit any of it, and availability is not the same thing as compliance. A document sitting in a wiki that nobody retrieves is inert. A document an agent retrieves and then overrides under task pressure is exactly as inert, just later.

This is the same distinction we've made about retrieval and enforcement in the codebase context, showing up one level up the stack. Giving an agent access to what the architect knows is necessary. It has never been sufficient, because retrieval tells an agent what a rule says, not whether the agent is permitted to violate it.

Without a system to carry that knowledge forward, the enterprise has the same problem in a new form. Before, the risk was a new engineer joining a team without the context to maintain it safely. Now it's an agent joining a business process without the context to operate inside it safely, at a speed that makes waiting for someone to notice considerably more expensive.

From tacit knowledge to a decision the system can carry

The fix is not asking the architect to write more documentation, for the same reason it wasn't the fix for the codebase version of this problem: documentation answers what a newcomer should know, not what must remain true regardless of what they're trying to accomplish. What actually needs to exist is a decision object, not a description.

A decision that a system can act on needs roughly six things: an identity, so it can be referenced and superseded rather than silently duplicated; a scope, so it applies to the right slice of the business rather than everywhere or nowhere; a lifecycle, so a stale decision doesn't keep firing after it stops being true; the rule itself, stated precisely enough to evaluate; any exceptions, with an owner and an expiry rather than an open-ended carve-out; and evidence, a record of what was checked and what was allowed, after the fact.

Take the EU approval exception from above. Written as a decision object it might look like: identity DEC-EU-APPROVAL-07; scope, invoices routed through the EU entity; rule, a second approver is required above €10,000; exception, the acquired subsidiary's legacy supplier codes, owner the EU controller, expiring at fiscal year end; evidence, every proposed invoice-processing change checked against it, logged. None of that requires new technology. It requires someone to have asked the question and written the answer down in a form more durable than a Slack reply.

Not every decision the architect uncovers reduces cleanly to a mechanical rule, and treating them as if they do is its own failure mode. Mneme's Architecture Protection Audit already draws this line for architectural decisions in a codebase, and the same taxonomy is useful here: some decisions are Protected by an active deterministic rule, some are Mneme-ready and waiting on deliberate activation, some require more modelling before they can become a rule at all, and some are Guidance — genuinely important, and genuinely a matter for human review rather than mechanical enforcement. The job of the forward-deployed architect is closer to that of the Audit itself: sort what was discovered into these categories, rather than force everything into one.

Discovery is shipping. It is not the finish line.

Getting an agent to find the applicable decision has been the harder half of this problem, because every business unit's context lives in a different shape: some in tickets, some in wikis, some only in a person's head once the architect has extracted it. Mneme now exposes its decision store as an MCP server, so any MCP-aware agent, Claude Code, Cursor, a custom SDK agent, can query which decisions apply to the task in front of it without a bespoke integration for every tool. See the MCP integration for setup.

That closes the discovery gap this series has been circling. It does not close the enforcement gap, and the distinction matters more here than almost anywhere else in this series. An agent can query the decision store, retrieve exactly the right constraint, and still generate a change that violates it, because retrieval only ever answers did the agent know. The question that actually protects the business is was the agent allowed, and that is a separate, deterministic check against the proposed action, not a property of how good the retrieval was.

Put the two side by side: discovery tells an agent what applies here. Enforcement decides whether the specific thing it's about to do is compatible with that. MCP is real progress on the first. It was never going to be the answer to the second, and nothing about it claims to be.

What the operating model looks like

Put the pieces in order and the shape of the role changes without the role disappearing. The forward-deployed architect still discovers how a business unit actually operates, that part does not compress. What changes is what happens to what they find: it becomes a decision with an identity, a scope, and a lifecycle, sorted the way the Audit sorts architectural decisions rather than left as a note in a ticket. Where a finding lands in the codebase, that sorting is what Mneme already does today. Where it is a business rule rather than an architectural one, the same shape applies but the enforcement question is still open, and pretending otherwise would be the same mistake as treating a wiki page as a control. And when the architect moves to the next business unit, the decisions they found don't leave with them.

That last part is the actual win. The architect still provides the judgement; nothing here replaces that. What changes is that the judgement no longer has to live in one person's head to keep working, and it doesn't reset every time a new engagement starts. The next forward-deployed architect who walks into that business unit inherits a decision corpus instead of a blank slate, and the agents already operating there keep respecting constraints nobody has to re-explain.

Programs like ServiceNow and Accenture's are scaling the discovery side of this because the commercial need is obvious: more business units, more agents, more engagements running in parallel than any one person can carry in their head. The decision layer is what makes that scaling survive contact with an actual enterprise, rather than producing faster demos and the same slow, fragile production rollouts.