Designing Agentic AI
for the Enterprise

From a convincing proposal to reliable action

An AI agent can read a report, recognize connections and suggest a next step. As soon as that suggestion is meant to change something in a business, some familiar questions become relevant: Which version of the data applies? Which rule should be used? Who is responsible? And who is actually allowed to initiate the change?

The agent may answer these questions in impeccable English. The system of record is generally unmoved by its eloquence. It needs valid inputs, appropriate permissions and a precisely defined action. This is where enterprise architecture—the design of the relationships between business, data and IT—becomes concrete for agentic AI. Here, an AI agent combines a language model with tools and software capable of carrying out several steps. The language model, often called an LLM, short for large language model, interprets the request. The surrounding architecture must determine which action may follow.

My recommendation is to design enterprise knowledge, decisions and execution as one connected system. The knowledge base describes the things the business talks about and connects them to their sources. The decision architecture assigns tasks to appropriate mechanisms: code calculates defined values, rules check explicit conditions, and LLMs interpret language and develop proposals. The execution architecture ensures that an authorized action takes effect under the right conditions.

The agent runtime is the software that brings these contributions together while a request is being processed. It maintains the request across steps, retrieves context, assigns work to components and processes their results. This makes it possible to trace how information leads to a decision and how a decision leads to a confirmed action.

If you are responsible for enterprise architecture, data, platforms or business applications, this design should help you structure a use case of your own. Which sources does it need? Which decisions belong in code, rules or human review? And which guarantees must the technical execution provide? The outcome is a scoped architecture brief with named deliverables. The introduction and knowledge model establish the business question; the clearly marked technical details that follow explain the runtime, action contract and resumption of work.

This whitepaper develops that connection from the business knowledge model to an outline of a technical runtime. The components and contracts presented here are an architecture proposal, not a platform that has already been implemented or tested. It starts with a requirement that can seem self-evident: everyone involved needs to know what they are talking about.

Connecting enterprise knowledge to its sources

An organization's knowledge is spread across business documents, databases, applications and the people who understand their particular quirks. An agent needs access to these relationships. It must be able to recognize which terms mean the same thing, which data belongs together and which source is authoritative for a particular question. The following building blocks contribute different parts; none replaces the others.

A glossary explains terms; a taxonomy organizes them into categories. An ontology describes business objects and their domain relationships, such as how a contract, a risk and an event relate. A knowledge graph records concrete objects and known connections. A contract object can, for example, refer to its documents, the responsible business unit and the authoritative record. The conceptual model and the concrete data remain distinct.

Stable identifiers—references that can be matched across systems—connect these views. A system of record holds the authoritative record or performs the authoritative transaction within its area of responsibility. For each request, it must be clear which source is authoritative for which claim. Access to documents and data remains limited to the permitted context; putting them in a graph does not extend anyone's permissions.

This establishes meaning. Whether a statement is valid today still needs to be checked against its sources. Information relevant to a decision therefore needs an owner, a business validity period and a retrieval time as part of its context. Observed facts, estimates, hypotheses and contradictions remain distinguishable. An agent's conjecture acquires a different status only through a review process with accountable ownership.

Different standards are available for implementation. SKOS supports knowledge organization systems; OWL supports formal ontologies. SHACL describes testable constraints on data in the RDF graph model, such as required properties and permitted values. Passing a structural check does not establish business truth. Which of these means you need depends on the use case and your existing systems.

This defines what the work may rely on. The next architecture task is to use that knowledge appropriately for the decision at hand.

Assigning work to code, rules and LLMs

Calculating a deadline, applying a rule and interpreting a contradictory document are different tasks. A sound decision architecture makes those differences explicit. Each component can then be used where its result can be meaningfully checked.

Decision Model and Notation, or DMN, is a standard for modeling business decisions, including through decision tables. A rule can check an explicitly defined condition. A language model may first identify a matter in a document that needs review. Defined code is suitable for the subsequent calculation. The architecture determines how these contributions fit together and where their results must be confirmed.

An LLM result becomes binding for the business only after the prescribed review and authorization. How convincingly it is written does not settle that question. Even a correctly evaluated rule produces the intended decision only if the rule version and inputs are appropriate.

Alongside the business decision comes the question of whether the specific action is permitted. Here, a policy is a machine-evaluable requirement concerning authority and conditions. A policy engine uses structured information to decide whether that requirement is met; the executing service enforces the decision. Open Policy Agent separates these responsibilities accordingly.

Consequences matter too. Jeff Bezos distinguishes readily reversible Type 2 decisions from Type 1 decisions that are difficult to reverse. This dimension helps determine the review required. On its own, it does not determine which tool may contribute to preparing a decision.

In the design below, human approvals depend on business responsibility, uncertainty and possible consequences. An approval applies to a specific action under specific conditions. Together with the knowledge model, this leads to the overall architecture.

How knowledge, orchestration and business systems work together

