Enterprise AI Architecture Decision Framework

Decide whether the use case needs AI before choosing the architecture

AI architecture starts with a simpler question: does this use case need AI at all?

I built this framework to answer that before anyone picks a model or platform. It routes work between process redesign, conventional automation, prompt-only AI, retrieval-augmented generation, predefined AI workflows and agentic systems. It also sets the boundary between what the system may inform, recommend, stage or execute.

The framework chooses the least complex design that can meet the outcome, evidence, risk and operating requirements. I worked it through twelve synthetic cases and a separate set of failure tests covering drafting, policy questions, access provisioning, insurance claims, incident investigation and bounded refunds.

Building blocks the framework can combine

The result is an assembled architecture, not a tool recommendation.

The framework chooses across suitability, reasoning, context, orchestration, authority and human control. These are building blocks rather than mutually exclusive outcomes. A single recommendation may combine several of them: governed retrieval inside a predefined workflow, for example, with human-retained decisions and bounded automated action.

Human review should be assigned to a specific output, judgement or action. It can provide validation, approval, escalation or monitoring, but it does not compensate for an unsafe design.

The decision map

Each assessment uses the same eight stages.

The pattern name comes last. It summarises the decisions but cannot replace them.

How the modules change the design

Start with suitability

I stop or redesign when there is no accountable owner, no testable outcome, disputed policy, unusable data or no credible operating model.

“No AI” is a valid recommendation. A model cannot resolve an organisational disagreement that nobody has made explicit.

Keep fixed rules out of model judgement

Rules, calculations and conventional workflows suit results that can be specified.

Probabilistic reasoning earns its place when the task depends on language, meaning or ambiguity that explicit rules cannot reasonably handle. Many enterprise designs are hybrid: the model interprets the messy input while deterministic components enforce the limits.

Add only the context the task needs

Prompt-only AI works when the supplied input contains everything required.

Governed retrieval is justified when the system must select evidence from current, attributable or permission-sensitive sources. Retrieval adds document lifecycle, evaluation and access-control work. A small, stable policy set may belong in a versioned rules service instead.

Live reads provide current state; they do not grant permission to change it. The framework handles side-effecting capabilities under authority.

Persistent state helps work continue across interactions, but retained information needs ownership, provenance, correction and deletion routes.

Reserve agents for genuinely variable paths

Use a predefined workflow when its stages and branches can be specified in advance, even if it contains several model calls or tools.

Runtime planning becomes defensible when intermediate findings determine which evidence or capability is needed next and a fixed workflow would be unreasonable to maintain.

Conversational input does not make a system agentic. Neither does a long sequence of steps.

Let impact set the authority ceiling

The framework records eight parts of the impact rather than hiding them inside one score:

• consequence;
• reversibility;
• detectability;
• data sensitivity;
• affected parties;
• source trust;
• operating scale;
• error asymmetry.

Limited, reversible and promptly detectable actions may qualify for bounded execution. Material, irreversible or hard-to-detect effects normally stay with a human decision or a staged action.

Wider authority requires explicit policy, evidence that the controls work and an accountable acceptance of the remaining risk.

Assign authority to actions, not products

A system should not receive one blanket autonomy level.

An incident investigator might query approved read-only tools and recommend remediation without any permission to change production. A refund workflow might send an approved clarification message but escalate every policy exception.

Each material action gets its own identity, permission, limit and approval position.

Compatibility rules

A component can make sense on its own and still break the assembled design.

The framework applies these rules before accepting a recommendation:

• suitability overrides every technology choice;
• deterministic policy stays outside model judgement;
• retrieval requires governed sources and preserved permissions;
• live reads do not grant action authority;
• every side effect maps to a defined action class;
• persistent state requires lifecycle controls;
• runtime planning requires a genuinely variable path;
• execution limits sit outside the model;
• untrusted content remains data or evidence, never system instruction;
• review, monitoring and recovery must work at expected volume;
• a human-retained decision cannot also be delegated to the system;
• the complete design must pass, not merely each pair of components.

