Series: Building the AI Foundation Part 4: Part 1: Stop Picking AI Tools laid out the seven-layer architecture. Part 2: The Context Layer covered how AI reaches your systems. Part 3a: The Developer Gate and Part 3b: The Operations Gate covered how changes get reviewed, for code and for plant records. This piece covers layer seven, the control plane. Part 5 covers how the tool-facing layers plug into all of it.

Here’s a question I’d like you to try on your own shop: which AI agent issued a customer credit last Tuesday? If you can’t say, you’re in good company. Most of us have logs. Very few of us have an answer.

Picture the morning. Your controller walks over and says a batch of customer credits posted overnight, $38,000 in all, and nobody in customer service remembers approving them. You pull the access log from Part 2 and see an agent read a customer’s order history at 2:07 a.m. You pull the change log from Part 3b and see a credit memo proposed at 2:11 and approved at 2:14. Now the real questions start. Which agent was it? Whose agent? Was that 2:14 approval a person thinking, or a person clicking? What did the run cost, and what else did it touch before it stopped?

“Let me get back to you” is where most of us land, and it can take a week.

The layer that turns that week into five minutes is the control plane. It’s layer seven, and if I were rebuilding my own stack from scratch, it’s the one I’d put in first.

Five jobs, no product

You can’t buy a control plane. It’s five jobs that somebody has to do: identity, policy, gateway, audit and cost. Skip them and you’ll still end up doing them, just one incident at a time and at a worse price. I’d rather we chose to do them on purpose.

Identity. Every request carries a person or a named agent. Never a shared key.

Policy. The data classification from Part 1 becomes rules a system enforces, not a PDF.

Gateway. One path for the model calls you own, where policy applies, sensitive fields get redacted and everything gets logged.

Audit. One record that joins what an agent read, what it proposed and who approved it.

Cost. Budgets and caps per team and per agent, with alerts that fire before the invoice does.

I’m not the only one who frames it this way. BCG tells CIOs to separate the control layer from the build layer, and Forrester now evaluates the agent control plane as its own market. It’s reassuring to see the idea has company. The work, though, still lands on us.

Start with who

Everything else on the list depends on identity, so let’s begin there.

Go back to the 2:07 a.m. story and suppose the agent ran under a shared service account. Part 2’s log says the integration account read the order history. Part 3b’s log says the integration account proposed the credit. Both statements are true, and neither helps. You still can’t tell which agent it was, which team owns it, or whether a human was anywhere near the request.

This isn’t only a tidiness problem. The worst agent-related breach I came across while researching this piece wasn’t a model going rogue. In the 2025 Salesloft Drift incident, attackers used stolen OAuth tokens tied to an AI chat agent to pull data out of customers’ Salesforce instances. The agent’s identity was the front door.

The rule I’d suggest is simple. When an agent acts for a person, that person’s identity travels with the request. When it runs on its own schedule, it gets a named identity of its own, scoped to what it needs, with a human owner on record. When that owner changes roles, the agent’s access gets reviewed the same day theirs does.

It’s dull work. It’s also the difference between a five-minute answer and a five-day one.

A policy nobody enforces is a wish

I’m fond of the one-page data classification from Part 1, because people actually remember it. But a page people remember still depends on people remembering it at 4:45 on a Friday, and none of us is at our best then.

So make each tier something a machine checks. Public and internal data can go to approved assistants. Confidential data goes only to tools under enterprise terms whose retention you’ve read yourself. Restricted data, meaning HR, payroll and customer personal information, stays on the private tier or stays out of AI altogether. The check lives in the gateway and in each tool’s admin settings, where it runs every time, whether anyone remembers or not. OWASP’s guidance on excessive agency lands in the same place: enforce authorization in the downstream system and don’t ask the model to police itself.

There’s a newer piece worth watching here. A new class of decision models returns a typed answer, such as a choice from a fixed list or a yes/no probability with a confidence score, instead of free text. TypeSafe AI’s Jev is one, and OpenAI has announced a Decisions API along similar lines. In a gateway, that kind of model could check a request against your data tiers and return an answer your audit log can store as-is. It’s early, the vendor claims aren’t independently verified, and I’d test any of them on your own data first. I’ll give it a full article in Part 5.

The gateway trap

This is the mistake I’d most like to save you from. A team builds a gateway, routes a few calls through it, feels covered, and quietly misses most of the real usage.

A gateway only sees what goes through it. ChatGPT Enterprise, Microsoft 365 Copilot and GitHub Copilot are hosted services with their own front doors, and you can’t route them through yours. You govern them from the admin side: single sign-on, the vendor’s console, and the audit export. The gateway earns its keep on everything you build or call by API, which means internal agents, the MCP servers from Part 2, scripts and local models.

Two paths, one destination.

Make Tuesday a five-minute question

Joining the logs takes one habit. Every event carries the same identity and a shared session or request ID. Once that’s true, the 2:07 a.m. mystery becomes a single thread you can pull: the agent pulled the customer’s order history (Part 2’s log), proposed a credit in the same session (Part 3b’s log), and at 2:14 an owner approved it. Or nobody did, which is also an answer.

I’d also keep a second record of your own rather than leaning on a vendor’s log alone. In 2025 a researcher reported that Microsoft 365 Copilot could be prompted to skip recording the files it had accessed, and Microsoft fixed it in August. That’s one researcher’s account, so I’d hold it loosely, but it’s a fair reason to cross-check.