Knowledge, decision mechanisms and executing systems need to refer to one another. Figure 1 organizes their logical responsibilities. Read it from top to bottom: a business request uses the shared knowledge base; orchestration coordinates the work and selects appropriate mechanisms; the specific action is checked before a change takes effect. The business system then confirms the result. Products, network paths and the distribution across individual services remain open.

The arrows show this logical relationship. They are not network connections and do not describe security boundaries that have already been established. The bottom row names responsibilities that apply across all layers: security and accountable data stewardship, information provenance, versioning, operational monitoring and controlled evolution.

Shared meaning connects the layers. When a business rule changes, its impact on the agent's context, rule evaluation and affected actions must be assessed. Enterprise architecture makes those relationships traceable. Business owners are accountable for the content; engineering and operations implement and operate the technical mechanisms.

Related building blocks appear in Palantir's ontology architecture and the AWS guidance on agentic enterprise architecture. Their combination in this illustration is my own reference design. Similarity between individual components does not establish an identical implementation or demonstrate the effectiveness of the overall design. The following runtime sketch explains how the roles are intended to work together during a request.

How the runtime carries a request across steps

Technical detail

Components and their responsibilities

A request and its result are often separated by several steps, follow-up questions and waiting periods. The runtime must preserve that continuity. Here, a run is the processing of one request, with its own identifier and persisted state. It may include many model and tool calls and last longer than any individual call.

The following names identify roles in the design. They prescribe neither products nor a separate service for every box. Existing workflow, integration or application services can take on several of these responsibilities, provided the necessary guarantees remain verifiable.

An Action Intent describes the intended change, including its target, inputs and execution context. A tool adapter translates the authorized request into a call to the relevant application programming interface, or API. Using these roles, Figure 2 shows how a run is intended to reach a confirmed action.

Solid arrows show work requests and returns; dashed arrows show approvals or evidence of results. Context retrieval and persisted processing state are available to the Orchestrator as separate responsibilities. The return path on the right attaches confirmation from the business system to the request. An approval received later can trigger further processing through a continuation event; it does not execute the action itself.

The highlighted gateway boundary is an implementation requirement: tool calls that write data must pass through this check. Workers must therefore have no equivalent write access that bypasses it. How permissions, runtime isolation and interfaces actually enforce this boundary must be demonstrated in the concrete technical design. The sequence within these roles can now be followed step by step.

From a request to the next confirmed step

An agent needs room to find a useful next step. The runtime needs clear conditions for allowing that step. The Orchestrator connects the two in a recurring cycle and controls its transitions outside the LLM.

1. Bind the request. The Run Manager authenticates the caller and determines the delegated authority. The objective, budget and stopping conditions share a common reference through the run ID.
2. Take ownership of the state. The Orchestrator takes a new or resumable request from the queue. An exclusive processing claim and version-checked state changes are intended to prevent competing updates to the same run. The implementation must also prevent a stale worker from writing further valid changes after losing its claim.
3. Retrieve context. The Context Builder reads permitted business objects and sources. Data versions, provenance and open questions accompany the assignment.
4. Determine the next step. An LLM, rule component or code returns a structured result. The runtime checks its schema, business conditions and permitted scope.
5. Execute or wait. Read-only tools operate in the run's access context. A write action produces an Action Intent. If information or approval is missing, the runtime durably records the waiting state.
6. Authorize the action. The gateway checks the specific intent against current authority, rules and any required approval. Changed parameters or relevant data versions require another check.
7. Confirm the result. The adapter reports success or failure. If the outcome remains unknown, reconciliation with the target system begins. Only a confirmed result changes the known execution state.
8. Continue or finish. The Orchestrator checks the objective and limits. A further step requires remaining budget and a permitted state transition.

The LLM develops its proposals within this framework. The runtime controls step counts, deadlines, costs and termination. As soon as a proposal is to trigger an authoritative change, it needs an unambiguous description. That is the purpose of the action contract.

The action contract specifies the target, inputs and approval

Technical detail

Understanding the fields of the action contract

“Take the next sensible step” is hardly sufficient as an instruction to a business system. It must be clear which action is to change which object, using which inputs. An Action Intent records these details together with the execution context. The following JSON—JavaScript Object Notation, a structured data format—outlines that contract. It contains illustrative values and placeholders. It is neither a complete interface schema nor an executable implementation.

{
  "runId": "run-17",
  "subjectRef": "actor-12",
  "delegationRef": "delegation-4",
  "actionId": "action-7",
  "targetRef": "record-42",
  "expectedVersion": "v19",
  "inputRef": "input-3",
  "inputHash": "sha256:…",
  "policyRevision": "policy-6",
  "approvalRef": null,
  "idempotencyKey": "record-42:action-7",
  "status": "PROPOSED"
}

In this example, proposed action action-7 belongs to run run-17 and concerns record-42. Its inputs are referenced by input-3; they are not written out here. PROPOSED means the action has been proposed. It does not establish that execution has occurred. The field names bring together the following questions:

In the example, actionId assumes an unambiguous mapping to a registered action. A real interface schema must also define how the action type, parameter structure and permitted target objects are determined. The shortened value sha256:… is not an actual hash. The idempotency key is also illustrative: different business actions must not accidentally receive the same key.

