Enterprise agent architecture

Enterprise AI Agent Architecture for Governed Production

Enterprise AI agent architecture places models inside a governed workflow system. The architecture maintains durable task state, retrieves company-specific knowledge, invokes constrained tools, applies identity and permissions, routes human approvals, evaluates decisions and actions, records evidence, handles failure, and supports controlled production changes. Each layer has a distinct responsibility and should be testable.

Written and reviewed by Arcta · Published August 6, 2026 · Reviewed August 6, 2026

Architecture begins with responsibility

An enterprise agent is not simply a model connected to several APIs. It is a workflow system in which different layers control context, reasoning, state, action, authority, evaluation, and operation.

Clear separation makes the system safer and easier to improve. A model problem can be addressed without rewriting permissions. A knowledge update can be evaluated without changing integration code. A failed external action can be retried without asking the model to reconstruct the entire task.

The correct architecture is the smallest one that can complete the bounded outcome dependably.

Reference flow

The typical flow is:

  1. An event or user creates a task.
  2. Intake validates identity, scope, and required input.
  3. The orchestrator reads durable workflow state.
  4. The knowledge layer supplies permitted, relevant company context.
  5. A model or deterministic component selects or performs the next decision.
  6. Tool interfaces validate and execute approved actions.
  7. Human review occurs where authority requires it.
  8. Results update workflow state and completion evidence.
  9. Evaluations and monitoring assess quality, control, and operation.
  10. Approved learning changes knowledge or workflow behavior through a tested release.

The steps may repeat, but the system should always be able to identify the current state and accountable next transition.

Intake and task identity

The workflow needs a stable task or case identifier. Intake validates required fields, normalizes source events, associates the correct tenant or organizational boundary, and records who or what initiated the work.

Missing inputs should produce an explicit state. The agent should not invent identifiers or silently cross a tenant boundary to make the task appear complete.

Durable workflow state

State belongs outside the model context. It records received evidence, completed checks, pending approvals, tool outcomes, retries, exceptions, and final disposition.

Durable state enables asynchronous work and human review. It also supports idempotency: if the same event arrives again, the system can determine whether an action already occurred rather than repeating it.

Orchestration

The orchestrator determines which steps are available from the current state. Some transitions are deterministic. Others may ask a model to classify, plan, extract, or apply contextual criteria.

Keep orchestration legible. Multi-agent designs are useful only when separate roles or parallel work provide a clear benefit. Additional agents introduce coordination, context, evaluation, and failure complexity.

Models

Models should have defined responsibilities and evaluated inputs and outputs. One workflow may use a model for extraction, another for synthesis, and another for applying criteria to evidence. The model should not own permissions or treat a proposed action as proof that the action occurred.

Separating model choice from company knowledge and workflow state makes it easier to compare providers, manage version changes, and prevent operating memory from being trapped in one model-specific prompt.

Governed knowledge

The knowledge layer supplies definitions, policies, precedents, exceptions, accepted examples, and source records relevant to the current state. Retrieval may combine structured queries, keyword search, vector search, relationship traversal, or explicit rules.

The key requirements are authority, relevance, access control, provenance, and update ownership. The AI knowledge-base guide explains why retrieval alone does not satisfy all five.

Tools and action interfaces

Tools should be narrow, typed, and observable. The application validates tool inputs, current state, identity, permission, and action policy before execution. It records the downstream response and distinguishes success, failure, timeout, and unknown outcome.

For consequential operations, separate preparation from execution. The agent can prepare an action payload while an approval service or deterministic policy controls whether the write occurs.

Identity, permissions, and secrets

The architecture must define whether the agent acts with the requesting user’s permissions, a constrained service identity, or a dedicated delegated role. Context retrieval and tool access should use the same organizational boundaries.

Secrets remain in managed infrastructure and should not be placed into model context. Logs and evaluation records should avoid unnecessary sensitive data while preserving enough evidence for diagnosis.

Human approval and escalation

Human review is an architectural component. The system creates an approval request with the proposed decision or action, relevant evidence, uncertainty, and allowed responses. The workflow then waits in a durable state.

Rejection, revision, timeout, and unavailable approver paths should be defined. Novel cases can route to an accountable expert, whose approved resolution may later become governed knowledge.

Evaluation and observability

Evaluation tests representative workflows and critical boundaries before launch. Production monitoring observes completion, quality, escalations, review effort, tool failures, and changes in behavior.

The NIST AI Risk Management Framework emphasizes incorporating trustworthiness considerations across design, development, use, and evaluation. Agent architecture operationalizes that lifecycle by connecting evaluations to versioned models, knowledge, tools, and workflow releases.

Managed production change

Models, prompts, knowledge, integrations, policies, and source data can all change. The architecture should record versions, run regression evaluations, support controlled rollout, and retain a rollback path for material changes.

An operating owner reviews incidents and value, not only system uptime. A workflow that remains available but requires steadily increasing human correction is degrading operationally.

How Arcta maps the architecture

Canon supplies governed company knowledge. Refinery turns approved operating evidence into updates. Compiler coordinates state, models, tools, permissions, and people. Crucible provides evaluation, release gates, and failure diagnosis.

These concepts preserve the separation between what the company knows, how the agent performs work, and how the organization decides that behavior is acceptable.

Questions and answers

Frequently asked questions

What are the main layers of enterprise AI agent architecture?

Core layers include intake, durable workflow state, orchestration, models, governed knowledge, constrained tools, identity and permissions, approvals, evaluation, observability, and managed operation.

Does an enterprise agent require multiple agents?

No. Begin with the simplest architecture that completes the workflow. A single agent or explicit workflow is often easier to evaluate and govern than an unnecessary multi-agent system.

Where should workflow state be stored?

State should live in a durable system designed for the task rather than only in model context, so work can resume, transitions can be inspected, and duplicate actions can be prevented.

How should models and tools be separated?

Models can propose reasoning or tool use, while deterministic application code validates inputs, permissions, state transitions, action execution, and confirmation of downstream results.

How does evaluation fit into the architecture?

Evaluation is a production layer connected to versioned models, knowledge, prompts, tools, and workflows. It gates changes and turns observed failures into reproducible regression cases.

A bounded place to start

Find the first workflow worth delegating.

Bring the work that slows down, gets reworked, or depends on a few people. Arcta will define a measurable starting point.

Talk with Arcta