If you run a regulated plant, the bar is already written down. FDA’s 21 CFR 11.10(e) calls for secure, time-stamped, computer-generated audit trails of operator actions. I haven’t found a public case of a manufacturer applying that to AI-made BOM or routing changes. That’s my argument rather than settled practice, and I expect we’ll see it asked for soon.

You don’t need a perfect system to start. You need three answers, fast. What did this agent read and change in the last week? Who approved each change? What did this person’s tools cost?

The invoice shouldn’t be your first alert

Pricing moved under all of us this year. OpenAI shifted Codex to token-based credits in April. GitHub moved Copilot to usage-based AI Credits on June 1. A seat price used to tell you roughly what you’d pay. Now it tells you the entry fee.

Agents turn that up a notch, since one unattended agent stuck in a loop can use more than a team of people typing. My suggestion: set a budget per team and per agent, alert at half and again at eighty percent, and use hard limits wherever the tool supports them. ChatGPT Enterprise workspace owners can set usage alerts and hard overage limits, and GitHub admins can set budgets with expiration dates on individual users. Turn them on day one. I’ve yet to meet anyone who regretted a cap that fired early.

Five ways this goes sideways

These are the patterns I’d watch for.

The shared account. Something breaks and the investigation ends at “the integration account did it.”

The gateway nobody uses. Engineers paste code into personal accounts that never touched it. The gateway was fine. The coverage wasn’t.

The PDF policy. The data policy exists as a document with nothing enforcing it, and the first audit finds three tools nobody approved.

Four logs, zero joins. The evidence exists, in four places. A five-minute question takes a week.

The surprise invoice. Someone learns what an agent cost from the bill.

What building this taught me

When I wrote the AI adoption plan for my own IT organization, single sign-on, the data policy, device management and repository rules all went into Phase 0, ahead of any broad rollout. People reasonably asked why we were doing the paperwork before the interesting part.

My answer was retrofits. Add identity after two hundred people already use a tool and you re-onboard two hundred people. Add it first and nobody notices it happened. Everything that feels like slowing down at the start becomes the reason we can say yes quickly later.

Where this leaves you

Nobody buys a control plane for the demo, and it never makes a keynote. It only gets noticed the day something goes wrong, and by then it’s either there or it isn’t.

Here’s a test you can run Monday. Pick one agent in your environment, any one, and try to answer four things: what it read, what it proposed, who approved it, and what it cost last week. Time yourself. If it takes more than a few minutes, you’ve found your first project, and I’d love to hear how it goes.

That’s the article. Subscribers have access to the working files below:

• The Tuesday-question worksheet (fillable PDF)

• Policy as rules: the data tiers

• Budgets and alerts

• What the hosted vendors keep, and where it runs out

• The Phase 0 checklist (fillable PDF)

If you can’t see them, all you need to do is subscribe to menonstack.com using the button below.

Read more

Series: Building the AI Foundation — Part 3b of 3a/3b. Part 1: Stop Picking AI Tools laid out the seven-layer architecture. Part 2: The Context Layer covered how AI reaches your systems. Part 3a covered layer six for developers. This piece covers the same layer for manufacturing and ERP operations. Part 4 will cover the control plane.

Part 3a covered the system-of-record layer from the developer side: one gate, no exceptions, and twenty years of tooling built to enforce it. This is the other half, and I’m writing it from the floor, not the office. The planner whose ERP now has an AI copilot suggesting reorder points. The quality engineer whose disposition assistant drafts a nonconformance resolution. The process engineer whose routing just got updated by an agent that read a work instruction and decided it knew better. All of them are changing systems of record every day, and almost none of them have a gate.

I’m focusing this on manufacturing and ERP specifically, since that’s where I’ve spent 25 years and where I think the stakes are different from a typical back-office example. A miscategorized sales lead is embarrassing. A wrong substitute component on a bill of materials can ship a defective unit, and in some industries, that’s not a business problem, it’s a regulatory one.

What’s actually happening

An AI copilot inside the ERP updates a bill of materials, swapping a component for an approved substitute, based on a supply shortage it read about in a planning note. A quality assistant closes out a nonconformance disposition because the defect looked similar to one it had closed before. A planning copilot adjusts safety stock on a critical part because demand looked flat for two weeks. A routing gets a new standard time because an agent recalculated it from recent cycle data. Genie, or a similar tool, answers an OEE or yield question by writing its own query against the plant’s data.

In each case, something that used to require an engineer’s or a planner’s deliberate judgment now happens because an AI decided it should. In most plants I’ve seen, nothing stands between that decision and it becoming the official version of the record.

What “system of record” means on the floor

A system of record is wherever an organization keeps the trusted version of something, plus the process that decides what earns that status. On the floor, that’s the item master, the bill of materials, the routing, the production order, and the quality notification, all living inside the ERP, with a process that’s supposed to govern changes to each one. Most of those processes were built assuming a person made every change. None of them were built assuming an AI agent might.

If your plant doesn’t have that process updated for AI involvement, sit with what that likely means. An agent has probably already touched a BOM, a routing, or a quality disposition, and nobody flagged it as different from a change an engineer made by hand. It won’t look like a safety incident. Nothing shuts down. A substitute part gets used that engineering never formally approved, or a quality hold gets released based on a disposition nobody double-checked, and you don’t find out until an audit, a customer complaint, or worse.

