The Enterprise AI Architect Roadmap: The 29 Domains the Role Actually Owns

Most reading lists for AI architects are a pile of technologies. LangGraph, Bedrock, Pinecone, vLLM, Terraform. Learn the list, the theory goes, and you become an architect.

That is backwards. The tools change every few months. The role does not.

An engineer asks how to build the thing. An architect asks what system should exist, why it should exist in that form, what can go wrong, and how anyone will know it is working. Everything below is organised around that second question.

This is the map for The Enterprise AI Architect's Handbook: twenty-nine domains that together describe the working knowledge of the role. Each domain gets its own article in this series, covering what it is, the decisions it forces, how it fails in production, and what a strong answer looks like. Where I have already written on a domain, the existing essays are linked directly under it, so this map is usable today rather than when the series finishes.

How to use this map

The same twenty-nine domains serve four different purposes, and it is worth being explicit about which one you are here for.

Self-study. Work top to bottom. The order is deliberate: the operating model first, because it is the frame that makes everything after it a choice rather than a fact, then knowledge and retrieval, then agents, then the control domains that decide whether any of it survives contact with production. Skipping to agents without the operating model is the single most common way to build something impressive that cannot be shipped.

Interview preparation. Depth beats coverage. Interviewers at architect level pick three or four domains and push until they hit the edge of your experience. Domains 1, 4, 6, 13, 15 and 22 are where most senior interviews concentrate, and domains 25 through 29 are about how you structure the answer once you have it.

Hiring. Use it as a rubric. Twenty-nine domains, scored on whether the candidate can name the failure modes and the trade-offs rather than the products. Someone who can only discuss frameworks is an engineer with a good vocabulary.

Architecture review. Use it as a checklist against a system already built or being proposed. Most AI systems that fail in production fail on the control domains, 13 through 16 and 21 through 24, not on the model or the retrieval pipeline.

Foundations

1. The Architect Operating Model

The frame for everything else. How a business objective becomes an architecture, why the same technology stack produces radically different systems depending on the consequence of being wrong, and how to place probabilistic components inside deterministic control boundaries.

Covers: functional and non-functional requirements, build versus buy versus managed service, control plane against runtime plane, synchronous against asynchronous execution, multi-tenancy, security, observability, evaluation and cost as design-time concerns, failure-mode-first design, bounded autonomy, trade-off reasoning, architecture decision records, service levels, and capacity planning.

Already published: AI Adoption Is an Operating-Model Change, Not a Software Installation and Enterprise AI Operating Model: Who Owns AI After the Pilot?

2. LLM and Foundation Model Fundamentals

Enough of the model internals to make architectural decisions, and no more. An architect does not need to derive attention. An architect does need to know why time to first token behaves differently from tokens per second, and what that means for the user experience being promised.

Covers: tokens and tokenization, embeddings, the transformer at a working level, autoregressive generation, instruction tuning and preference optimisation, context windows and attention limits, lost-in-the-middle, KV cache, decoding parameters, hallucination as a structural property, reasoning and multimodal models, structured outputs, tool calling, quantisation, inference architecture, throughput against latency, batching, and prompt caching.

Already published: LLMs Aren't Magic: What CXOs Must Know Before Going In-House, Physics AI Models: A CTO Guide, and Large Behavior Models: The Foundation Models of Robotics

3. Prompt and Context Engineering

Prompts are configuration, and configuration that reaches production without versioning, testing or a rollback path is an outage waiting for a trigger. This domain treats context as an engineering artefact rather than a writing exercise.

Covers: the system, developer and user instruction hierarchy, zero-shot and few-shot patterns, structured prompting and output schemas, constrained generation, decomposition patterns, context selection, compression and ordering, prompt templates, versioning and registries, prompt testing, injection boundaries, and portability across models.

Already published: How to Make AI Write Reliable Code

Knowledge and Retrieval

4. Retrieval-Augmented Generation

The most-implemented and least-understood pattern in enterprise AI. Almost every RAG failure is a retrieval failure wearing a generation costume, and diagnosing which stage broke is the actual skill.

