Production-ready agents, Prerequisite 0: Before you build: what to have ready

A common piece of advice about agents goes: “It is all about the preparation. Get your data ready and your governance sorted first.” That advice is right, and it is also incomplete. Data and governance are two of the things to settle before you build. There are seven more, and the ones people skip are the ones that most often get projects cancelled.

The numbers make the point. In February 2025 Gartner predicted that through 2026, organisations will abandon 60% of AI projects that are not supported by AI-ready data. In June 2025 it predicted that over 40% of agentic AI projects will be cancelled by the end of 2027, and gave three reasons: escalating costs, unclear business value and inadequate risk controls. None of those reasons is “the model was not clever enough”.

This prerequisite is the checklist I use before any agent code is written. It comes first in the series because every later part assumes these questions already have answers. You need no technical background to read it.

Where are we in the architecture?

This prerequisite does not add a box. It lists what to have ready before any box is built. Part 1.25 walks through the whole picture, layer by layer.

the complete Acme architecture: Maria asks in Gemini Enterprise; the router runs on Agent Runtime behind plugins and Model Armor and calls the marketing and supply agents over A2A; they reach BigQuery and Databricks through Agent Gateway; identity and secrets on the left, models, knowledge and the market watch managed agent for public research on the right, traces, logs and analytics below; above it, shoppers reach Gemini Enterprise for CX, whose conversation insights land in BigQuery, and the Legal industry edition plugs into Gemini Enterprise

What do I need to know first?

A use case is one specific job for the agent, described from the user’s side: who asks what, and what they do with the answer.
A baseline is how the job is done today, measured: how long it takes, how often it is right, what it costs. Without it, nobody can say whether the agent helped.
Data readiness means the agent can use the data correctly: it is defined, findable, clean and fresh.
Data governance means the organisation controls the data: who owns it, who may see it, how sensitive it is, how long it is kept, and a record of who used it.
A risk tier is how much harm a mistake could cause, which decides how much checking and approval the agent needs.

What should be ready before you build?

Nine things, in four groups:

nine things to have ready before you build a production agent, grouped into the case, the data, control and running it: a problem worth an agent, a measure of success with a baseline, data that is ready, governance that is sorted, an identity plan, a risk decision, an eval set, an owner with a budget, and the people who will use it; data and governance are two of the nine

Here is each one, with the question to answer, Acme’s answer, and where the series builds on it.

1. A problem worth an agent

The question: what job does this do, for whom, and is an agent the simplest thing that works? Anthropic’s guidance on building agents recommends finding the simplest solution possible and adding complexity only when needed, which may mean not building an agent at all. A report, a dashboard or a single model call with one tool often does the job.

Acme’s answer: Maria, in marketing, asks questions that need marketing data in BigQuery and supply data in Databricks, such as “Why did Acme Pure underperform in Western Europe last month?”. Today she asks two teams and waits. The questions vary too much for a fixed dashboard, and the answer must combine two owners’ data, so a small set of agents is justified. Part 1 and Part 6.5 come back to this choice.

2. Success, measured

The question: what number will tell us the agent is worth it, and what is that number today? Unclear value is one of Gartner’s three reasons projects are cancelled, and it is usually a missing baseline rather than a missing benefit.

Acme’s answer: three measures, each with today’s value written down before the build: how long a cross-team question takes to answer, how often the answer matches what an analyst would say, and the cost per resolved question. Part 10 turns the second into an eval gate, and Part 13.5 prices the third.

3. Data that is ready

The question: if the agent reads this data, will it get the right answer? Readiness has four parts:

Defined: each measure has one agreed formula and an owner. If marketing and supply calculate OTIF differently, the agent will confidently give two answers.
Findable: tables and columns are described, so a person or an agent can tell otif_pct is a percentage and service_penalty_eur is in euros.
Clean: no silent gaps, duplicates or test rows.
Fresh: you know when data lands, and the agent can say how current an answer is.

Part 13.75 shows the preparation step by step, for tables and for documents.

Acme’s answer: published metric definitions with named owners, described in a semantic layer that the agents read (Prerequisite 2 and Part 2), and governed metric views in Databricks.

4. Governance that is sorted

The question: who owns this data, who may see which parts of it, and can we prove what happened? Readiness and governance are easy to blur, so here they are on one table:

data readiness and data governance are different questions about the same table: readiness asks whether the agent can use the data correctly, such as one agreed OTIF definition, fresh rows and clear column meanings; governance asks who may use it and how that is controlled, such as Unity Catalog grants, sensitive columns, retention and audit

Acme’s answer: each table has an owning team; Unity Catalog grants decide what each person may see; the supply agent queries Databricks as the signed-in user, so those grants apply to every answer (Part 7); and every tool call is logged (Part 9). The decision that matters most: governance lives in the data platform, not in the agent’s prompt.

