goagentdata

Deep postStep 2: Collect what you need

Your AI is only as good as the data and context you give it

TL;DR. "Garbage in, garbage out" used to be the whole rule. With AI it is no longer enough: correct data is necessary but not sufficient. The second condition is context: written definitions, what was recorded and when, whether history was kept, and what the business means by a number. That context used to live in an analyst's head. An agent has no such head, so the context has to be written down. This week, check three things: is it recorded at all, is the history kept, and is the meaning written down.

What changed about "garbage in, garbage out"?

For decades the rule was simple: false input, false output. AI adds a second way to fail. Entirely correct data can still give a wrong answer, because the data does not say what it means. A column named "status" holds the word "active" in thousands of rows, and nothing in the column tells the AI whether active means paying, logged in, or merely not deleted. The AI picks one and answers in the same calm tone either way.

Until recently, a business analyst carried that context. They knew which statuses to leave out, which month the tracking broke, and which customer was a pilot. When they forgot, they searched old chat threads or asked someone what happened when. The context was real, but it lived in a person. That was always a weak spot: when the analyst left, the context left too. Agents make it impossible to ignore.

An agent cannot ask around. When something is missing, it fills the gap with a reasonable assumption, and it rarely says it made one. A reasonable assumption about your business is still a guess. So the context has to be written where the agent can read it.

I think of it as two necessary conditions: correct data first, context second. Neither replaces the other.

Is a better model the fix?

It helps, but only up to a point. A stronger model explores more: it may list every value in a status column and notice one it did not expect. In short, an agent can discover your data, not your intent. No model can know a rule that was never written down, such as which customers your team treats as pilots. And the strongest models are available to your competitors too. Your data and its context are the parts that are yours to improve.

What does missing context look like?

Imagine a warehouse where "items in stock" is defined as every item that has not exited. It sounds right, and every row behind it is correct. But some items are marked missing, and some are scrapped. Neither group ever exited, so both sit inside the stock count, although they are on no shelf.

The warehouse team knows this. Ask anyone on the floor and they will tell you missing items are gone and scrapped items are written off. The analyst who built the report knew it too, and quietly filtered them out in the spreadsheet. That knowledge just never reached the written definition.

So the data is correct and the knowledge exists. What is missing is the link between them. An agent asked "how many items are in stock?" cannot ask the floor. It counts every item that has not exited, and answers with a confident number that is too high.

Before

Before: the assistant reads the database with no contextA warehouse database feeds an AI assistant directly, with no context on the path. Asked how many items are in stock, the assistant answers at once with a confident number. The count includes the items marked missing or scrapped: they never exited, so they are still counted, and the number is too high. No definition is named.How many items are in stock?WarehousedatabaseNo contextAIassistantAnswerNo definition namedConfident, too highMissing or scrapped: never exited,so still counted

After

After: a context card sits between the data and the assistantThe assistant reads a read-only copy of the same database through a context card with four fields: the definition of in stock (items on a shelf), what it excludes (missing and scrapped items), whether history is kept (yes, with dates) and the owner (head of operations). The same question returns a lower number, because the missing and scrapped items drop out of the count, and a note beside the answer names the definition it used, items_in_stock.How many items are in stock?Read-onlycopyContextDefinitionitems on a shelfExcludesmissing, scrappedHistorykept, with datesOwnerhead of operationsAIassistantAnswerDefinition used:items_in_stockLower, with its sourceMissing or scrapped: still in the data,left out of the count
Before, the assistant counts every item that never exited, missing and scrapped ones included, and answers at once with a confident number that is too high. After, a context card on the path defines in stock and what it excludes, so the same question returns a lower number with the definition it used.

What does context actually include?

Context is four plain things:

  • Definitions. What the business means by "in stock", "customer", "active" or "revenue", and what is excluded.
  • What was recorded, and when. A field added in March says nothing about January. A change in how you record something creates a break in the trend.
  • Whether history was kept. Did the system keep each past state, or does it hold only today's?
  • What a number is for. The decision it informs and the person who owns it.