Covers: the full lifecycle from ingestion, parsing and chunking through embedding, indexing, retrieval, reranking, context assembly, generation and citation; chunking strategies; dense, sparse and hybrid retrieval; vector databases and approximate nearest neighbour indexes; similarity metrics; tenant and access-control aware retrieval; query rewriting, expansion, decomposition and HyDE; rerankers; contextual compression; citation grounding; freshness and incremental indexing; provenance; retrieval and generation evaluation; agentic, corrective, self, adaptive, multi-hop, multimodal and graph variants; and the honest comparison against both fine-tuning and long-context models.

Already published: RAG in Production: What Breaks at Enterprise Scale

5. Enterprise Data Foundation and Knowledge Architecture

The domain that decides whether retrieval has anything worth retrieving. Most organisations discover this after the pilot, when the demo that worked on twelve curated documents meets the real corpus.

Covers: structured, semi-structured and unstructured sources, batch and streaming ingestion, change data capture, semantic normalisation, canonical models, ontologies and taxonomies, entity resolution and linking, knowledge graphs and graph plus vector retrieval, lineage and provenance, confidence scoring, evidence modelling, data quality, and schema evolution.

Already published: Data Readiness for Enterprise AI: What Ready Actually Means

Agents

6. Agent Architecture

The distinction between an agent, a workflow and a chatbot is architectural, not marketing. This domain covers the anatomy of a system that decides its own next step, and the controls that make that acceptable in an enterprise.

Covers: agent anatomy from goal through context, reasoning, planning, state, memory, tools, observation, verification and termination; agent loops; reflection, generator-verifier and planner-executor patterns; state-machine and graph-based agents; long-running agents; deterministic sub-workflows; tool invocation contracts; action verification; termination conditions; step, time, token and cost budgets; retry and recovery; checkpointing and durable execution; idempotency; compensation; human in the loop and on the loop; confidence thresholds; escalation policies; and evidence packs.

Already published: How to Design AI Agents, I Built a Personal AI Agent and Here Is Where It Broke, Enterprise AI Agents: Designing Safe, Scalable, Governed Autonomy, and When AI Becomes Common, the Advantage Moves to How Work Is Orchestrated

7. Agent State and Memory

Memory is the domain where privacy law, security and reliability meet. Getting it wrong produces systems that cannot be audited, cannot forget, and quietly poison themselves over time.

Covers: working, session, episodic, semantic and procedural memory, state persistence and checkpoints, memory retrieval, summarisation and consolidation, retention and time to live, scoping by user, tenant, agent and workflow, memory provenance, memory poisoning, deletion and privacy, and the difference between state and model context.

Already published: AI Agent Memory vs State

8. Multi-Agent Systems

The decision to go multi-agent is usually made for the wrong reason. This domain covers when the topology genuinely helps, and the distributed-systems failures it inherits the moment you adopt it.

Covers: the single against multi-agent decision, supervisor-worker and hierarchical topologies, planner-worker, router-specialist and generator-critic patterns, parallel workers and aggregation, handoffs, shared against isolated context and memory, agent communication and coordination, agent identity and permissions, conflict resolution, distributed failure modes, and multi-agent evaluation.

Already published: Parallel Claude Code Agents

9. Agent Frameworks and Orchestration

Frameworks are a delivery accelerant and a lock-in risk at the same time. The architectural question is which parts of your system are allowed to know the framework exists.

Covers: the major orchestration frameworks at a working level, graph state, conditional edges, checkpointing and persistence, interrupt and resume, durable execution, framework-independent agent architecture, framework selection trade-offs, lock-in, declarative orchestration, versioned execution graphs, input contracts, failure policies, and versioning of workflow definitions.

10. Tools, APIs, MCP and Enterprise Integration

Where an agent stops being a conversation and starts touching systems of record. This is the highest-consequence surface in the entire architecture, and the one most often designed last.

Covers: tool and function calling, tool schemas, discovery, registries and permissions, result validation, the distinction between read and write tools, side-effecting operations, idempotent tool design, credential brokering, short-lived credentials, secrets isolation, MCP architecture and security, plugin and connector architecture, integration manifests, REST, gRPC, webhooks, event-driven integration, queues and streams, and integration with systems of record such as ERP, CRM and procurement platforms.

Already published: Tool Output Is Not Instruction and API Contracts in Microservices

Model Strategy

11. Model Strategy, Serving and Routing

Model choice is a portfolio decision, not a preference. Systems that hard-wire one provider inherit that provider's outages, price changes and deprecation schedule.

