From business problem to governed AI system

The stack is not the starting point

AI architecture conversations often begin too low in the stack: Which model? Which agent framework? Which vector database? Which orchestration engine? Which cloud? Which application builder?

Those questions matter, but answering them first can lock a team into implementation decisions before the operating problem is clear.

A more disciplined sequence starts by translating the business problem into a stable system specification. Only then do technology choices become bindings to an understood operating model.

The architecture begins with an operating model

Before choosing a runtime, make the following explicit: identity or tenancy; actors and roles; domain objects; state and event history; relationships; policies and constraints; permissions and privacy; authority and approvals; workflow and state transitions; the AI responsibility; decision memory and audit; and the recurring review or learning process.

This forces an important distinction. A business description such as "use AI to improve supplier approvals" is not yet an architecture. It does not tell you whose state is authoritative, what evidence must exist, who is permitted to decide, which transitions are legal, what the AI may infer, or what must remain human-controlled.

Current platforms make assembly easier. They do not remove the design problem.

Google can add Firestore persistence and authentication to AI-generated applications. Microsoft provides Dataverse and ontology capabilities for operational agent systems. Palantir exposes an operational ontology with objects, relationships, actions, and security. OpenAI's Agents SDK can preserve sessions and suspend runs for human approval.

Those capabilities are useful building blocks. They do not decide which state should be authoritative, who owns the decision, what evidence is sufficient, which transition is permitted, when the system should abstain, or what the business means by "correct."

Those are architecture questions before they are platform questions.

A worked example: supplier exceptions

HYPOTHETICAL EXAMPLE — Consider an enterprise procurement team that wants AI to help process supplier-policy exceptions.

Identity: the enterprise procurement function.

Actors: requester, procurement analyst, risk reviewer, finance reviewer, supplier, and AI assistant.

Objects: supplier, contract, exception request, evidence item, policy, approval, and decision.

States: submitted, incomplete, under review, risk review, finance review, approved, rejected, expired.

Policies: thresholds for spend, missing evidence, sanctions/risk checks, and required approvals.

Authority: AI can classify the request, identify missing evidence, summarize risk, and recommend a route. It cannot approve an exception above the authority granted to human reviewers.

Memory: the system retains the evidence considered, recommendations produced, human decision, rationale, and later outcome.

Disagreement: conflicting reviewers remain explicit rather than being averaged into an automated answer.

Learning: recurring outcomes may suggest policy or model improvements, but the system cannot silently rewrite the policy that governs future decisions.

Once that logical model is clear, the implementation team can choose databases, identity services, orchestration, models, tools, and interfaces based on actual requirements rather than architectural fashion.

The runtime should be replaceable where practical

A governed specification should keep contracts around state, authority, evidence, workflow, AI responsibility, and evaluation intelligible even if runtime bindings change. This does not mean every technology is interchangeable. It means the organization should understand which parts express business truth and which parts are implementation choices.

That distinction reduces accidental lock-in at the conceptual layer. It also makes architecture reviews more useful because a team can ask whether a model, agent framework, or database still satisfies the same state and authority contract when it changes.

The reference application is a falsification tool

A bounded reference application can then test whether the specification actually works. Does the state model survive realistic exceptions? Do permissions match the intended decision rights? Does disagreement remain visible? Can evidence lineage be reconstructed? Does AI classification improve the process? Does the system know when to abstain? Are there missing rules that only become obvious once the workflow is concrete?

The purpose is not to prove the architecture right. It is to create conditions under which it can be shown wrong early.

The output is a decision, not a diagram

The method can be summarized as:

operating problem → governed specification → smallest architecture → bounded test → evidence → decision.

A diagram is useful only if it makes that decision easier to defend.

Decision implication

Start with the operating model the organization must preserve. Make state, actors, authority, policy, evidence, and learning explicit. Then choose the minimum technology required to instantiate it.

Request a Fit Conversation for a governed AI-system architecture review →