Why none of this works without governed data

Every check I describe below assumes something underneath it: that the data feeding the check is itself reliable. A BOM reconciliation check only works if engineering’s approved revision is the one actually sitting in the system. A routing change check only means something if the standard times it’s comparing against reflect current reality, not a routing that was updated informally six months ago and never synced back. A quality rule check depends on a defect taxonomy that means the same thing in every plant, not one that’s been redefined locally three different ways.

This part is easy to skip, because it doesn’t look like a system-of-record problem. It looks like a master-data problem, which sounds smaller and further upstream. It isn’t smaller. Governed data, meaning data with clear ownership, a known schema, defined lineage, and accountable stewardship, is the precondition for everything else in this piece. I’ve watched a single item master discrepancy between two plants on the same ERP instance cause a planning error that took weeks to trace back to its source. An AI agent making decisions on top of that same discrepancy doesn’t fix the problem. It just makes the wrong decision faster, and with more apparent confidence.

This is also where Part 2 connects directly to this layer. The curated layer with shared definitions that The Context Layer described sitting in front of multiple ERPs is what makes a downstream BOM or routing reconciliation check meaningful in the first place. Skip that layer, and every check described here validates a change against data nobody has actually agreed on, plant to plant.

Developers get a warning when this goes wrong, since a bad schema tends to break a build loudly, as Part 3a covers. A plant doesn’t get that warning. A BOM that means something different in two plants doesn’t break anything visibly. It just makes every downstream production order, and every automated check built on top of it, quietly wrong at the same time.

The gate this layer needs

A change to a BOM, a routing, or a quality disposition should move through something structurally similar to a pull request: a proposed edit, a check against whatever rules govern that record, review by whoever owns it, and only then adoption as the official version. Developers have tooling for every step of that, covered in Part 3a. Most ERPs have the last step, a save or a transaction code that commits the change, and not much enforcing what comes before it when an AI made the proposal.

An engineering change control process can stand in for branch protection. A BOM or routing edit shouldn’t go live until it clears the same formal review a human-initiated change would require, whatever tool proposed it.

Quality and engineering rules can stand in for automated tests. Does this substitute component appear on the approved list for this item. Does this routing change fall within the standard-time variance engineering allows. Does this disposition match a defect code that’s actually been delegated for automatic resolution.

A named owner can stand in for CODEOWNERS. A BOM change routes to engineering. A quality disposition routes to the quality engineer of record. A safety stock change routes to the planner who owns that part family.

The merge-rights rule from Part 1 applies here too. An agent can propose a change to any of these. A person decides whether it becomes official.

Traceability

Most ERPs already keep change documents, so you can usually see that a BOM or a routing changed and when. What they rarely tell you is whether an AI copilot proposed that change on its own initiative, what it based the change on, or whether anyone with the right authority reviewed it before it went live. Quality systems are often worse, especially once an AI assistant is drafting disposition language directly into a record with no trail that distinguishes it from an engineer’s own notes. Genie sharpens the same problem for plant analytics, since someone can generate an OEE or yield number through a conversational query with no artifact resembling a change document behind it. Even where a record of change exists, a record of AI involvement usually doesn’t.

Review at scale, without a queue

Developers have a capacity problem, covered in Part 3a: AI-assisted pull request volume outpacing human review capacity. Manufacturing has a different problem, and it isn’t about volume. Most plants never had a review role for this kind of change in the first place, whether the change came from a person or an AI. There’s no queue to overwhelm, because nobody built a queue. A planner might notice a safety stock level looks off. A stockout or a quality escape is often the first time anyone looks closely enough to ask where a number actually came from.

Where this connects back to The Context Layer

Part 2’s registry logs what an agent read: which system, which fields, under whose identity. This piece logs what changed afterward. Put those two together and something useful happens. An agent that queried inventory data across two plants through Genie, then in the same session proposed a BOM substitution, produces a signal that only makes sense once someone’s looking at both logs side by side.

Failure patterns worth naming

Most of what follows traces back to the same root cause: a gate that looked correct, running on data nobody had actually governed.

An AI copilot substitutes a component on a BOM based on a supply note, and the substitute was never qualified for that application, which nobody catches until a field failure traces back to it.

A quality assistant closes a disposition that reads fine but releases a hold engineering never actually signed off on, caught only when an audit asks for the paper trail.

A planning copilot drops safety stock on a part because recent demand looked flat, and a single large order turns it into a stockout that stops a line.

Someone asks Genie for a yield number, gets an answer built on a different definition than the one engineering certifies against, and only finds out when the plant’s own report disagrees with it in a review meeting.

What building this taught me

The developer side of this layer, covered in Part 3a, was the easy part to specify when I put together the IT org’s AI adoption plan. GitHub rulesets, required reviews, CODEOWNERS on critical paths, all of it maps onto tooling that’s existed for years.

The harder conversation, in every manufacturing environment I’ve worked in, was never about the ERP’s change-control features. Those exist. It was about whether anyone had updated the assumption underneath them, that a human initiated the change being controlled. An AI agent proposing a BOM substitution doesn’t trip any of the alarms built for a careless engineer, because it isn’t careless. It’s confident, fast, and occasionally wrong in a way a human reviewer would have caught immediately if they’d known to look.