Covers: selection criteria across capability, quality, latency, cost, context length, tool use, modality, residency, privacy and availability; closed against open-weight models; managed against self-hosted serving; the model gateway and provider abstraction; model registries; routing and complexity-based routing; fallbacks, cascades and ensembles; rate limits and quotas; load balancing; multi-region and multi-cloud serving; self-hosted inference and quantised serving.

Already published: Enterprise LLM Deployment Cost in India

12. Fine-Tuning and Model Adaptation

Mostly a domain about knowing when not to. The architect's contribution is usually to establish that the problem is a retrieval problem, a prompt problem or a data problem before anyone spends a quarter on training.

Covers: the honest comparison between prompting, retrieval and fine-tuning; supervised fine-tuning; parameter-efficient methods including low-rank adapters; dataset curation and splits; data quality and leakage; synthetic data; fine-tuning evaluation; catastrophic forgetting and overfitting; merging and distillation concepts; and the deployment lifecycle for an adapted model.

Assurance and Control

13. Evaluation of LLM, RAG and Agent Systems

The domain that separates teams who ship from teams who demo. Without evaluation you have no way to distinguish a change that improved the system from one that broke it in a way nobody has noticed yet.

Covers: evaluation strategy, golden datasets, offline, online and human evaluation, model-as-judge and judge calibration, pairwise evaluation, regression testing, A/B, shadow and canary evaluation, quality gates, retrieval metrics including recall, precision, mean reciprocal rank and normalised discounted cumulative gain, faithfulness and groundedness, citation correctness, agent-specific evaluation across task success, tool selection and argument correctness, step efficiency, policy compliance, recovery and side-effect correctness, safety and adversarial evaluation, business-outcome evaluation, and building evaluation sets out of production failures.

Already published: How Enterprises Evaluate LLM Features Before Shipping

14. LLMOps and Observability

You cannot operate what you cannot see, and standard application monitoring is blind to the failures that matter here. A system can be fully green on latency and error rate while producing steadily worse answers.

Covers: the application lifecycle, prompt, model, dataset, evaluation and deployment versioning, feature flags, experiment tracking, distributed tracing and open telemetry conventions for generative AI, the trace hierarchy from agent run through model call, retrieval, reranking, tool call, policy check, approval and verification, metrics across latency, tokens, cost, errors, retries, tool failures and task success, cost dashboards, drift detection across data, retrieval, prompt, model and behaviour, production sampling, feedback loops, incident management, rollback, and root cause analysis.

15. AI Security

The domain with the widest gap between what teams believe they have covered and what they have actually covered. Every tool an agent can call is an attack surface, and every document it reads is untrusted input.

Covers: threat modelling for generative AI, trust boundaries, direct and indirect prompt injection, sensitive information disclosure, data exfiltration, excessive agency, improper output handling, model and data poisoning, embedding attacks, supply chain risk, system prompt leakage, resource exhaustion, tool abuse, confused deputy problems, privilege escalation, cross-tenant leakage, authentication and authorisation models, least privilege, policy as code, guardrails, input and output filtering, personal data detection and redaction, secrets management, network isolation and egress control, sandboxing, schema validation, allowlisting, tenant isolation, encryption, audit logging, tamper-evident evidence, and red teaming.

Already published: AI Agent Architecture: The Trust Boundary Model, Prompt Injection: A Complete Guide, Prompt Injection Attacks: 6 Examples and 6 Defenses, AI Agent Prompt Injection Risk Scorecard, Secure Architecture for AI Agents That Read Email, Documents and Webpages, and Implementing Zero Trust Security Architecture

16. Responsible AI, Privacy and Governance

Governance fails when it is a committee and works when it is architecture. This domain is about encoding the obligations into the system rather than into a policy document nobody reads.

Covers: responsible AI principles, risk classification, model risk management, human oversight, explainability and transparency, accountability, fairness and bias, privacy by design, consent and purpose limitation, data minimisation, residency and retention, right to deletion, the major regulatory regimes including GDPR, the EU AI Act and India's DPDP Act, governance workflows and approval thresholds, policy lifecycle and versioning, auditability, evidence lineage, and incident governance.

Already published: Enterprise AI Agents: Designing Safe, Scalable, Governed Autonomy

