Author: Jugal Shah

  • The Identity Problem: Why Your “Single Customer View” Is Five Different People

    Every enterprise claims to have a single customer view. Almost none of them do. What they have is five versions of the customer — the CRM version, the billing version, the support version, the marketing version, and the one in the data warehouse that was stitched together three years ago and hasn’t been questioned since.

    This isn’t a cosmetic problem. Identity is the join key of the entire enterprise. When it’s wrong, every report is subtly wrong, every personalization is subtly off, and every AI agent built on top of it acts on fiction with total confidence.

    Why identity breaks

    Identity breaks because every source system has its own opinion about who a customer is, and none of them are wrong — they’re just incomplete. The CRM knows “Robert Smith, rob.smith@email.com.” Billing knows “Bob Smith, rsmith@work.com, account 88412.” Support knows a phone number and a first name. The mobile app knows a device ID. None of these records agree, and all of them are real.

    The naive fix is “just match on email.” It works until it doesn’t: shared family emails, work emails that change when people change jobs, customers with three accounts across three business units. Email is an attribute, not an identity.

    Match and merge: the mechanics

    Identity resolution comes down to two questions: which records refer to the same person, and what do you do about it?

    Matching is the first question, and it has two flavors. Deterministic matching — same email, same phone, same government ID — is precise but misses most real-world messiness. Probabilistic matching scores the likelihood that two records are the same person based on name similarity, address proximity, shared identifiers, and behavioral signals. Good systems use both: deterministic rules for the obvious cases, probabilistic scoring for the rest, and a human review queue for the gray zone in between.

    If your matching is fully automatic with no review queue, you don’t have identity resolution. You have identity roulette.

    Merging is the second question, and it’s where most projects quietly fail. Merging doesn’t mean deleting records. It means linking them: every source record survives, and a golden record sits above them as the resolved view. Delete the sources and you lose lineage, auditability, and the ability to un-merge when you get it wrong. And you will get it wrong sometimes.

    Survivorship: who wins

    When five records disagree about a customer’s address, which one is right? That’s survivorship, and it needs explicit rules — not vibes.

    The honest answer is “it depends on the attribute.” The most recent address usually wins. The legal name from the verified onboarding system beats the nickname someone typed into a support ticket. The phone number the customer used last week beats the one from 2019. Survivorship rules should be attribute-level, source-ranked, and visible — anyone should be able to ask “why does the golden record say this?” and get an answer, not a shrug.

    The golden record and the 360 view

    A golden record is the resolved, survivable, lineage-tracked representation of an entity — customer, product, location, supplier. The 360 view is what you build on top of it: every interaction, transaction, and touchpoint attached to one identity.

    Here’s what separates real 360 views from slideware: the golden record is operational, not analytical. If it only lives in the warehouse for reporting, it’s a museum piece. The real thing feeds the call center screen, the personalization engine, the fraud check, and the agent — in real time, through APIs, with the same identity everywhere.

    Identity in the agentic era

    This is where identity goes from important to existential. A dashboard showing a duplicated customer is an embarrassment someone might notice. An autonomous agent acting on a duplicated customer is a machine that emails the wrong person, applies the wrong discount, or discloses one customer’s data to another — at speed, at scale, without asking.

    Agents don’t have the human instinct to say “wait, this doesn’t look right.” They act on whatever identity you hand them. Every identity defect your organization tolerated in the BI era becomes an incident in the agentic era. The math changed; the tolerance can’t stay the same.

    Your agents will be exactly as trustworthy as your identity resolution. No more.

    What good looks like

    Good identity resolution has a shape you can recognize: source records preserved with lineage, match rules versioned and explainable, a review queue for uncertain matches, attribute-level survivorship rules, golden records served operationally through APIs, and metrics — match rate, merge rate, false-positive rate — that someone actually watches.

    It’s unglamorous work. Nobody demos identity resolution at a conference. But it’s the foundation everything else stands on: the 360 view, the personalization, the analytics, and now the agents. Get identity right and the rest gets easier. Get it wrong and the rest gets fictional.

    The enterprises that treat identity as infrastructure will have an almost unfair advantage as agents take over more of the work. The ones that don’t will have very fast, very confident systems acting on five different versions of the truth.

    — Jugal

  • What “AI-Ready Data” Actually Means: A Data Leader’s Field Guide

    Every board in America is asking about AI strategy right now. And somewhere in every one of those companies, a data leader is sitting in that meeting thinking: “You want AI? Have you seen our data?”

    That gap — between AI ambition and data reality — is where data leadership careers will be made and broken over the next three years. Not in model selection. Not in prompt engineering. In the unglamorous work of making enterprise data connected, trusted, and discoverable enough for intelligence to stand on.

    This is the field guide for closing it.

    Single source of truth — or a very expensive mirror

    Every enterprise has data. Most have five versions of every fact: the finance version, the marketing version, the operations version, and two more nobody will admit to. Ask an AI to answer a question on top of that, and it won’t resolve the contradictions. It will confidently pick one.

    A unified data platform isn’t a technology project. It’s a trust project. The technology — the lakehouse, the catalog, the pipelines — is the easy part. The hard part is getting every domain to agree on what a customer is, what revenue means, and which system wins when they disagree.

    If the business doesn’t trust the data, your single source of truth is a very expensive mirror.

    Three tests for whether you’re actually there: connected (can you trace a metric from dashboard to source system?), trusted (do business leaders quote your numbers without adding “but let me check”?), and discoverable (can a new analyst find the right dataset in an afternoon, not a quarter?). If any answer is no, you don’t have a platform yet. You have infrastructure.

    AI-readiness is a data problem wearing an AI costume

    Here’s the uncomfortable truth behind every stalled AI pilot I’ve seen: the model was fine. The data wasn’t. Wrong, stale, contradictory, or legally unusable — pick your poison.

    AI-readiness has a concrete definition, and it’s worth writing down: every dataset an AI system touches has a known owner, a documented lineage, a quality verdict, and a clear access policy. That’s it. Not a vision statement — an inventory.

    The leaders getting this right aren’t running “AI readiness programs” as a separate track. They’re folding readiness into the platform work they should have been doing all along: data contracts at ingestion, quality gates in pipelines, lineage as a first-class artifact. When the AI use case arrives, the data is already standing at attention.

    Governance that ships

    Governance has a branding problem, and data leaders created it. For a decade, governance meant committees, tickets, and six-week waits for access approvals. So the business learned to route around it — shadow pipelines, spreadsheet empires, “temporary” extracts that are now seven years old.

    Governance that slows teams down gets routed around. Every time.

    The fix isn’t less governance. It’s governance that ships: policies enforced in the platform itself, access granted by rules instead of meetings, quality checks running in the pipeline instead of in a quarterly review. The NIST AI Risk Management Framework gets this right — Govern, Map, Measure, Manage as a continuous cycle, not a stage gate. Embed it, automate it, and measure whether teams move faster with it than without it. That’s the only metric that matters.

    Data mesh, honestly

    Data mesh is the right answer to a real problem: centralized data teams don’t scale to hundreds of domains. Federated ownership, domain-oriented data products, self-service infrastructure — the principles are sound.

    But mesh without a platform is just distributed chaos with a trendy name. I’ve watched organizations declare “data mesh” and get sixteen incompatible definitions of a customer, each owned by a domain team with no incentive to reconcile them. The mesh needs a strong center: shared standards, common tooling, and a platform team whose job is making domain ownership easy, not just making it someone else’s problem.

    Be honest about where you are. If your domains can’t yet produce trustworthy data products on their own, you don’t need a mesh — you need a platform team and about eighteen months of discipline. Mesh is a maturity destination, not a starting position.

    Master data: the unsexy foundation

    Nobody gets promoted for fixing duplicate customer records. But here’s what changes the math: agentic AI.

    A bad customer record in a dashboard is a wrong number someone might catch. A bad customer record fed to an autonomous agent is an agent that emails the wrong person, bills the wrong account, or acts on fiction at machine speed. AI doesn’t just surface master data problems — it multiplies them.

    Your AI is only as smart as your customer record.

    Master data excellence — golden records for customer, product, location, the entities your business actually runs on — is the highest-leverage, lowest-glamour work in the data portfolio. Do it before the agents arrive, not after the incident.

    Forward deployment: adoption is the job

    The best data platform in the world is worthless if nobody uses it. And “build it and they will come” has a perfect failure record in enterprise data.

    The model that works is forward deployment: data engineers and governance specialists embedded with business units, operationalizing standards inside real workflows instead of publishing them from headquarters. You don’t drive adoption with town halls. You drive it by sitting with the finance team until their close process runs on your platform — and then letting them tell the story.

    Measure adoption, not deployment. Not “pipelines built” but “decisions made on governed data.” Not “datasets cataloged” but “analysts who found what they needed without filing a ticket.” The platform serves the business, and the metric should prove it.

    The leadership part

    None of this is a technology problem at its core. It’s an alignment problem, which makes it a leadership problem.

    Three disciplines matter most. First, executive fluency: translate everything into business outcomes. Nobody funds “data mesh.” They fund “cutting month-end close from nine days to three.” Second, organization building: hire for judgment, not just tooling — tools change every eighteen months, and the team that thrived through three platform migrations is worth more than the team that knows this year’s stack. Third, patience with urgency: this work takes years, but you must show value in quarters. Ship the thin slice that earns the next round of trust.

    The enterprises that get data right in the next three years will have an almost unfair advantage in AI — not because their models are better, but because their models stand on ground instead of fog. The ones that don’t will have very impressive pilot graveyards.

    The work is unglamorous. The payoff isn’t. That’s the job.

    — Jugal

  • The Agentic Enterprise, October 2026: The Framework I Wish I’d Had

    Hi — Jugal here.

    This week I published something I’ve been building toward for years: the Agentic Architecture Framework — a practitioner’s method for architecting AI systems on a real data foundation. If you know TOGAF, you’ll recognize the shape. If you don’t, here’s the one-line version:

    It’s a disciplined way to answer “where does AI earn its keep here?” — and keep answering it as the system grows.

    This edition isn’t a recap of the article. It’s the part I couldn’t fit in it: the deeper cut, the worked example, and something I’m only sharing with you — a self-assessment you can run on your own organization Monday morning.

    The framework in 90 seconds

    Six components:

    1. 12 principles — the rules every AI initiative gets judged against (business value first, data quality as prerequisite, evals before enthusiasm, humans in the loop by design, cost as architecture, and seven more)
    2. The AI Delivery Cycle — six phases plus a preliminary: Vision & Value → Data Foundation

      The deeper cut: what “data readiness” actually looks like


      The phase that kills the most bad AI projects is Phase B — Data Foundation. Not because data teams fail, but because nobody asks for a verdict. So here’s what a real Data Readiness Assessment looks like, worked through on a realistic example.


      Scenario: you want an AI assistant that answers customer questions from your support knowledge base and ticket history.


      The assessment asks five questions per data source:



      1. Quality — Of 50,000 tickets, how many have a correct resolution recorded? (In most orgs: 60–70%. The rest are “closed” with no usable answer.)

      2. Completeness — Do you have the product documentation the answers depend on? Is it current?

      3. Freshness — How stale is the oldest article the assistant might quote? If it’s three years old, the assistant will confidently give wrong answers.

      4. Lineage — Can you trace an answer back to the ticket or article it came from? If not, you can’t fix bad outputs.

      5. Access & rights — Does the assistant have legal access to all of it? Support tickets often contain customer PII that changes what you’re allowed to do.


      The verdict format is binary per source: GO or NO-GO — with conditions. Example: “Ticket history: CONDITIONAL GO — usable after filtering to tickets with verified resolutions (est. 65% of corpus). Knowledge base: NO-GO — 40% of articles outdated; remediation required before training.”


      That verdict, written down and signed off, is worth more than any model evaluation. Because a brilliant model on unready data is just a faster way to be wrong.


      Subscriber exclusive: the maturity self-assessment


      Run this on your organization. Be honest — no one sees the score but you.


      Level 1 — Exploring. AI curiosity, no production systems. You’re here if: the AI conversation is mostly conference talks and vendor demos.


      Level 2 — Experimenting. Pilots and demos exist. You’re here if: you can name three pilots, but none has a production date.


      Level 3 — Piloting. First


      Try this week


      Pick one AI initiative — just one — and score it against three principles:



      1. Can you name its business outcome in one sentence? (Principle 1)

      2. Has anyone issued a written data-readiness verdict? (Principle 2)

      3. Does it have an eval harness that could catch a regression tomorrow? (Principle 3)


      If the answer to any of these is no, you don’t have an AI project yet. You have homework. That’s fine — now you know what it is.


      What’s next


      Next month: governance that accelerates — what the NIST AI Risk Management Framework looks like running inside a real AI system, not a compliance deck. If this edition resonated, that one’s for you.


      As always, reply to this email — I read every one.


      — Jugal


      The Agentic Enterprise is a monthly newsletter on production AI, agentic systems, and enterprise data architecture. Browse the archive · aideeva.com


      production AI workloads. You’re here if: something is live, and governance/HITL is the bottleneck.


      Level 4 — Scaling. Multiple AI systems in production. You’re here if: cost control and reuse are your main problems — congratulations, those are good problems.


      Level 5 — Leading. AI is a managed capability with feedback loops, mature evals, governed expansion. You’re here if: you can run the full delivery cycle in your sleep.


      The uncomfortable pattern: most enterprises score themselves at 2 and plan like they’re at 4. If that’s you, the fix isn’t more ambition — it’s Phase B and Phase D done properly, before anything else.


      → Intelligence Architecture → Evaluation → Governance & Deployment → Operate & Evolve

    3. A content framework — what you actually produce in each phase (not shelfware: signed-off deliverables like the Data Readiness Assessment and the Evaluation Plan)
    4. Three reference architectures — RAG, agent, and eval-harness blueprints you tailor instead of reinventing
    5. Governance mapped to NIST AI RMF — Govern, Map, Measure, Manage, woven through the cycle instead of bolted on after
    6. A 5-level maturity model — from Exploring to Leading, so you can locate yourself honestly

    Read the full article here: The Agentic Architecture Framework

    And if you’re the one who has to explain AI to a board: I also published the executive companion this week — How CIOs and CTOs Should Approach AI.

    That verdict, written down and signed off, is worth more than any model evaluation. Because a brilliant model on unready data is just a faster way to be wrong.

  • How Executives Should Approach AI: A CIO/CTO Field Guide

    Every CIO and CTO I talk to is living the same paradox. The board wants an AI strategy. Vendors promise transformation in a slide deck. And somewhere in the building, a dozen disconnected pilots are quietly dying — not from bad models, but from bad approach.

    Here’s the uncomfortable truth: most enterprises don’t have an AI problem. They have an approach problem. The technology works. What’s missing is executive discipline — the same discipline you’d apply to any major capital bet.

    This is a field guide for that discipline.

    1. Start with the P&L, not the model

    No AI initiative should exist without a named business outcome and a rough ROI thesis written in plain language. Not “leverage LLMs for synergy” — but “cut claims processing time by 40%” or “resolve tier-1 support tickets without human touch.”

    If you can’t write the outcome on a whiteboard, you don’t have a strategy. You have a science project. Fund accordingly — which is to say, barely.

    The question to ask of every proposal: where does AI earn its keep here? If nobody can answer with a number, the answer is “nowhere yet.”

    2. Your data estate is the real project

    Here’s what the demos never show: the AI was the easy part. The hard part was the twenty years of data underneath it — fragmented across systems, inconsistently defined, with lineage nobody can trace.

    Most AI failures are data failures wearing an AI costume. Before you approve a single model evaluation, demand a data readiness verdict: is our data fit for machine consumption — quality, completeness, freshness, access, lineage? If the answer is no, your AI budget is actually a data modernization budget. Say so out loud. Boards respect honesty more than hype.

    3. Escape pilot purgatory

    The enterprise AI graveyard is full of pilots that proved the technology and changed nothing. The pattern is always the same: too many pilots, too thin, no path to production, no owner with P&L responsibility.

    The fix is concentration, not experimentation:

    • Pick two or three workflows where AI moves a real number. Not ten. Two or three.
    • Fund them like products, not experiments. A product has an owner, a roadmap, and a production date. An experiment has a demo day.
    • Define the production gate up front. What eval score, what cost per transaction, what error rate earns the right to scale? Write it down before the pilot starts, when everyone’s still honest.

    One workflow in production beats ten pilots in a slide deck. Every time.

    4. Demand governance that accelerates

    Many executives treat governance as the thing that happens after the engineers finish — a review board, a checklist, a six-week delay. Then they’re surprised when teams route around it.

    Flip it. The governance that works in the AI era ships with the system: eval harnesses that catch regressions automatically, guardrails as code, human-in-the-loop checkpoints placed where the cost of error is highest. Frameworks like the NIST AI Risk Management Framework give you the structure — Govern, Map, Measure, Manage — but the principle is simpler: if your governance slows shipping without reducing risk, it’s theater.

    Ask your teams one question: “Show me the guardrail.” If it’s a document, you have a problem. If it’s running in the pipeline, you have governance.

    5. Know your unit economics

    AI has a cost structure executives aren’t used to: it scales with usage, not with seats. A support agent that costs pennies per ticket at pilot scale can cost a fortune at enterprise volume — token spend compounds silently in multi-step workflows.

    Before scaling anything, demand the unit cost: what does one transaction cost us, fully loaded? Cost per resolved ticket. Cost per processed document. Cost per generated report. Then ask what happens to that number at 10x volume.

    If nobody knows the unit economics, you’re not running an AI strategy. You’re running an experiment with the company’s money.

    6. Run hub-and-spoke, not chaos or centralization

    Two operating models fail predictably. Pure centralization creates a bottleneck — one AI team, a hundred requests, everything waits. Pure decentralization creates chaos — fifteen teams buying fifteen tools, no shared learning, no leverage.

    What works is hub-and-spoke: a central platform team owns the foundations (data pipelines, eval harnesses, model access, guardrails, cost monitoring), and embedded teams in the business units own the use cases. The hub provides leverage. The spokes provide proximity to the actual problem.

    Your job as the executive: protect the hub’s mandate and hold the spokes accountable for outcomes, not activity.

    7. Hire for the bottleneck, not the hype

    You don’t need an army of prompt engineers. The roles that actually unblock enterprise AI are far less glamorous:

    • Data engineers who can make the estate AI-ready — because that’s the real project (see #2).
    • Evaluators who can tell you whether the system is getting better or worse — because without evals, you’re flying blind.
    • Product-minded engineers who think in workflows and outcomes, not demos.

    If your hiring plan says “AI experts” without naming these three, rewrite it.

    8. Measure like an executive, not a researcher

    Benchmark scores don’t pay bills. Hold your AI portfolio to decision-grade metrics:

    • Outcome metrics: the business number it was supposed to move. Did it move?
    • Quality metrics: eval scores, error rates, escalation rates — trending which direction?
    • Economic metrics: unit cost per transaction, and its trajectory at scale.
    • Risk metrics: incidents, bias findings, data exposure events. Zero surprises is the target.

    Review these the way you’d review any business unit. AI doesn’t get a grace period from accountability — that’s exactly how pilot purgatory starts.

    9. Interrogate your vendors

    Every vendor will tell you their AI is enterprise-ready. Few can prove it. Before you sign, demand answers:

    • Show me your eval methodology — not your benchmark scores, your methodology.
    • Where does our data go? Who can see it? How do we get it back?
    • What happens to our unit cost at 10x volume?
    • What’s our exit strategy if this doesn’t work?

    The vendors worth partnering with answer these crisply. The rest are selling slides.

    The one question

    Strip away the frameworks and the org charts, and the executive’s job on AI comes down to a single discipline: keep asking where does AI earn its keep here — and fund only the answers backed by evidence.

    Start with the P&L. Fix the data. Concentrate your bets. Govern at the speed of shipping. Know your unit costs. Measure like it matters — because it does.

    The enterprises that win the AI era won’t be the ones that experimented the most. They’ll be the ones that approached it with the most discipline.

    For the practitioner’s companion to this guide — the full method with principles, delivery phases, and reference architectures — see The Agentic Architecture Framework. Jugal Shah writes about production AI, agentic systems, and enterprise data architecture at aideeva.com, where he publishes The Agentic Enterprise newsletter.

  • The Agentic Architecture Framework: A TOGAF-Style Method for AI & Data

    Enterprise architecture has a trusted method for designing technology change: TOGAF and its Architecture Development Method (ADM). But TOGAF was built for a world of deterministic systems — applications with known inputs, predictable outputs, and release cycles you could plan on a Gantt chart.

    AI systems don’t behave that way. They are probabilistic. They learn, drift, hallucinate, and compound cost silently in multi-step loops. The data they depend on is rarely ready. And the governance models built for traditional software either block AI entirely or wave it through unexamined.

    This article proposes the Agentic Architecture Framework — a practitioner’s method for architecting AI systems on a real data foundation. If you know TOGAF, you already know its shape: principles, a development method, a content framework, reference architectures, and governance. What’s different is what it confronts: data readiness, evaluation, model economics, and human judgment as first-class architectural concerns.

    This isn’t a standard. It’s a field method — drawn from shipping production AI and data platforms at scale — for anyone who has to answer the question: where does AI actually earn its keep here, and how do we build it so it keeps earning it?

    Why TOGAF alone isn’t enough for AI

    TOGAF’s ADM is excellent at what it was designed for: aligning business, data, application, and technology architecture through a disciplined, iterative cycle. But apply it directly to an agentic AI initiative and four gaps appear:

    1. Data readiness is assumed, not assessed. TOGAF’s Phase C covers data architecture, but AI needs something stricter: a verdict on whether the data is fit for machine consumption — quality, lineage, freshness, access, and bias.
    2. Evaluation has no home. Traditional architecture assumes you can specify behavior. AI behavior is emergent. Without a dedicated evaluation discipline — eval harnesses, red-teaming, offline-to-online validation — you’re shipping hope.
    3. Cost is not an architecture concern. TOGAF plans migration cost; it doesn’t account for token spend compounding across agent loops at 3 AM. In A
    4. Governance is a gate, not a loop. Phase G governs implementation, but AI systems need continuous governance — drift detection, feedback loops, and human-in-the-loop placement that evolves as the system learns.

    Most AI failures are data
    failures wearing an AI costume.

    In AI, cost is architecture.

    The Agentic Architecture Framework keeps TOGAF’s skeleton and rebuilds the muscle for AI.

    The framework at a glance

    Six components, mirroring the structure architects already know:

    1. Architecture Principles — the 12 rules every AI initiative is judged against.
    2. The AI Delivery Cycle — the method itself: Preliminary + six phases (A–F), iterative, not waterfall.
    3. The Content Framework — what you produce in each phase (artifacts and deliverables).
    4. Reference Architectures — reusable blueprints: the RAG blueprint, the agent blueprint, the eval harness blueprint.
    5. Governance — mapped directly to the NIST AI Risk Management Framework (Govern, Map, Measure, Manage).
    6. The Maturity Model — five levels, from Exploring to Leading, so you can locate any organization honestly.

    Component 1: The 12 principles

    Principles are the framework’s conscience. Every design decision should be traceable to one of these:

    1. Business value first, models second. No AI initiative exists without a named business outcome and an ROI thesis.
    2. Data quality is an AI prerequisite, not a data problem. If the data isn’t fit, the AI isn’t ready. Say so early.
    3. Evaluation before enthusiasm. No model, agent, or pipeline reaches production without an eval harness that can catch regressions.
    4. Humans in the loop by design. Place human judgment where the cost of error is highest — deliberately, not as an afterthought.
    5. Cost as an architecture concern. Token spend, compute, and data pipeline cost are designed in, with budgets per workflow.
    6. Deterministic where possible, probabilistic where valuable. Don’t pay for an agent to do what a rule, a lookup, or a smaller model does better.
    7. Lineage is non-negotiable. Every AI output should be traceable to the data and model version that produced it.
    8. Governance that accelerates. Guardrails ship with the system — as code, as evals, as contracts — never as a committee that meets after launch.
    9. Start narrow, earn the right to expand. One workflow, done well, beats five pilots that never reach production.
    10. Security and privacy by construction. Data access, PII handling, and model exposure are architectural inputs, not audit findings.
    11. Observability from day one. If you can’t see what the system did and why, you can’t operate it.
    12. Learn in production. Feedback loops, drift detection, and retraining aren’t maintenance — they’re the system working as designed.

    Component 2: The AI Delivery Cycle

    The method. Iterative, tailorable, and familiar to anyone who’s run an ADM cycle. Requirements management runs continuously through the center — same as TOGAF.

    Preliminary — Principles & Posture. Establish the AI principles (above), define risk appetite, stand up the governance scaffolding, and tailor the framework to the organization. Maps to NIST AI RMF Govern.

    Phase A — Vision & Value. Define the business outcome in plain language. Where does AI earn its keep here? Produce the AI Vision: the outcome, the ROI thesis, the explicitly-named non-goals. Get stakeholder sign-off before a single model is evaluated.

    Phase B — Data Foundation. Assess data readiness brutally: quality, completeness, freshness, lineage, access rights, and bias. Remediate or descope. Output: the Data Readiness Assessment — a go/no-go verdict per data source. This phase kills more bad AI projects than any other, and that’s its job.

    Phase C — Intelligence Architecture. Design the AI itself: model selection and routing, retrieval architecture, agent decomposition, tool use, and the deterministic-vs-probabilistic split. Build-vs-buy decisions live here. Output: the Intelligence Architecture with cost projections per workflow.

    Phase D — Evaluation. Build the eval harness before production: offline benchmarks, golden datasets, red-teaming, and the promotion criteria for online testing. Define what “good” means numerically — and what triggers a rollback. Output: the Evaluation Plan with pass/fail thresholds.

    Phase E — Governance & Deployment. Map risks (NIST AI RMF Map), measure them (Measure), and put controls in place (Manage). Place human-in-the-loop checkpoints where error cost is highest. Deploy in stages behind the eval harness. Output: the Risk Register, the HITL design, and the staged rollout plan.

    Phase F — Operate & Evolve. Run it like a production system: cost monitoring against the budgets set in Phase C, drift detection, feedback loops feeding back into evals, and a defined change process for model updates. Output: the Operations Runbook — and the input to the next cycle.

    Then cycle again. AI systems are never “done”; each cycle deepens the data foundation, sharpens the evals, and expands scope only where value is proven.

    Component 3: The Content Framework

    Every phase produces artifacts (working products) and deliverables (signed-off outputs). The core set:

    PhaseKey deliverableSupporting artifacts
    PreliminaryAI Principles sign-offRisk appetite statement, governance charter
    A — Vision & ValueAI VisionROI thesis, non-goals list, stakeholder map
    B — Data FoundationData Readiness AssessmentData quality scorecard, lineage map, access matrix
    C — Intelligence ArchitectureIntelligence ArchitectureModel routing table, cost projections, build-vs-buy analysis
    D — EvaluationEvaluation PlanGolden datasets, red-team findings, promotion criteria
    E — Governance & DeploymentRisk Register + rollout planHITL design, control mappings, rollback procedures
    F — Operate & EvolveOperations RunbookCost dashboards, drift reports, feedback-loop specs

    A deliverable is reviewed and signed off. An artifact is lived in. Confuse the two and you get shelfware.

    Component 4: Reference architectures

    Don’t redesign what repeats. The framework ships with three starting blueprints, tailored per engagement:

    • The RAG blueprint. Ingestion → chunking → embeddings → vector store → retrieval → generation → eval. With the data-readiness gates from Phase B baked into ingestion, and the eval harness from Phase D wrapped around retrieval quality.
    • The agent blueprint. Planner → tools → memory → human checkpoints → output validation. With loop budgets (max steps, max cost per run), deterministic fallbacks, and HITL placement per Principle 4.
    • The eval harness blueprint. Golden dataset → offline eval → shadow mode → canary → production monitoring. The promotion ladder every AI system climbs, with rollback criteria at each rung.

    Component 5: Governance — the NIST AI RMF mapping

    Governance in this framework isn’t a separate track; it’s woven through the cycle, mapped to the NIST AI Risk Management Framework’s four functions:

    • Govern → Preliminary phase. Culture, accountability, risk appetite, and the principles themselves.
    • Map → Phases A–C. Context, categorization, and risk identification as the vision, data, and architecture take shape.
    • Measure → Phase D. Evaluation, red-teaming, and quantified risk — the numbers behind the verdicts.
    • Manage → Phases E–F. Controls deployed, risks tracked, feedback loops running in production.

    If your organization already runs a NIST AI RMF program, this framework slots into it. If it doesn’t, the framework gives you the program.

    Component 6: The Maturity Model

    Five levels. Be honest about where you are — the framework meets you there:

    1. Exploring. AI curiosity, no production systems. Focus: Preliminary + Phase A. Pick one outcome.
    2. Experimenting. Pilots and demos exist. Focus: Phase B + D. Kill what the data can’t support; eval what survives.
    3. Piloting. First production AI workloads. Focus: Phase E. Governance and HITL are the bottleneck — fix them.
    4. Scaling. Multiple AI systems in production. Focus: Phase F + reference architectures. Cost control and reuse separate winners here.
    5. Leading. AI is a managed capability with feedback loops, mature evals, and governed expansion. Focus: cycle speed — how fast can you run the Delivery Cycle well?

    Most enterprises sit at 2. Most AI strategies assume they’re at 4. The maturity assessment exists to close that gap before it closes your budget.

    How to use it

    1. Start with the maturity assessment. One workshop, honest scoring, no vanity.
    2. Run Preliminary once — principles and posture are enterprise-level, not per-project.
    3. Run the cycle per initiative — Phases A through F, tailored. A narrow internal tool gets a light pass; a customer-facing agent gets the full treatment.
    4. Build the reference architectures as you go. Your second RAG system should be 70% reuse.
    5. Let Phase F feed Phase A. The learnings from operations are the most valuable input to the next vision.

    Closing

    TOGAF gave enterprise architecture a shared language for the deterministic era. The agentic era needs its own — one where data readiness is a verdict, evaluation is a discipline, cost is designed in, and governance ships with the system instead of chasing it.

    That’s what this framework is for. It’s a starting point, deliberately: tailor it, argue with it, and let production teach you the rest.

    The best framework is the one your teams actually run — cycle after cycle, until “where does AI earn its keep?” is a question you can answer with evidence.

    Jugal Shah writes about production AI, agentic systems, and enterprise data architecture at aideeva.com, where he publishes The Agentic Enterprise newsletter.