Where this leaves you

Whether the change is a BOM, a routing, or a quality disposition, the discipline should be the same one Part 3a described for code: one governed path, resting on governed data, applied identically regardless of which AI proposed the change. Most plants are operating without that path today, and I’d guess yours is too, unless someone’s specifically gone looking. That’s the bigger risk sitting on most shop floors right now, not because the technology is unsafe, but because nobody’s built the gate for it yet.

Series: Building the AI Foundation — Part 3a of 3a/3b. Part 1: Stop Picking AI Tools laid out the seven-layer architecture. Part 2: The Context Layer covered how AI reaches your systems. This piece covers layer six for developers specifically. Part 3b covers the same layer for business users. Part 4 will cover the control plane.

I started writing this as one article, covering code and business systems together under the heading “the system of record.” A few pages in, it was clearly fighting itself. Developers have twenty years of tooling behind this question. Everyone else has almost none. Mixing them made both halves weaker, so I split it. This piece is the developer half. Part 3b covers the harder, less comfortable half: CRM, contracts, HR policy, and the analytics tools that are quietly rewriting business records with no review at all.

Stop Picking AI Tools, Part 1 of this series, argued that AI works better as an architecture than as a purchase: seven layers, most of them meant to be swapped out as models and vendors change. The Context Layer Is Where Multi-System Enterprises Get Stuck, Part 2, went deep on layer five and covered how AI reaches ERP, CRM, custom apps, a data platform if you have one, and the sensitive systems that need a separate tier of their own.

This piece picks up layer six, the system of record, from the side where the discipline already exists.

One gate, whichever tool wrote the change

Here’s the part developers already know in their bones. An agent opens a pull request. It gets reviewed and tested. It merges. Whichever tool wrote the code, Copilot, Cursor, Codex, or an agent from Part 1’s delegated-development layer, the same gate applies. Nobody argues with that principle out loud. What’s worth digging into is what actually has to be true for it to hold up once the tools get good enough to tempt you into cutting corners.

What actually needs to be true

Branch protection comes first. Required reviews, with no bypass for “the AI already checked it.”

The tests don’t care who’s asking. CI and CD gates run the same suite no matter who or what opened the PR.

Security scanning stays uniform. Static analysis, secrets, and dependency checks apply without exception, regardless of how fast the change came in.

Review assignment doesn’t shift. CODEOWNERS or something like it routes review the same way whether a human or an agent authored the change.

The merge line holds. This is the rule from Part 1, and it’s worth repeating here specifically: an agent from the delegated-development layer opens a pull request. It never merges one.

That last one gets harder to enforce as agents get better, not easier. The better an agent’s track record, the more tempting it is to let it skip the queue “just this once.” Resist that. The gate isn’t there because you distrust the agent. It’s there because building a safe exception path is its own project, and most teams that try to shortcut it end up building exactly that project anyway, just after something’s already gone wrong.

Why this still depends on governed data

Every check in that gate assumes something underneath it. A test suite assumes the code it’s testing reflects reality. A security scan assumes its dependency database is current. None of that is really a code problem, and it’s worth saying plainly: a pull request can pass every check in this article and still be wrong, if the data or systems it touches were already unreliable before the AI got involved.

I’m not going to dig into this deeply here, because Part 3b does, and it’s the more important half of that conversation. But I don’t want developers reading this to think governed data is someone else’s problem. It isn’t. It’s just better handled, so far, on this side of the fence.

Traceability

This is the part developers already have mostly right, and it's worth seeing why, because Part 3b will show you what it looks like when this is missing entirely. Commit and PR metadata identify which tool or agent produced a change. Good practice links that change back to the task or spec behind it, often traced to a context-layer read from Part 2's registry. If something breaks in production six months from now, you can usually reconstruct what an agent was told to do, what it touched, and who approved it.

Review at scale

Part 1 flagged that AI-assisted pull request volume can outpace human review capacity, and that’s the real bottleneck here, not whether the gate exists. The gate is fine. The humans reading what comes through it are the constraint.

The fixes are becoming standard: AI-assisted first-pass review, and smaller pull requests as policy, especially for anything a delegated agent wrote. What changes is the reviewer’s actual job. It shifts from reading every line to judging whether the first pass caught what mattered. That’s a different skill, and I’d train for it directly rather than assume it develops on its own.

Failure patterns worth naming

A team fast-tracks AI pull requests because each one looks small, until a small change breaks something nobody reviewed closely.

A team blocks AI PRs from auto-merging but lets a human rubber-stamp them without real review, which defeats the purpose from the other direction.

Nobody owns updating branch protection as new agent tools arrive, so the gate loosens quietly over a year, and no one ever decided that on purpose.

What building this taught me

The developer side of this layer was the easy part to specify when I put together the IT org’s AI adoption plan. GitHub rulesets, required reviews, CODEOWNERS on critical paths, Copilot running first-pass review, agents that open PRs but never merge. All of it maps onto tooling that’s existed for years, and most of the work was configuration, not invention.

The harder conversation came later, once I started asking the same question about systems that aren’t code. That’s where Part 3b picks up, and it’s the half of this topic I think more people need to read.

Where this leaves you

Developers have this path built and mostly working, which makes it tempting to assume the system-of-record problem is solved across the company. It’s solved in one domain. I’d be curious whether your organization has even asked the question in the others yet, which is exactly what Part 3b is about.