Engineering and Infrastructure

17. Software Engineering for AI Platforms

The unglamorous baseline. AI systems fail as distributed systems far more often than they fail as AI, and an architect who cannot reason about idempotency, backpressure and transaction boundaries will be surprised repeatedly.

Covers: production Python including typing, validation, asynchronous concurrency, testing, logging and profiling; API design across REST and gRPC; event-driven architecture and streaming; clean architecture, domain-driven design and dependency inversion; service boundaries and gateways; caching; idempotency; retries with backoff; circuit breakers, bulkheads and timeouts; dead-letter queues; compensation and saga patterns; transaction boundaries; schema evolution; contract testing; continuous delivery; and secure development lifecycle.

Already published: Microservices Architecture Design, Database Ownership in Microservices, Service-to-Service Authentication in Microservices, and Tenant Context in Multi-Tenant Microservices

18. Cloud Architecture for AI Workloads

Cloud-specific knowledge dates quickly, so this domain focuses on the shapes that persist: identity, network isolation, private connectivity, managed model access, and the multi-account or multi-project structures that make tenant and environment isolation real rather than aspirational.

Covers: identity and access management, virtual networks and private endpoints, managed model services across the major providers, serverless and container compute, storage and database selection, queues, event buses and workflow orchestration, secrets and key management, monitoring and tracing integration, multi-account and multi-region architecture, and the well-architected principles that apply regardless of provider.

Already published: Data Centre Infrastructure: Sovereignty, Energy and the AI Era

19. Containers, Infrastructure as Code and Delivery

How the architecture actually reaches an environment, repeatedly and reversibly.

Covers: containers and registries, orchestration primitives, configuration and secrets, namespaces and network policies, resource requests and limits, probes, autoscaling including queue-driven and GPU workloads, scheduling and affinity, infrastructure as code with modules, state and drift, GitOps, environment promotion, policy as code in the pipeline, artefact registries, blue-green and canary deployment, rollback, and infrastructure testing.

20. Cost and Performance Architecture

Cost is a design parameter, not a monthly surprise. The unit that matters is almost never cost per token; it is cost per successful task.

Covers: cost per request, per task, per successful task, per tenant, per workflow and per business outcome; routing for cost; delegation to smaller models; context reduction; retrieval optimisation; prompt and semantic caching; response-length control; batching; asynchronous execution; step and retry budgets; embedding, vector store, GPU and cluster costs; multi-cloud cost visibility; chargeback and showback; quotas; unit economics; and the cost, performance and quality triangle.

Already published: AI FinOps: A Practical Framework to Control Enterprise AI Cost, How to Cut Your Claude Code Cost, and How We Reduced AI Coding Agent Token Cost by 70%

Production

21. Reliability and Resilience

AI systems have failure modes ordinary services do not: the provider degrades, the output is well-formed but wrong, the retrieval silently returns nothing useful, the approval never arrives. Each one needs a designed response.

Covers: provider outage, rate limiting and throttling, model timeout, malformed output, retrieval failure, vector store outage, tool timeout and partial failure, duplicate execution, workflow crash, context overflow, policy denial, approval timeout, retry strategy and backoff, circuit breakers, fallback models, queueing, checkpoint recovery, idempotency, compensation, dead-letter queues, graceful degradation, disaster recovery, incident response, runbooks and postmortems.

22. Enterprise AI Platform Architecture

The shift from building one AI system to building the capability that many teams use. The central idea is the separation of a control plane that governs from a runtime plane that executes.

Covers: the reference architecture; control plane components including model, prompt, tool, policy and evaluation registries, tenant configuration, budgets and deployment configuration; runtime components including the gateway, identity, agent runtime, model gateway, context service, memory service, tool gateway, policy engine, approval service, execution layer and evidence store; shared platform against embedded teams; golden paths and self-service; multi-tenancy and isolation; regionalisation and residency; provider portability; enterprise single sign-on; and the standing tension between central standards and team autonomy.

23. Production and Launch Readiness

The gate. What must be true before an AI system is allowed to touch real users, real money or real records.

Covers: functional correctness, evaluation thresholds, security testing and threat modelling, privacy review, performance and load testing, failure injection, cost validation, capacity planning, service level objectives, monitoring and alerting, runbooks, incident response, rollback for both model and prompt, audit readiness, human approval design, operational ownership and support model, shadow mode, canary, progressive autonomy, and the post-launch feedback loop.

