# Governed enterprise AI reference architecture Version: 1.0 — 29 September 2026 Publisher: IgniteX Solutions Scope: vendor-neutral design aid for governed operational AI This reference architecture is for teams designing AI that can investigate, recommend and act inside enterprise workflows. It separates business ownership, agent reasoning, authority, execution and evidence so that changing a model or adding another agent does not silently change who may act. It is a design and evaluation aid, not proof of an IgniteX deployment, security certification or customer outcome. Adapt it to the organisation's systems, risks and regulatory duties. ## 1. Begin with a mission contract A mission contract defines the bounded unit of work before an agent receives tools: - Business objective and accountable owner - Requester identity and permitted purpose - Starting state, completion condition and maximum duration - Approved knowledge sources and data classifications - Allowed, prohibited and approval-gated actions - Human escalation and exception owner - Outcome verification method - Evidence and retention requirements The contract should survive a change of model or agent implementation. A prompt is not a substitute for this contract. ## 2. Architecture boundaries ### A. Request and identity boundary Authenticate the requester and preserve the business purpose, tenant, role and delegation context. Do not infer authority from natural-language instructions. Verify that the system distinguishes people, service accounts and agent identities; scopes delegated authority with an expiry; and carries tenant and environment boundaries through every tool call. ### B. Mission state and orchestration boundary Keep durable mission state outside the model. Record the current step, owner, evidence, unresolved questions, approvals, retries and next permitted action. Use deterministic workflow logic where model judgment is unnecessary. Verify what happens when an agent, model or worker stops; whether work can resume without repeating a consequential action; and whether one mission remains correlated across tickets, agents, approvals and tools. ### C. Knowledge and data boundary Retrieve only from sources the requester and mission may access. Preserve source identity, version or timestamp where decisions depend on freshness. Treat retrieved text as data, not authority to expand tool permissions. Verify that source permissions remain effective after retrieval, operators can inspect supporting sources, and untrusted content cannot change policy or tool scope. ### D. Agent and model boundary Agents may classify, investigate, compare evidence and prepare proposals. Their output is untrusted until it passes the controls appropriate to the action. Model choice, prompt version and relevant configuration should be traceable for reproducibility. Verify that recommendation is separate from execution authority, deterministic checks can reject unsafe proposals, and the model can change without losing mission state or authority rules. ### E. Policy and approval boundary Evaluate identity, action, target, environment, data and current mission state before execution. Bind a human approval to the exact proposal or an immutable digest, define its expiry and re-evaluate it if the proposal changes. Verify that permission to prepare remains distinct from permission to apply, expired or revoked approval is rejected, and high-risk work can require separation of duties. ### F. Tool gateway and execution boundary Expose narrow operations rather than unrestricted credentials or general shells. Validate arguments, enforce resource scope, apply idempotency controls where supported and redact secrets from prompts and evidence. Verify that tool identities have least privilege, target environment and resource identifiers are explicit, and credentials can be rotated or revoked without rebuilding the agent. ### G. Verification and reconciliation boundary A successful tool response is not the business outcome. Check the authoritative system after execution. If the response is lost, reconcile target state before retrying; when duplicate execution cannot be prevented safely, stop and escalate. Verify the independent signal that proves the outcome, how partial or delayed results are handled, and whether retry behaviour is bounded and visible. ### H. Human operations boundary Provide an operator queue showing mission state, evidence, required decision, deadline and safe next actions. A human handoff should transfer context and responsibility, not only send a notification. Verify that an operator can pause, reject, redirect or take over work; the accountable owner is clear when automation stops; and emergency stop and recovery procedures are tested. ### I. Evidence and assurance boundary Retain a reconstructable record of what was requested, permitted, proposed, approved, executed and verified. Apply access controls, minimisation and retention limits; do not turn the audit trail into a second uncontrolled data store. Minimum record: - Mission and correlation identifiers - Requester, agent, policy and approver identities - Source references and relevant versions - Proposed action with sensitive arguments redacted - Policy decision and approval scope/expiry - Execution result, retries and target-system reference - Independent outcome check, exception owner and recovery status ## 3. Control flow 1. Accept an authenticated request and create a mission contract. 2. Retrieve permitted context with source evidence. 3. Let an agent investigate or prepare a proposed action. 4. Validate the proposal against deterministic rules and current policy. 5. Obtain a human decision when the action class requires it. 6. Re-check scope, target, state and approval immediately before execution. 7. Execute through a constrained tool identity. 8. Verify the business outcome in the authoritative system. 9. Close, escalate or reconcile the mission and preserve the evidence. ## 4. Framework versus enterprise platform An AI agent orchestration framework commonly helps developers define state, routing, tools and agent behaviour. An enterprise autonomous orchestration platform must also operate the surrounding responsibilities: business ownership, identity, policy, approvals, durable queues, recovery, evidence, change control and service operations. These layers can use more than one product. The evaluation question is not whether one tool claims every feature; it is whether the whole deployed architecture has an explicit owner and tested behaviour for every boundary. ## 5. Multi-agent design rule Use multiple agents only when the separation creates a measurable benefit such as distinct expertise, independent checking or ownership boundaries. For every handoff record the input and permitted context, output schema and uncertainty, unresolved questions, authority retained or transferred, and timeout/failure owner. Test repeated work, conflicting recommendations, stale context and a failed agent. A multi-agent diagram without failure and authority behaviour is not an operating architecture. ## 6. Deployment review Map the application, model endpoints, retrieval stores, policy engine, identity provider, tool gateway, queues, evidence store, telemetry, backups and operator interfaces. For each component record: - Hosting and data location - Data sent and retained - Authentication and network path - Availability and recovery responsibility - Version/change owner - Exit and portability method Private application hosting does not automatically mean every model call, support path or telemetry flow stays inside the same environment. ## 7. First pilot evidence Before expanding autonomy, run representative positive and negative cases: 1. Authorized action completes and the business outcome is independently verified. 2. Requester lacks scope; no target change occurs and denial is recorded. 3. Proposal changes after approval; a fresh decision is required. 4. Approval expires or authority is revoked before execution. 5. Retrieved content attempts to change instructions or tool scope. 6. Tool response is lost; reconciliation occurs before any retry. 7. Tool reports success but target state is unchanged. 8. Agent or worker fails mid-mission; the operator receives usable context. Use synthetic or redacted records until data handling and publication permissions are established. ## 8. Ownership matrix Assign named roles for the business outcome, workflow/product, data, identity/access, AI/model, policy/risk, integration/tool, human approval, operations/incident response and evidence assurance. One person may hold multiple roles in a small pilot, but the responsibilities should remain explicit. ## 9. What this architecture does not prove The document does not prove that a product is secure, compliant, production-ready or accurate. Evidence must come from the actual configured environment, representative tests, observed outcomes and accountable acceptance. Related IgniteX resources: - EAO platform: https://www.ignitexsolutions.com/eao - Enterprise AI governance: https://www.ignitexsolutions.com/enterprise-ai-governance - Governed AI acceptance tests: https://www.ignitexsolutions.com/resources/governed-ai-acceptance-tests.md - Pilot evidence scorecard: https://www.ignitexsolutions.com/resources/governed-ai-pilot-scorecard.csv