Context Engineering: why the right information determines the outcome

What a good analyst actually knows

Ask an experienced analyst why margin fell last month and they will come back with an answer. What is interesting is everything they used to get there that nobody ever wrote down.

They know which of the four tables that look similar is the one finance actually trusts. They know that margin here means something specific, and that it is calculated differently in the sales pack. They know the intercompany rows come out before the number means anything. They know last month is not closed yet, so the figure will move. And they know which parts of that data they are allowed to look at, and which they are not.

None of that is in the database. It lives in the analyst.

Which is the work we did on InSight

InSight is our conversational analytics product. You ask it a question in plain language and it answers from your data.

The hard part of building it was never the conversation. It was giving the system the knowledge the analyst carries.

That meant a register of which sources are the trusted ones for which subject, so the system is not guessing between four similar tables. It meant agreed definitions for the terms the business uses, so margin means one thing and can be traced back to how it was calculated. It meant knowing how current each source is, so an answer can say what it is based on. It meant permissions that follow the person asking, so the system cannot show someone data they could not open themselves. And it meant keeping a record of exactly which sources an answer touched, so any number can be traced.

Put that work in and you get an answer an analyst would recognise. Leave it out and you get a fluent, well structured answer that happens to be wrong, which is harder to catch than an obvious error.

That is context engineering. The same applies whether the work is analytics, a customer reply or a report.

You already know this discipline

This is data management wearing different clothes. The principles your data team has argued for over the last decade now help determine whether AI works in your department.

Garbage in, garbage out. A model handed last year's pricing sheet will quote last year's prices, fluently. It has no way of knowing the sheet is stale.

One version of the truth. If three versions of a definition exist, the system will use one of them. It will not tell you which, or mention that the other two disagree.

Accountability. Someone needs to take responsibility for the quality of what goes in, and that works best as part of how you already manage data.

Access and permissions. Deciding what an AI system is allowed to see is a governance decision rather than a technical one. It gets made by default if nobody makes it deliberately.

If your organisation already takes this seriously, you have a head start. If it does not, this is where the gap tends to show, in answers that are wrong in ways nobody catches.

The part that is new

One principle here does not come from data management, and it is easy to miss.

More information is not better information.

Models get less accurate as you give them more to hold. Anthropic describes this as an attention budget that every additional word depletes. So handing over everything just in case, which feels like diligence, can make the result worse.

This is why the work above is about selection rather than volume. Narrowing to the right table, the right definition and the right rows is what makes the answer good, and it is also what makes it affordable. What you send is what you pay for.

What to do about it

Four questions, none of which need a technical answer.

For the work your team relies on, who takes responsibility for whether the information is accurate and current? Where does the single correct version live, and does everyone know? What is permitted to leave which system, and who decided that? And when someone starts a piece of work with AI, do they begin by asking what it needs to know, before they think about how to phrase the request?

Get those four right and much of what looks like a model problem stops being one.

Part of the series that starts with The jargon is complicated. The capabilities underneath are simple. Next: Harness Engineering, making good results the default for everyone.