Already published: From AI Pilot to Production: The Twelve Gates

Practice and Leadership

24. Domain Architecture

Applying the whole model to one real business function, end to end, where the consequences are financial rather than conversational. Working through a single domain properly is worth more than reading about ten.

Covers: translating standard operating procedures into executable workflows, dependency ordering, input contracts, failure policies, deterministic execution plans, evidence requirements, approval thresholds, financial impact quantification, closed-loop remediation, and integration with existing systems without replacing them.

25. AI System Design Practice

Fifteen problems, worked. A production retrieval platform, a multi-tenant knowledge assistant, an agent workflow platform, a tool gateway, a model router, an evaluation platform, an observability platform, a memory service, a secure ingestion pipeline, a regulated multi-region deployment, a human approval system for AI-initiated actions, and others.

26. Architecture Artefacts

The diagrams an architect must be able to produce under time pressure, on a whiteboard or in a document, without hedging.

Covers: context, container and component diagrams, data flow, sequence and deployment diagrams, trust boundary diagrams, agent state machines and execution graphs, retrieval pipelines, routing and tool-execution flows, approval and recovery flows, multi-tenant isolation models, control plane and runtime plane views, observability trace models, threat models, and decision records.

27. Structured Answers and Reviews

How to structure a system design answer, a trade-off argument, an incident account and a leadership account so that the reasoning is visible. The same structures serve an interview, a design review and a board update, because all three are asking whether your judgment can be trusted.

Covers: the full system design structure from objective through requirements, scale, data, model choice, architecture, state, security, reliability, evaluation, observability, cost, deployment, rollout and trade-offs; the options, constraints, criteria, decision, consequences and revisit-conditions structure for trade-offs; the detection, containment, diagnosis, recovery, root cause and prevention structure for incidents; and a first ninety days structure for a new architecture role.

28. Experience Narratives

The dozen accounts an architect must be able to give from their own work: an end-to-end architecture, a production retrieval system, an agent platform, a security decision, a multi-tenant design, a reliability incident, a latency problem, a cost reduction, a genuine trade-off, an approach that failed and was corrected, a governance decision, and a difficult stakeholder.

The failed approach matters most. Architects who have never been wrong in public have usually never shipped anything consequential.

29. Architecture Leadership and Technical Strategy

The part of the role that has nothing to do with models. Architecture that cannot survive an organisation is not architecture, it is a diagram.

Covers: discovery and requirements elicitation, stakeholder mapping, capability mapping, use-case prioritisation against value, feasibility and risk, roadmaps and target and transition architecture, migration strategy, pilot-to-production strategy, build against buy against platform, vendor evaluation, architecture governance and design authority, standards and guardrails, technical debt, risk registers, engineering quality bar, design and code review, mentoring, team scaling, executive communication, and communicating trade-offs to people who will not read the diagram.

Already published: How to Prioritise AI Use Cases by Value, Feasibility and Risk and Digital Transformation for SMEs: A CXO Playbook

Common questions

Do I need all twenty-nine to call myself an AI architect? No. You need working depth in the operating model, retrieval, agents, evaluation and security, and enough of the rest to know when to bring in someone who has it. What separates an architect from a senior engineer is not breadth for its own sake, it is knowing which domain a given failure belongs to.

How long does this take? Longer than a certification and shorter than a career. If you are already a senior engineer building with these systems, the gaps are usually evaluation, observability, cost and platform architecture, which is a few months of deliberate work rather than years.

Is this enough for an architect interview? The knowledge is. The delivery is a separate skill, which is what domains 27 and 28 exist for. Interviewers at this level are not testing recall, they are testing whether you can structure an unfamiliar problem and be honest about what you do not know.

Does this map to a certification? Not to any single one. Certifications tend to be either cloud-provider specific or model specific, and this covers the architecture that sits above both. Use it as the syllabus and the vendor certifications as evidence for the parts they actually cover.

What comes next

Each of the twenty-nine domains becomes its own article, listed in order below. They are written to stand alone, so you can enter at whichever domain you are currently stuck on. Together they form the working reference I wish had existed when I started designing these systems for organisations that had to live with the consequences.