Leave a comment

Series: Building the AI Foundation — Part 2 . Part 1: Stop Picking AI Tools laid out the seven-layer architecture. This piece is a deep dive into layer five, the context layer. Part 3 will cover the system of record.

The first article in this series, Stop Picking AI Tools, proposed treating enterprise AI as an architecture rather than a purchase. That architecture had seven layers, and most of them exist to be replaced as vendors and models change. Several readers responded with variations of one question. One division runs SAP, another runs a platform built on IBM i, and a third depends on a customer relationship system that few people trust. Dozens of internally built applications sit beneath all of it. Which layer addresses that problem?

This article addresses it. The context layer, fifth of the seven, receives the deepest treatment in this series because organizations tend to misconfigure it before they reach questions of governance. The difficulty lies in deciding which systems count in the first place.

The systems the standard diagram leaves out

When consultants draw enterprise systems, they usually draw one ERP with clean lines to a CRM and a data warehouse. After 25 years in enterprise IT and ERP, I’ve rarely seen a landscape that tidy.

A realistic diagram has one or two ERPs, often inherited through acquisitions. The CRM is the one half the sales team works around. Somebody built a quoting tool in 2014, it still runs part of the business, and the only person who understood it has left. A plant-floor system has no real API because nobody expected it to need one. Then there are the systems holding data you can’t expose casually: payroll, customer identifiers, safety records, and sometimes regulated manufacturing data.

Many companies also run a data platform that copies information from several of these systems into one governed place. That changes the picture more than people expect, and I’ll come back to it below.

Every AI initiative runs into this landscape early. An assistant that knows one system helps only the people who work in that system. Wiring each new tool straight to each new system brings back the sprawl from Part 1, one layer down.

Why point-to-point access breaks down

The obvious first move is to let each AI tool build its own connector to each system. With three tools and three systems, that’s nine integrations. Each one has its own authentication, its own reading of the data, and its own maintenance. Part 1 mentioned this problem in passing. With several ERPs, a CRM, and custom applications, it becomes the main one.

Custom applications make it worse because there’s no vendor connector to start from. Sensitive systems raise the stakes: a careless integration is a real exposure, and nobody wants to explain why an AI assistant could read compensation data because a connection already existed.

What MCP actually is, in plain terms

The Model Context Protocol, or MCP, is a standard way for an AI tool to discover and call the tools and data a server exposes. The protocol will keep changing, and it may not be the standard in three years, so I wouldn’t invest in it for its own sake. What it removes is the need for a separate integration for every pairing of tool and system. Build one connector per system and any compatible tool can use it, whichever one your teams prefer this year.

It’s the same argument I made for AGENTS.md in Part 1, one level up. Different artifact, same principle: put the effort where it outlasts any single vendor.

The pattern changes with the type of system

What sits behind a connector determines how you build it.

ERP and CRM platforms usually have mature APIs and existing connectors, so the work is scoping and normalization. You can expose each system’s own terms as they are, or map “sales order,” “SO,” and whatever the CRM calls the same thing to one shared term. Native terms ship faster. A shared vocabulary takes longer to build, and it lets someone ask for total open orders across two plants and get one answer instead of two.

Custom applications often have no API at all, so the work starts a step earlier. The best option is a thin API layer added to the application itself, if you can change the code. Next best is reading from a replicated database, which keeps any load off production. Script-based access with close monitoring is the last resort. Most of the engineering time in this layer goes into that bridge, and very little goes into learning the protocol.

Every server should sit behind a registry, or gateway, that AI tools use to discover approved connections. Without one, people configure connections by hand, and the sprawl returns.

When a data platform already exists

Many companies already run a data platform, such as Databricks, that pulls data from the ERPs and the CRM, plus some custom applications, into one governed place. If yours does, five things change.

First, it’s a new kind of system in the landscape, and a friendly one. Databricks provides managed MCP servers over Unity Catalog data, search indexes, Genie, and custom functions. Unity Catalog enforces permissions on those servers, and they can authenticate as the individual user, so agents reach only what that person has been granted. That matches the identity rule I’ll get to below. Other platforms may offer something similar, so check yours before assuming it.

Second, normalization moves upstream. If the ERPs and CRM feed a curated layer with shared definitions, “open orders across both plants” becomes a query against one set of tables instead of a mapping project on every server. The work shifts to data engineering: pipelines and master data, plus the definitions both depend on. A weak curated layer gives confident wrong answers, so every pipeline needs a named owner.

Third, custom applications get an easier path. Replicating their data into the platform gives you the replicated-database option once, for many applications, and you skip a separate bridge for each. That covers reading only. Writing back still needs another route.

Fourth, the context layer splits into two lanes. One is for knowing: analysis, and grounding answers in current data. The other is for acting: creating or updating records in the systems of record. Creating an order still needs a server in front of the ERP, with the same scoping and identity rules as before. The platform answers questions; it doesn’t replace those servers.

Fifth, sensitive data gets easier to govern and easier to expose. You can apply column masking and row filters once, at the catalog, and tag sensitive fields in the same place, instead of rebuilding that protection on every server. The same consolidation concentrates risk, though. Joining data from several systems can reveal things no single system showed on its own, so the sensitive-tier review has to cover joined and derived datasets, not just the sources.