The agent proposes the action and supplies its business reasoning. Trusted runtime components add the verified caller context, authority references and evidence. A permission the model awards itself has roughly the evidentiary value of a power of attorney it signed for itself.

An approval binds the action, inputs, target and relevant versions. If any of these changes, the earlier approval is no longer sufficient. Immediately before the change takes effect, the target system checks the applicable conditions and versions within the transaction. A prior gateway check alone cannot rule out intervening changes.

The Model Context Protocol, or MCP, describes, among other things, how tools expose input schemas and, where applicable, output schemas. These descriptions help callers use tools correctly. For the action contract proposed here, the participating services must additionally enforce identity, approval binding and a confirmed result.

Enforcement therefore remains an architecture responsibility. The time that may pass between proposal and execution leads to the next requirement: the request must survive an interruption.

Persisting requests, reconciling unknown outcomes and resuming work

Technical detail

Persisted state and resumption

An approval may arrive long after the original model call has ended. A service may have made a change even though its response never arrives. In both situations, the runtime needs persisted state from which a permitted continuation can be determined.

These states are a design proposal for the run. Individual actions have their own progression from proposal through checking and dispatch to confirmation. UNKNOWN denotes an unresolved outcome after dispatch. A timeout initially confirms that a response is missing. It is remarkably restrained on the question of whether the action succeeded.

When an approval arrives later, the runtime loads the persisted action and rechecks its validity, unchanged parameters and current decision context. A persisted history makes resumption possible; earlier permissions must still be valid.

A retry of the same logical action should not cause an additional business effect. This property is called idempotency. The design uses the same idempotency key for the same action; a new business request receives its own mapping. The executing service must recognize duplicate calls; the target system must reliably prevent additional business effects on repetition. The key alone does not create this property. The Temporal documentation on Activities explains this relationship too. A persisted workflow alone does not guarantee a single business effect in arbitrary external systems.

If an outcome can neither be established nor safely retried, the action remains on hold for review. Stopping a run does not undo a business effect that has already been confirmed. A compensation, such as a permissible reversing entry, is a separate action requiring fresh authorization. These limits belong in the runtime design and must be verifiable in operation.

Checking execution through controls and evidence

The architecture's quality becomes visible at its transitions: from request to context, from proposal to approval, and from execution to a confirmed result. For each transition, it must be clear which condition applies and what happens when it is missing.

The evidence connects the run to its task, sources and data versions, model and template versions, rules, policies, approvals and tool calls. It records the confirmed result with a reviewable rationale. This requires relevant evidence; the model's internal reasoning is not necessary as an audit record. Access, retention and sensitive content in these records are themselves part of the technical design. Full document contents or secrets do not belong in a log merely because they were available in context.

Responsibilities remain visible too. Business owners maintain terms and rules. Authorized decision-makers are accountable for approvals. Engineering and operations implement the controls and ensure their reliable operation. Enterprise architecture keeps the relationships between these responsibilities traceable as things change.

These control points describe requirements. Whether an implementation meets them must be checked against concrete evidence. The design leaves product selection, interfaces, storage, isolation and performance sizing open. This is the transition from the general architecture to your own implementation brief.

Turning the design into a reviewable implementation brief

To get started, you need a process whose objective and limits your team can name. Choose a bounded decision with a manageable set of sources and a clearly describable possible action. Then develop the knowledge, decision and execution views for exactly that scope. Existing services and responsibilities belong in the discussion from the start; a new box in a diagram is not, on its own, a reason for a new service.

The result should be readable by the business team, architecture, engineering and operations together. The following mapping makes visible which documents may be missing before implementation. The names are suggested filing conventions, not outputs from a tool that has already been run.

This gives the team a basis for detailed technical design and later acceptance. Before use, operations, protection requirements and performance must also be assessed for the actual system. Passing a test of one transition does not establish the reliability of the entire process. It does, however, make a particular guarantee verifiable and show which questions remain open.

Conclusion

A convincing proposal becomes a reliable action only when meaning, the decision process and execution fit together. The agent needs sources with accountable ownership; each step needs a suitable mechanism; the change in the business system needs specific authority and a confirmed result. Enterprise architecture connects these guarantees across responsibilities and changes.

For your own design, it is therefore worth working through one bounded request from beginning to end. Establish where each item of information comes from, who is accountable for each decision, and under which conditions an action may be executed, retried or stopped. The resulting knowledge models, contracts and test cases give implementation a sound working brief.

The components, states and data fields shown here form a conceptual reference design. Their combination has not been implemented or experimentally validated. Standards and product documentation inform individual building blocks; they do not demonstrate that the architecture as a whole has been tested. The detailed technical design must enforce and demonstrate the described boundaries in the systems actually selected.

The practical yardstick remains the opening question: can the business explain and substantiate why this particular action was permitted under these particular conditions? A sound architecture preserves that connection from request to confirmed effect. When a condition is missing, it must be equally able to stop in a traceable way.