Enterprise AI Agent Architecture: Build the Control Plane Before the Agent

Enterprise AI agents fail in production not because teams pick the wrong framework, but because they build agents as standalone applications instead of governed digital workers running on a shared control plane that owns identity, scoped tools, approvals, and audit before the first agent ships. The frameworks are fine. The orchestration patterns are fine. What kills the rollout is that every app invents its own login, its own keys, its own memory, and its own audit trail — and then someone in security asks a question nobody can answer.

An agent without a permission engine, tool gateway, and tiered approval model is a privilege escalation incident waiting for a postmortem. The enterprises shipping agents in production are not the ones with the cleverest planner. They are the ones who built identity, scopes, a tool gateway, and audit first, and only then let an agent touch a tool.

The real architecture is not the agent — it is the control plane underneath it

Every enterprise agent guide opens with the same component list: a model for reasoning, tools for external functions, instructions that define behavior ^[1]. Correct, and dangerously incomplete, because it describes one agent in isolation. The enterprise unit of design is not an agent. It is the layer underneath every agent.

Call it the Agent Control Plane. It owns tenants, human identities, agent service identities, the scope catalog, the tool registry with its credentials, the permission engine, the approval workflow state machine, scoped memory, and the audit log. Every app — accounting, ledger, margin, marketing, energy forecasting — plugs into the same control plane. Every agent runs on top of it. Salesforce frames the agentic enterprise as a multi-year IT architecture transformation precisely because traditional enterprise architecture supports only sub-scale agent deployments, not widespread agents reasoning and acting across systems ^[3].

If you cannot draw that diagram for your stack today, you are not building enterprise agents. You are building demos that will collide the moment a second team ships.

Stop giving agents their own logins

Agents are not people. They should never have human-style logins, permanent master API keys, or autonomous principals that outlive the request. Agents run as scoped service identities inside the human user's active session, and the effective permission for any action is computed as an intersection: human permission ∩ agent permission ∩ tenant policy ∩ tool or data scope. If any of those four says no, the action does not happen. This is the rule that prevents the marketer from extracting payroll data through an over-eager accounting agent.

The authentication patterns split cleanly. Humans use OIDC, SSO, and session tokens. Internal agents and services use short-lived service tokens, scoped API keys, and signed internal requests, with mTLS where the trust boundary demands it. Third-party integrations use OAuth where available and tenant-scoped connector credentials stored in a vault — never long-lived master keys baked into a config file. The control plane issues, rotates, and revokes everything.

Explicit state machines and human-in-the-loop checkpoints are what make agent behavior auditable when agents touch expenses, production data, or customer communication ^[4]. That predictability starts with identity. If you cannot answer which human, which agent, which tenant, and which scope authorized a tool call — in that order — you do not have governance. You have hope.

The tool gateway is where governance actually happens

Direct agent-to-database connections are the production failure mode the field refuses to discuss. Agents do not call Stripe directly. Agents do not query the ledger directly. Agents do not hit Gmail, the marketing platform, or the accounting system directly. Every tool call routes through a gateway that enforces permission checks, tenant isolation, input validation, output filtering, rate limits, secret isolation, approval checks, and structured logging — before any side effect occurs.

Memory is not a global blob either. It is tenant memory, user memory, agent memory, workflow memory, and document memory, each scoped and entitlement-aware. If a user cannot read payroll, the retrieval layer must not surface payroll-adjacent embeddings to an agent acting in that user's session. The gateway enforces this, because the alternative — trusting each agent to self-police — is not a control. It is a wish.

Building this once, centrally, is what lets an enterprise add the third, fifth, and tenth agent without re-litigating security every time. Building it per app is how organizations end up with three accounting agents, four secret stores, and a compliance team that has stopped returning calls.

Risk-tier every action before you write a prompt

Read public market data and transfer funds cannot share an approval policy. Assign every action in your tool catalog a risk level from 0 to 5. Level 0 is reading public data. Level 1 is reading internal data. Level 2 is drafting or calculating. Level 3 is writing internal records. Level 4 is publishing, emailing, submitting, or notifying external parties. Level 5 is moving money, changing legal records, deleting data, or executing trades.