5. An identity plan

The question: when the agent reads or does something, whose permissions does it use: its own, or the user’s? This decides your whole security design, and it is expensive to change later.

Acme’s answer: each agent has its own identity for Google Cloud, and reads Databricks with the user’s own token, so the agent can never see more than the person asking. Prerequisite 4 introduces the words; Part 7 builds it.

6. A risk decision

The question: what is the worst a mistake could do, and what checks does that demand? Decide which actions the agent may take, which need a person’s approval, and which it must never do. Take legal and privacy advice where the use case touches personal data or regulated decisions. The EU AI Act, for example, sorts AI systems into four levels of risk, with obligations that rise with the level; NIST’s AI Risk Management Framework organises the work into four functions: Govern, Map, Measure and Manage.

Acme’s answer: the agents only read, with one exception: a supply replan job that changes data, which runs only after Sam approves it (Part 9). The design rule follows from this decision: models read and write language, and code makes the decisions.

7. An eval set, before the code

The question: what real questions should the agent answer, and what are the right answers, agreed by the people who own the data? Write them before you build, or you will end up testing the agent against what it happens to say.

Acme’s answer: real questions from Maria and Sam, with the expected numbers taken from the owning teams’ tables, became the golden set; a separate held-out set is kept aside for release decisions (Part 10).

8. An owner and a budget

The question: who runs the agent once it is live, what may it cost, and how do we turn it off? Escalating cost is another of Gartner’s three reasons, and an agent with no owner is the first to be switched off when something goes wrong.

Acme’s answer: a named owning team, a cost ceiling per question enforced while each turn runs (Part 11.5), a monthly estimate (Part 13.5), and a kill switch with a runbook (Parts 9 and 16).

9. The people who will use it

The question: where do users work today, what will change for them, and how will they tell you when it is wrong? An agent that lives in a separate tool nobody opens fails however good it is.

Acme’s answer: the agent is published in Gemini Enterprise, where Acme’s people already work (Part 12), rather than in a new tool. Questions it answers badly become new eval cases (Part 10).

So, is it data and governance, or something else?

Both, and more. Data readiness and governance are necessary: without them, the agent is wrong or unsafe however well it is built. But the reasons agent projects actually get cancelled sit elsewhere on the list: no measured value (2), no risk decision (6) and no owner or budget (8). The model you choose is not on the list at all. It matters, but it is the easiest thing to change later (Part 13).

My view: if you can only do three things before building, write down the baseline (2), collect the eval set with the data owners (7), and decide whose identity the agent acts with (5). Each one is cheap now and very expensive to retrofit, and each forces the conversations, with the business, the data owners and security, that you would otherwise have in the middle of the project.

One honest gap: no checklist makes an organisation ready on its own. In practice some of these are never fully green before the first build; Acme’s held-out set was still small when Part 10 was written. The point is to know which ones are amber, and to decide that on purpose.

Try it: a one-page readiness check

Copy this, fill it in for your own use case, and mark each line green, amber or red. Anything red is a conversation to have before writing code.

1 Problem     Who asks what? Why is an agent simpler than a report or one model call?
2 Success     The metric:            Today's value:            Target:
3 Data ready  Each measure: formula owner, description, quality check, freshness
4 Governance  Data owner, access grants per person, sensitive fields, retention, audit log
5 Identity    Agent acts as: itself / the user / both (for which systems?)
6 Risk        Actions it may take; actions needing approval; actions it must never take
7 Evals       Number of real questions with agreed answers:     Agreed by:
8 Running it  Owner:      Cost ceiling per question:      Off switch:
9 People      Where users work today; how they will give feedback

What can go wrong

Starting with the model. Choosing a model and a framework before the problem and the measure of success are clear. The demo works; nobody can say if it helps.
Governance in the prompt. Telling the agent which data a user may see, instead of letting the data platform enforce it.
Two definitions of one number. The agent quotes both and is right both times, which is worse than being wrong once.
Evals written after the build. They end up describing what the agent does, not what it should do.
No owner. The first incident has nobody to call, and the project is switched off.

What did we learn?

Data readiness and governance are two of nine things to have ready; neither is enough alone.
Readiness asks whether the agent can use the data correctly; governance asks who may use it and how that is controlled.
Gartner’s reasons agentic projects get cancelled are cost, unclear value and weak risk controls, not the model.
Decide the baseline, the eval set and the identity plan before writing code; they are the hardest to add later.
Every item on the list has a part in this series that builds on it.

What comes next?

If Python is new to you, continue with Prerequisite 1: The Python you need to read agent code. Otherwise, Prerequisite 2: The business terms and the data behind the agents shows items 3 and 4 of this list for Acme in detail.

Sources

Opinions are my own. Every fact in this post comes from the public sources linked above. Acme Consumer Brands and its data are fictional.