One more caution, about the registry. Databricks lets administrators see and manage its own MCP servers in one place, which is useful. Your registry still has to cover every system. If a single platform’s console becomes the registry, one vendor ends up holding the role I argued in Part 1 should stay neutral.

Sensitive-data systems deserve their own tier, not a footnote

I want to be direct about this, because it’s the part people skip past.

Some systems shouldn’t get a general-purpose MCP server, at least at first. HR and payroll are the clearest examples. They’re usually better served by narrow, read-only tools with field-level redaction built in than by a general connector with a few fields switched off afterward.

Scoping has to go below the system level, down to individual fields. A server over your CRM might expose accounts and opportunities and leave out compensation and personal identifiers. Redaction belongs at the server, before any response reaches the model. A prompt-level instruction can’t give the same protection, because a well-meaning user or a differently configured tool might skip it.

That calls for a separate, heavier approval path. A server that touches regulated or sensitive data goes through security review, and often legal review, before it enters the registry. A sales or operations system gets a lighter one. It's slower on purpose. A decision like this shouldn't move at the speed of a Friday afternoon message thread.

Governance across the whole registry

Four principles hold whatever system sits behind the server.

Identity comes first. MCP calls should run as the requesting user and never as a shared service account, so the underlying system’s own authorization still applies. Custom applications tempt people the other way, because one broad credential is easier than per-user authentication, so this matters more there.

Scoping is second. Give each server a narrow, task-specific set of tools. Handing over a system’s full capability because a template made that the easy path is the usual way this goes wrong.

Audit comes next. Every MCP call is a loggable event, so treat it like any other system access. A vendor’s chat history isn’t an audit trail.

Ownership is the hardest to assign. Someone has to update a server when the underlying system changes. That’s straightforward for ERP and CRM platforms, which follow release cycles. Custom applications often have none, and their servers go stale and keep answering with full confidence. Data pipelines carry the same risk, so they need owners too.

A rollout sequence for a real enterprise

Start with the system that has the best API and the lowest sensitivity. Often that’s a curated, non-sensitive set of tables in the data platform, where governance already exists. Prove one narrow use case end to end on that server before you add a second.

Build the registry, and especially the sensitive-data approval path, while you only have two or three servers. Adding that structure after fifteen servers are running costs much more. Then expand in order: mature systems next, custom applications once their bridges exist, and sensitive systems last, through the heavier review path.

It’s the same phasing as the adoption plan in Part 1, one layer down: prove it small, and build governance while it’s still cheap.

Failure patterns worth naming

These recur often enough to name. A shadow MCP server appears on someone’s laptop because the official one took too long to approve. Credentials sit in a config file because nobody has set up secret management for this layer. A server built from a generic template exposes far more of a system than anyone intended, because nobody reviewed the defaults. A sensitive system gets connected to a general-purpose server because it was already there, and nobody asked whether it belonged. And an unowned pipeline goes stale, so the answers look authoritative and are wrong.

None of these is unusual. Each comes from putting speed ahead of structure.

What building it myself taught me, this time

In Part 1 I said context beats model choice, and this layer is where I’ve seen that most clearly. I designed a complete ERP application specification meant to be built by a team of AI agents, and most of the effort had nothing to do with AI. It went into scoping: deciding what each component needed to know and in what form, along with what it should never touch. The specification worked as a context layer for a system that didn’t exist yet.

The lesson carried straight over to this article. The protocol is the easy part. Deciding what belongs on the other side of it, and what doesn’t, is where the judgment is, whether you’re specifying a system for agents to build or choosing which of your fifteen production systems gets an MCP server this quarter.

Where this leaves you

The protocol will keep changing. MCP itself may not be the final standard, any more than any specific model is the final model. What won’t change is the discipline underneath it: one connector per system, not per tool; narrow scopes instead of broad access; identity carried all the way through; and a clear, deliberate line around what doesn’t get connected at all, at least not yet.

That discipline is the actual asset. Everything else is implementation detail that next year’s tools will happily inherit, if you’ve built it right.

Share Balu Sudhakar

Series: Building the AI Foundation — This is the first piece in a series, Building the AI Foundation, on the seven-layer architecture I use for enterprise AI. Part 1 lays out the full model. Later parts go deep on individual layers — starting with the context layer, where MCP earns its keep.

Every IT leader I talk to right now is getting the same question from their CEO, their board, and their own teams: “What’s our AI strategy?” In most early-stage organizations, the honest answer is a collection of licenses. Some people have ChatGPT. A few developers are trying Cursor or Copilot. Someone in the architecture team is running models on a laptop. And a lot of people aren’t using anything at all, because nobody has told them what’s allowed.

I’ve been through enough technology waves (ERP, cloud, mobile, digital) to recognize the pattern. We start with tools because tools are tangible. You can buy them, demo them, and put them in a board deck. But tools are the part of this that changes fastest. The model that’s best for coding today will be overtaken in six months. The vendor you standardize on this year may not be your vendor in three.

I’ve also spent the last couple of years doing more than reading about AI. I run a self-hosted lab at home where I build and break things: local models, AI agents, automated workflows. Some of what I’ll share here comes from boardrooms and delivery programs. Some of it comes from late nights in my own lab, finding out firsthand what works and what doesn’t.