What can a non-technical founder check this week?

Each check pairs a failure with its guardrail, and none needs code.

1. Is it recorded at all?
Failure: the AI answers a question about something your systems never captured, so it infers or guesses.
Guardrail: for each question you care about, name the system that records it, and the person who owns it.
Check: pick three questions you ask often, such as stock levels, lost customers or sales by channel. For each, ask your team which system holds the answer. If nobody can name one, the AI is guessing. And if nobody knows where the data lives, nobody can take responsibility for it either.

2. Is history kept?
Failure: a record is overwritten when something changes, so the past is gone and any trend is quietly wrong.
Guardrail: keep each change as a new row with a date, or keep a dated copy, instead of editing in place.
Check: ask your developer to show you a record that changed last month. Can you see what it was before? If you only see today's value, history is not kept.

3. Is the meaning written down?
Failure: a number has a definition only in someone's head, so each reader, human or AI, invents its own.
Guardrail: one short written definition for each key number, including what it excludes, stored where your AI can read it.
Check: ask your AI assistant "which definition did you use for that number, and where is it written?" Then open the document it names. If there is no document, or it does not say what the AI claimed, the meaning was its own guess.

What should you do at each stage?

Before launch. Decide what you will need to answer later and make sure the product records it from day one. Write a one page glossary with the one or two numbers that matter, and keep history from the start.

First paying customers. Run the three checks above against the production database, billing and your CRM (where sales tracks customers). Give each key number its own short written definition in a shared folder, and point any AI you use at that folder. Name one person who owns it, even if it takes them an hour a week.

Growing with a first data person. Add review. A change to a definition or to what is recorded gets a named approver and a dated note. The first data person owns the definitions and that change log, because the judgment about which context matters is the hard part.

For your data team

For your data team

This part gets technical. The pattern is simple: treat context as data. Keep it versioned, queryable and next to the thing it describes.

Pick the right slowly changing dimension type, per column. A slowly changing dimension is an attribute that changes now and then, such as an item's status, a customer's plan or a product's price. How you store the change decides what history you can answer later.

  • Type 1, overwrite. Keep only the current value. Right for corrections, like a typo in a name, where the old value was never true.
  • Type 2, new row per change. Each version gets valid_from, valid_to and is_current (the Kimball Group's description is the classic reference). Right for anything you will trend, reconcile or audit: status, plan, location, price. This is the default for business state.
  • Type 3, previous value column. Keeps one step back. Rarely enough, because the second change erases the first.
  • Periodic snapshot. A dated copy of the whole table each day or month. Simple, and good for stock levels and balances, but it misses changes between snapshots.

The choice is per column, not per table. In the warehouse case, the item's name can be Type 1, while its status must be Type 2, or "in stock last quarter" cannot be answered at all.

Give the agent a rule, and enforce it separately. Instruct it to use only documented definitions, to cite the file behind every number and to say when none exists. Enforce the boundary with read-only credentials on a copy of the data, never the live database. A copy that mirrors only the current state still holds no history, so choose the type in the source.

metric: items_in_stock
definition: items physically available in the warehouse
include: status = received and not exited
exclude:
  - status = missing      # never exited, not on a shelf
  - status = scrapped     # written off, never exited
history: item_status is type 2 (valid_from, valid_to, is_current)
recorded_since: 2026-03-01    # example: no status history before this date
owner: head of operations

Check it in 10 minutes

  1. Pick one question you would ask an AI about your business, such as "how many items are in stock?"
  2. Ask your AI and write down the answer.
  3. Ask which definition it used, what it excludes, and where it is written. If the answer is "nowhere", write it today.
  4. Ask whether the system kept last quarter's history. If it only holds today's state, note that gap.
  5. Ask the person who knows the area best for the same answer. If the two differ, the difference is your missing context.

See where your setup stands with the two minute self-check, or read the draft checks your coding agent can run.

Check your setup in 2 minutesAll postsGet new posts by email