Designing an AI-Native Decision Platform from First Principles

I recently finished a full architecture cycle for an AI-native retail decision platform. Strategy, product requirements, architecture design document. Ontology-first. Semantic layers. Agentic workflows with governed autonomy. The full stack, designed from first principles for retail use cases.

I want to explain why we made the choices we made, because architecture decisions are more revealing than a technology list. Anyone can name-drop ontologies and agents. The question is why you chose them over the alternatives, and what you gave up.

Why ontology-first, not vector-first

The default architecture for AI-powered search and decisioning in 2024-25 was vector embeddings plus RAG. Embed your documents, run similarity search, stuff the top-k chunks into a prompt, generate an answer. It works for Q&A. It falls apart for decisions.

Retail decisions are relational. "Should we promote this product in this store next week?" depends on supplier contracts, margin targets, local demand signals, cannibalisation risk from adjacent categories, current stock levels, and what happened the last time a similar promotion ran in a similar store. That is not a similarity-search problem. It is a graph-traversal problem. The relationships between entities carry more decision-relevant information than the entities themselves.

An ontology does two things a vector store cannot. First, it makes decisions explainable by construction, you can trace the path through the graph that led to the recommendation. Second, it makes governance tractable, you can define access controls, audit trails, and autonomy boundaries at the entity and relationship level, not at the document level. For a regulated retail environment operating under UK GDPR and the EU AI Act, that distinction is the difference between a platform you can defend to a regulator and one you cannot.

We built a retail ontology from scratch. Products, promotions, stores, customers, suppliers, contracts, margin targets, demand forecasts, competitive signals, each modelled as an entity type with typed relationships. Not a general-purpose knowledge graph. A domain-specific one, designed around the decisions the business actually makes every day.

Semantic layers: the abstraction that makes it work

An ontology by itself is a data model. What makes it useful for AI is the semantic layer on top, the abstraction that translates business questions into graph queries and model calls without requiring data scientists to understand the underlying schema.

We designed three semantic layers, stacked.

The first maps business language to ontology concepts: "markdown risk" resolves to a specific subgraph involving product margin, stock velocity, and competitor pricing. A merchandiser asks a question in their language; the platform translates it into a structured traversal.

The second handles retrieval: given a resolved concept, assemble the right context from the ontology, the vector store, and any real-time feeds, within a token budget. Context windows are expensive. Filling them with the right information, not just similar information, is the engineering problem most teams underestimate.

The third handles action: given a recommendation from the model, map it back to a concrete business action (change a price, trigger a promotion, flag for human review) with the right governance controls attached. The action layer is where autonomy meets accountability.

The implementation uses LangChain and LangGraph for orchestration, Pydantic for typed tool schemas, pgvector alongside a graph database for hybrid retrieval. The point is that the semantic layer is infrastructure, not application code. It sits between the business user and the AI, and it is where governance lives.

Agentic workflows with governed autonomy

The hardest part of the architecture was autonomy governance. An agent receives a task, decomposes it using a planner, executes steps using tools that query the ontology, and produces a recommendation. That much is well-understood. The question is: how much should the agent be allowed to do before a human has to approve?

Three primitives.

Autonomy budgets: how much the agent is allowed to decide without human approval, defined per decision class, per risk tier, per monetary threshold. A markdown recommendation under £500 on a low-risk product category might execute automatically. A promotional allocation above £50,000 requires human sign-off. The thresholds are configurable, auditable, and enforced at the platform layer, not in application code.

Decision rights: who owns the rollback, who signs the audit trail, who answers to the regulator. Every governed decision has a named owner, a recorded justification, and a reversibility assessment before it executes.

Blast radius: what is the worst outcome if the agent gets it wrong, and is that outcome survivable for the business before a human notices? This is the question most teams skip. If the blast radius of an incorrect decision is a £200 markdown on 50 units in one store, the business absorbs it. If the blast radius is a £2M promotional commitment across 500 stores, it does not. The platform enforces different governance paths based on this assessment.

These are first-class concerns in the architecture, enforced at the semantic layer. An agent cannot execute an action that exceeds its autonomy budget, the platform rejects it before it reaches the business system. This is what makes the platform regulator-legible under EU AI Act Article 14.

What we deliberately chose not to build

Scope discipline matters more than ambition in a platform like this. We stripped the design down to the five or six decision types that actually drive EBITDA in retail data: promotional optimisation, markdown management, assortment planning, customer segmentation, media allocation, and supplier negotiation support. Everything else was deferred.

We also chose not to build a visual workflow editor for non-technical users. The investment was not justified for our team size and user base, the platform serves data scientists and product engineers, not business analysts with a drag-and-drop interface. That is a trade-off we may revisit, but for now it keeps the architecture simpler and the engineering team focused on the decisions that compound in the P&L.

What matters in the end

The platform is in production. The ontology models the decisions. The semantic layers translate business questions into governed actions. The agents operate within their autonomy budgets. It is not finished, platforms never are, but the architecture is holding up against real workloads, and the decisions it produces are explainable, auditable, and commercially useful.

The discipline of documenting every architectural decision, why ontology over vector-only, why three semantic layers instead of one, why governed autonomy rather than human-in-the-loop on every action, forces clarity that slides and verbal alignment cannot. When a regulator or an internal audit team asks why the platform works the way it does, the answer is not "because the engineer who built it thought it was a good idea." The answer is a referenced section in an architecture design document, with alternatives considered, trade-offs evaluated, and risk assessed. That is what enterprise AI governance looks like in practice.

If you are building something similar, ontology-first AI platforms for regulated decisioning in retail, logistics, financial services, or any data-intensive environment, I would be interested to compare notes. venkat@rvenkat.com.