So I want to offer a different starting point: treat AI as an architecture, not a purchase. Define the layers, the job each one does, and the rules that govern it. Then pick tools to fill those layers, knowing you’ll swap some of them out. Whether your company leans toward OpenAI, Anthropic, Google, or Microsoft matters much less than whether you’ve built the structure that lets you change your mind.

The mistake most of us make first

The typical early-stage pattern goes like this. A few enthusiasts adopt tools on their own. Leadership buys an enterprise license for one assistant to “get ahead of it.” Usage spikes for a month, then flattens. Six months later, you have overlapping licenses, no idea what data went where, and a team split between people who swear by AI and people who tried it once, got a wrong answer, and moved on.

The root cause is almost never the tool. It’s three missing things: clarity on what’s allowed, a shared place where AI work lands and gets checked, and a deliberate plan for how people learn. Architecture solves the first two. The adoption plan solves the third.

What building it myself taught me

I don’t think you can lead AI adoption credibly without getting your hands dirty, so I did. Over the past couple of years I’ve built a home lab running open-source models, workflow automation, and a set of AI agents that handle real work for me every day. One maintains a personal knowledge base: it captures what I work on, writes my morning brief, wraps up my day, and runs a weekly review. Another assembles a daily digest of news and markets. I’m now building a local-first, voice-driven assistant on top of that knowledge base, and I’ve designed a full ERP application specification intended to be built by a team of AI agents rather than a team of developers.

Four lessons from that work shaped the architecture in this article.

Context beats model choice. The single biggest jump in quality didn’t come from switching to a better model. It came from giving the AI better context: well-organized knowledge, clear instructions, and structured specifications. When I designed the ERP spec for an agent team, most of the effort went into making it precise enough for agents to act on. That’s why the context layer is central to this model.

Local models are real, but narrower than the hype. I’ve tested open models on everything from an older laptop to a well-specced MacBook Pro. For private data, summarization, and everyday tasks, they’re genuinely useful, and they cost nothing per token. For complex, multi-step reasoning and agentic coding, the frontier cloud models are still meaningfully ahead. That experience is why I describe the private tier as a data-sovereignty layer, not a replacement for cloud AI.

Agents need boundaries by design. In my own setup, I use a cloud coding agent as a tightly scoped connector: it gets predefined instructions, does one job (fetching email and calendar data), and writes its output to a known location with a traceable ID. It doesn’t get open-ended access. That pattern of narrow scope, defined outputs, and traceability is exactly what enterprises need for delegated agents, and it’s why the system-of-record layer insists that agents open pull requests but never merge them.

Tool choice is the least durable decision. Even in a home lab, I’ve swapped models and tools more times than I can count. What survived every change was the structure: where knowledge lives, how agents are instructed, how outputs are checked. Multiply that by an enterprise, and the case for architecture over tools makes itself.

I’ve been codifying these lessons into a framework I call the MenonLabs Agentic Engineering Framework. What follows is the enterprise architecture at its core.

The seven layers

Here’s the model I use. It comes from what I’ve seen across decades of ERP implementations, program management, and IT delivery: the organizations that absorb new technology well are the ones that define the structure first and fill in the tools second. It’s deliberately vendor-neutral.

1. The everyday assistant. This is the general-purpose AI that everyone in the company uses for drafting, analysis, research, summarizing, and thinking out loud. It’s the broadest-reach layer and usually the first one you license. The job here is enterprise terms (no training on your data, controlled retention), single sign-on, and a small number of approved connectors to your document stores.

2. Interactive development. This is AI inside the developer’s editor, working alongside them in real time on completions, multi-file edits, and explanations. The key design decision is not which tool, but how many. My recommendation: one primary AI editor per developer, with a clear default and an opt-in path for power users. Paying for two overlapping coding assistants per person is the fastest way to waste budget.

3. Delegated development. This is the layer most organizations haven’t thought about yet, and it’s where the biggest shift is happening. You hand an agent a well-defined task (write tests for this module, upgrade this dependency, document this service) and it works in a sandbox and returns a pull request. The developer’s role moves from writing every line to specifying and reviewing. Start this layer on bounded, low-risk work, and never give agents the ability to merge.

4. The private tier. Some data can’t leave your environment: regulated data, customer PII, sensitive IP. This layer runs open-weight models on developer laptops or on a shared server inside your network. Be realistic about it. Local models are good for restricted-data work, embeddings, redaction, and offline use. They are not yet a replacement for frontier models on complex agentic tasks, and hardware alone won’t justify the investment. Treat this as your data-sovereignty tier, not a cost-cutting strategy. I learned this in my own lab. The local models I run handle private, everyday work well, but I still reach for frontier models when the task is hard.

5. The context layer. AI is only as useful as what it knows about your environment. This layer connects your tools to your systems: ticketing, wikis, API catalogs, database schemas, ERP metadata. Two practices matter here. First, adopt open standards like the Model Context Protocol (MCP) so every tool can reach the same context the same way, instead of wiring each one separately. Second, put a plain-text instruction file (such as AGENTS.md) in every code repository, describing how to build, test, and work in that codebase. Most major coding tools now read it, which means your investment in context survives any vendor switch.

6. The system of record. Every piece of AI-generated code should land in the same place and go through the same checks as human code: a pull request, automated tests, security scanning, and human approval. For most of us, that’s our source control platform. This is the most important layer for governance, because it’s tool-agnostic by design. It doesn’t matter which assistant wrote the change. What matters is that it was reviewed, tested, and traceable.