The assessment stops when a required control cannot be staffed, a consequential action cannot be constrained, source permissions cannot be preserved or the impact cannot be classified and accepted.

A veto identifies what must change. It does not always end the use case.

Worked example: low-value customer refunds

A fictional retailer wants to handle routine refund requests submitted in free text.

The recommendation is a RAG-enabled predefined workflow with bounded deterministic execution and human exception handling.

Decision at a glance

How it works

1. Authenticate the customer and bind the request to a specific order.
2. Use a model to return structured intent and missing-information fields.
3. Retrieve the applicable approved policy and record its source and version.
4. Read the current order, payment and previous-refund state.
5. Apply deterministic eligibility, duplicate and exposure rules.
6. Choose one of four known branches: clarify, refund, stage or decline automation.
7. Execute through a narrow refund interface or an approved communication template.
8. Record and reconcile the evidence, decision, action and payment outcome.

The model interprets language. It cannot override policy, choose another payment route or invent a new branch.

Routine messages use approved templates populated from constrained fields. A person validates any model-written free text before it is sent.

The authority exception

In this fictional scenario, a refund may be cancelled before payment settlement, but the architecture assumes a completed transaction cannot be reliably reversed through the same workflow. That assumption must be checked against the payment provider before implementation. Small losses can also become material at volume.

Pre-authorised execution is therefore an explicit exception to the normal staging default. It needs approved policy, independent limits, monitoring, reconciliation and accepted residual risk. Without that approval, the same workflow prepares the refund for a person to execute.

Why this is not an agent

The stages, tools and exception routes are known. Runtime planning adds no useful capability.

Free-text input, policy retrieval and a refund API do not change that judgement.

Why RAG is conditional

This example assumes several changing product or regional policies where evidence selection, versioning and citations matter.

If the policy set is small, stable and already represented in a versioned rules service, I would remove RAG. The simpler hybrid workflow would do the job with less operational overhead.

Principal controls

Why the other designs were rejected

Process redesign or no AI becomes the answer if policy and exception ownership are unclear.

Deterministic-only automation is preferable when customers can use a structured form and language interpretation adds little value.

Prompt-only AI lacks maintained policy evidence and current transaction state.

A RAG chatbot can explain policy but cannot provide transaction controls or an auditable execution path.

An agentic workflow adds runtime freedom where the problem needs fixed boundaries.

Human handling for every request remains the fallback until routine volume, policy consistency and control performance justify wider authority.

Change the assumptions and the recommendation may change.

Limits

This is an initial architecture decision aid, not production approval.

It does not replace legal analysis, security design, privacy assessment, domain risk review, detailed cost modelling or empirical evaluation. Each organisation still needs to define its thresholds for materiality, information classification, response time and accepted risk.

A recommendation remains provisional until it has been tested against representative successes, boundary cases, failures and adversarial inputs.

Evidence base

The framework combines enterprise architecture judgement with public AI risk guidance. Its main anchors are:

• NIST AI Risk Management Framework
• NIST Generative AI Profile
• Anthropic: Building effective agents
• Joint guidance: Careful adoption of agentic AI services
• UK NCSC: Guidelines for secure AI system development

The detailed working version includes the full module definitions, compatibility rules, twelve validation cases and failure tests. Those cases are working validation material rather than a public self-service assessment; a summary will be published with the Advisor evidence.

How this becomes the Advisor

This page explains the architecture logic. The next intake form will capture the outcome, evidence, data, variability, impact, authority and operating constraints for a use case.

The Advisor will apply the module and compatibility rules to those inputs, then return an assembled recommendation, rejected alternatives and the conditions that must hold before implementation.

The twelve synthetic cases and failure tests are working validation material, not a public self-service assessment. The framework and refund example are the first public outputs. The intake, example recommendation and interactive Advisor will make the method repeatable as they are completed.

Return to the Enterprise AI portfolio to follow the Advisor and other outputs as they are released.

If you want to test an enterprise AI use case before choosing tools, contact me at consulting@joshwickes.com.