Bind each level to a specific human-in-the-loop rule. Levels 0 and 1 run with logging. Level 2 runs with logging plus confidence metadata. Level 3 is restricted to specific roles and specific agents. Level 4 requires explicit human approval before execution. Level 5 requires dual control or is hard-blocked for agents entirely. Agents that approve expenses, modify production data, or communicate with customers need human review before critical actions, and explicit state machines are how you make that auditable ^[4].

Approval state itself must be a first-class object: drafted, review_requested, approved, rejected, executed, cancelled. The marketing agent drafts a campaign and a human approves before the platform publishes. The margin agent proposes price changes and finance approves before pricing updates. The energy agent flags a battery arbitrage opportunity and a human approves before execution. The agent prepares. The human authorizes. The platform executes. The audit log records all three.

Use deterministic services for math, agents for reasoning

The LLM is not the source of truth for ledger balances, margin calculations, forecasts, or anything else where being wrong has a number attached. Margin formulas live in a deterministic service. Ledger posting rules live in a deterministic service with validations. Forecast model training lives in a statistical or ML service with versioned inputs and recorded assumptions. The agent coordinates those tools, explains the result, classifies exceptions, and drafts the next step.

The right division of labor in a margin workflow is concrete. The agent receives the request and the control plane checks permissions. The agent calls ledger reads, invoice reads, and product cost reads through the tool gateway. A deterministic margin service performs the calculation. The agent explains the drivers and proposes price changes. Proposed changes enter the approval workflow. The audit log records every tool call, every permission decision, and every approval state transition. At no point does the model produce the number that a CFO will sign off on.

This split also kills the temptation to over-architect. Maximize a single agent's capabilities first; additional agents create complexity and overhead, and a single agent with tools is often sufficient until workflows become genuinely too complex or tool selection fails ^[1]. Most of what teams reach for multi-agent systems to solve is actually solved by adding a deterministic service behind a well-scoped tool.

Start with one agent and excellent governance, not a multi-agent constellation

The pragmatic build sequence is not glamorous and that is the point. First, shared tenant and user identity. Then the agent registry. Then the scope-based permission engine. Then the tool gateway. Then the audit log. Then agent run history. Then the approval workflow. Then the connector registry. Then the memory service. Then evaluation and monitoring. Only after that do you ship the first one or two high-value agents — a margin agent and an accounting agent are good candidates because the value is measurable and the deterministic services already exist.

The order matters. Teams that invert it — pick a framework, build an agent, then retrofit governance — are the teams whose pilots never reach production ^[2].

Split into multi-agent systems only when a single agent's tool selection genuinely fails: when the prompt is doing too much work, when tool descriptions are colliding, when one agent's context window is exhausted by capabilities it rarely uses. Until then, one agent with ten well-scoped tools beats five agents with their own memory, their own keys, and their own opinions about how to call Stripe.

Sovereignty is an architectural choice, not a compliance checkbox

Once the control plane owns identity, secrets, memory, and audit for every autonomous write, the question of where the model runs stops being an infrastructure preference and becomes a governance question. Every prompt sent to a cloud LLM API contains the inputs the control plane just authorized — ledger excerpts, invoice contents, customer records, energy contracts, internal policy documents — plus, often, the tool schemas that describe what the agent is allowed to do. Sending those writes through a third-party API turns the model provider into the largest unmanaged blast radius in your stack.

Interoperability standards like Model Context Protocol and Agent2Agent matter ^[3], but interoperability without sovereignty just means more endpoints sharing your data. For regulated workloads — finance, energy, healthcare, anything under GDPR — the answer is local GPU inference on open-weight models, running on infrastructure the customer controls, with the same control plane governing both the agent and the model.

This is what Wavenetic builds. WaveNode hardware, the runtime, open-weight models, the application layer, RAG with citation tracking, and European support as a single on-premise, air-gapped stack. Audit trails and GDPR-aligned deployment are not features bolted on for compliance — they are the same control plane the architecture demanded in the first place. Pick the framework last. The enterprises that ship agents in production are the ones that built the control plane first. The ones still stuck in pilot are the ones who let each app invent its own login, its own keys, and its own audit trail.

Book a technical review of your agent control plane with our team — https://wavenetic.com