7. The control plane. This layer sits underneath everything: identity and provisioning, device management, a data classification policy, an LLM gateway for API access, audit logging, and cost tracking. It’s the least exciting layer and the one that determines whether you can scale safely.

Tool options by layer

I promised this wouldn’t be a tool article, but a reference helps. Every layer has credible options across the major ecosystems:

• Everyday assistant: ChatGPT Enterprise, Claude for Enterprise, Gemini for Workspace, Microsoft 365 Copilot

• Interactive development: GitHub Copilot in VS Code, Cursor, Windsurf, JetBrains AI, Gemini Code Assist

• Delegated development: OpenAI Codex, Claude Code, GitHub Copilot coding agent, Google Jules

• Private tier: Ollama or LM Studio on laptops; vLLM on a shared server; open models from the Qwen, Llama, Gemma, Mistral, and gpt-oss families

• Context layer: MCP servers for your systems and AGENTS.md in each repo

• System of record: GitHub, GitLab, Azure DevOps, Bitbucket

• Control plane: Your existing IdP and MDM; LLM gateways such as LiteLLM, Portkey, or a cloud provider's equivalent

Notice that the layers with the longest shelf life (context, system of record, control plane) are the ones built on open standards and platforms you likely already own. The layers with the shortest shelf life are the model-facing ones. Invest your effort accordingly.

The one policy that unlocks adoption

If you do only one thing this quarter, publish a one-page data classification policy that maps data types to tools. For example:

• Public and internal data can be used with any approved tool.

• Confidential data (source code, designs, customer-adjacent information) stays in enterprise tenants with verified no-training and retention terms.

• Restricted data (regulated, PII, M&A) stays on the private tier only.

This single table resolves most “am I allowed to use this?” questions. In my experience, ambiguity is the biggest adoption killer. People who aren’t sure they’re allowed will simply not use the tools, and the ones who use them anyway will do it in ways you can’t see.

How to get your team there

The architecture is the easy part. Getting a team from occasional experimentation to daily use takes a deliberate plan. Here’s the sequence I recommend.

Phase 0: Make it safe and clear (first month). Stand up the control plane: single sign-on on every tool, the data policy, device management, and branch protections plus security scanning on your repositories. Name an executive sponsor and a small group of champions. Choose respected practitioners, not just the enthusiasts. Then have leadership say out loud why you’re doing this. Address the job question directly. If you’re silent on it, people fill the silence with their own fears, and that shows up as quiet resistance.

Phase 1: Prove it with lighthouse projects (months 2–3). Champions go deep on two or three real use cases with clear value and low risk: writing tests for legacy code, documenting undocumented modules, running a framework upgrade, analyzing a messy interface spec. Measure before and after. You need your own numbers, not vendor claims. Champions also write the instruction files for their teams’ key repositories, which is what makes AI output match your standards instead of generic code.

Phase 2: Roll out in waves (months 3–5). One or two teams at a time, each led by its champion. Train by role rather than generically. Developers need different skills (writing good task specs, reviewing AI-generated code) than business analysts (requirements, test scenarios, documentation) or managers (reading adoption data and modeling usage themselves). The most effective format I know is a weekly 30-minute “show your workflow” session where practitioners share their actual screens. Peer demos convert skeptics far better than formal training.

Phase 3: Embed it in how you work (months 6–12). AI stops being optional and becomes part of the process. Delegated agents own the test and tech-debt backlogs. Every pull request gets an AI first-pass review. Story templates include an agent-ready specification. And a small enablement team, drawn from your champions, owns the tooling, patterns, and metrics as a product.

What to measure (and what not to)

Skip lines of code and suggestion acceptance rates. They’re easy to count and tell you very little. Instead, track:

• Adoption: weekly active users by tool and team.

• Flow: pull request cycle time and lead time for changes.

• Quality: change failure rate and defect escapes, especially on AI-authored changes.

• Cost: spend per active user.

• Sentiment: whether your people actually find it useful.

If cycle time drops and quality holds, you’re winning. If usage is high but quality slips, your review process is the bottleneck, and that’s the next thing to fix.

Four things I’d tell a peer over coffee

First, build something yourself. My most valuable AI education didn’t come from vendor briefings. It came from building things in my own lab, and I’d encourage every IT leader to do the same, even on a small scale.

Second, protect learning time. Asking people to adopt new ways of working on top of a full delivery load is the most common reason these programs stall. Ten percent of their time for the first 90 days is a small price.

Third, lead visibly. If managers still write status reports by hand, the team hears that AI is optional, whatever the strategy deck says.

Fourth, set honest expectations. AI is excellent at tests, boilerplate, documentation, and upgrades. It’s weaker on complex business logic and on the customizations that make your systems yours. Say that up front, start where it shines, and you avoid the “I tried it and it was wrong” dismissal that can set a team back months.

The bottom line

The companies that get real leverage from AI won’t be the ones that picked the best model in 2026. They’ll be the ones that built the structure to absorb whatever comes next: clear rules on data, a single place where all AI work lands and gets checked, shared context that any tool can use, and a team that knows how to work this way. Tools will change. That foundation won’t.

I’d love to hear how others are approaching this. What’s working in your organization, and where are you stuck?

Subscribe now