Beyond Prompt Engineering

About This Paper

Who it is for. Owners, directors and operational leads deciding how to spend time and money on AI, and the people who will have to make whatever they decide actually work. It assumes commercial judgement, not technical background.

What it argues. For work that depends on your own information, getting that information in order can matter more than refining prompts or changing models.

How to use it. Sections 1 to 4 are the argument and the six levels of AI maturity. Sections 5 to 10 are the decisions: a 90 day plan, cost and return, what to measure, governance, the common mistakes and worked sector examples. Sections 11 to 13 are what the models get wrong, how systems fail and where you run them. Sections 14 to 16 are technical detail, optional for most readers. The appendices are a readiness checklist and a list of questions to put to any supplier. Read the appendices first if you are short of time.

What it is not. It is not legal, financial or professional advice. It is not a product recommendation, and no supplier has paid for or reviewed any part of it. Where it describes regulation it summarises publicly available guidance and points at the questions worth asking; it is not a compliance checklist and should not be used as one.

On the figures and the evidence. Where a claim rests on published research it is cited and listed in the references. Where it rests on practitioner judgement it says so, and any working estimate indicates order of magnitude only: anyone building a business case should replace it with figures measured in their own environment. A deliberate attempt was made to source the widely quoted enterprise AI statistics; most could not be sourced credibly. The frequently repeated claims that 80 to 95 percent of AI projects fail, that RAG cuts hallucinations by a specific percentage, or that reranking lifts retrieval quality by a stated margin, trace overwhelmingly to vendor-published material or to secondary reporting of it, not to independent research with disclosed methodology, and section 19 lists the claims left uncited for that reason. Readers should apply the same test to any AI briefing they are given, including those with more impressive-looking numbers than this one.

Currency. Regulatory dates, vendor terms and tool capabilities move quickly. Everything here reflects the position at the date above and should be confirmed against current official sources before any decision rests on it.

1. Executive Summary

Twelve months of prompt training. A library of clever phrasings on the intranet. A dashboard showing adoption is up. And not one line on the P&L that anybody can point at and say: that moved because of this.

If this is your outcome, look beyond staff training. The problem may well be the information the AI can use, not how people word their requests. Most organisations approach AI as a writing problem: train people to phrase requests more skilfully, circulate the prompt library, measure success by whether people are “using it”.

The organisations getting genuine returns have done something different. They have stopped treating the model as the product and started treating context as the product. They invest in getting the right information in front of the model at the right moment, with the right permissions, in a form the model can use.

This paper sets out:

• Why prompt quality has diminishing returns while context quality does not
• The six levels of AI maturity, and what changes at each step
• The components of a working context stack, in plain terms
• The failure modes that quietly destroy trust in these systems
• A practical 90-day sequence that does not require a platform rebuild
• What to measure, what to govern, and what to ask suppliers

The core recommendation is unglamorous: the bottleneck is almost never the model. It is the state of your information. Organisations with clean, accessible, well-permissioned knowledge get disproportionate value from the same models everyone else is using.

2. The Central Argument

A general-purpose language model, on its own, is a reasoning engine with no memory of your business. Unless you attach documents, memory or a connected system, every conversation begins from nothing. Whatever it does not know, it either asks for or invents.

This produces a predictable pattern. Someone asks the AI to draft a client response. The AI produces something structurally competent and factually hollow. The user fills in the gaps by hand. The time saved is modest, so enthusiasm fades.

Now change one variable. The same model, same prompt, but it can see the client’s account history, the last four email threads, the signed terms, the current pricing sheet, and twenty previous letters written in the house style. The output goes from a template to a near-final draft.

Nothing about the model changed. The prompt barely changed. What changed was the information available at the moment of generation.

This is the whole argument, and it scales:

Prompts specify intent. Context supplies the facts. Infrastructure makes it repeatable.

The third clause is the one most organisations skip. A single impressive result from a carefully assembled prompt is a demonstration. A system that produces that result every time, for every member of staff, without anyone assembling anything, is an operational asset.

The economics of the shift

Models improve on a schedule you do not control and did not pay for. Model improvements often reach you through the tools you already pay for, but they cannot put your business information in order for you. Context, by contrast, is the part you own, the part competitors cannot copy, and the part that compounds.

Investment in prompt technique depreciates with each model release, because newer models increasingly infer what older ones had to be told. Investment in organised, retrievable, permissioned knowledge appreciates, because every future model will use it better than the current one does.

That asymmetry should drive where the budget goes.

3. Why Prompt-Led Adoption Plateaus

Prompt engineering is real and it does help. Structured output requests, worked examples, explicit constraints and step-by-step decomposition all measurably improve results. The problem is not that prompting is useless. The problem is where the ceiling sits.

The ceiling is set by information, not phrasing. No arrangement of words causes a model to know your margin structure. If the fact is not in the prompt, not in the retrieved documents, and not in the model’s training data, it does not exist. Elaborate prompting around a missing fact produces a confident, well-structured guess, which is worse than an obvious blank.

The burden falls on the user, every time. Prompt-led usage means the human supplies the context manually at each interaction. That is a tax on every task, paid forever, and it is exactly the work that scales badly. It also means quality tracks the individual. Your best operator gets excellent output; everyone else does not.

Nothing accumulates. A brilliant prompt used on Tuesday teaches the organisation nothing. Close the window and the knowledge is gone. There is no asset at the end of the year.

Models are absorbing the technique. Behaviours that once needed explicit instruction, such as reasoning through a problem before answering or asking clarifying questions, are increasingly default. The instructions that mattered in 2023 are largely redundant now. This trend will continue.

Better prompting can improve results, but it cannot supply missing business information. That is where context and infrastructure matter. Most training budgets are being spent entirely inside the first bracket.

4. The Capability Ladder: Six Levels of AI Maturity

Each level builds on the one below. Skipping levels is possible but usually produces fragile results, because the higher levels depend on the discipline established lower down.

Level 1: Ad hoc prompting

The AI is used as a smarter search engine or a writing aid. Every task starts blank. All context is typed by hand.

• Typical use: summarise this, rewrite that, explain this concept
• Value: real but modest, concentrated in drafting and comprehension
• Effort to reach: none
• Limitation: output quality varies enormously by user

Level 2: Structured prompting and reusable patterns

Staff learn to specify audience, tone, format and constraints. The organisation builds a small library of tested prompts for recurring tasks.

• Typical use: standard letters, meeting summaries, first-draft copy
• Value: consistency improves, variance between staff narrows
• Effort to reach: low, a few days of training and curation
• Limitation: the user still supplies all facts

Level 3: Persistent memory and standing instructions

The system retains stable preferences: house style, terminology, formatting conventions, recurring projects, who the user is and what they do.

• Typical use: anything where the same background would otherwise be re-typed
• Value: removes repetitive setup, improves consistency across sessions
• Effort to reach: low to moderate, mostly a matter of using the features properly and deciding what is worth storing
• Limitation: memory holds preferences well and facts poorly; it is not a substitute for a document store, and stale memory is actively harmful

Level 4: Document context and retrieval

The AI can search your own material and pull the relevant passages into its working context. Suppliers call this retrieval-augmented generation, or RAG. The point for you is that answers can come from your own material.

• Typical use: answering from policies, contracts, manuals, historic correspondence, technical specifications
• Value: the single largest step change for most organisations, and the main defence against fabrication when retrieval is well configured; poorly configured retrieval can make matters worse rather than better
• Effort to reach: moderate; the work is mostly in preparing and organising the source material, not the technology
• Limitation: answer quality is capped by document quality; three versions of a policy in circulation produces three inconsistent answers

Level 5: Connected live systems

With permission, the AI reads from the systems where work actually happens: email, calendars, file storage, CRM, ticketing, accounting, databases.

• Typical use: “what is outstanding on this account”, “prepare for tomorrow’s meeting”, “reconcile these two reports”
• Value: moves from static knowledge to current state
• Effort to reach: moderate to high; the difficulty is permissions and identity, not connection
• Limitation: every connector widens the blast radius of a mistake; this is where governance becomes non-negotiable

Level 6: Agentic execution

The AI completes multi-step work rather than producing text about it: drafting and sending, updating records, running analyses, monitoring for changes, producing recurring reports.

• Typical use: compliance sweeps, data reconciliation, monitoring, routine report production, first-line triage
• Value: this is where the return becomes non-linear, because you are removing whole tasks rather than accelerating them
• Effort to reach: high, and it requires everything below it to be reliable first
• Limitation: unattended action needs audit trails, reversibility and defined limits; reliability compounds against you, because an agent that is 95 percent reliable at each of ten dependent steps completes the whole chain about 60 percent of the time

A note on sequence. Level 4 is the highest-return step for most organisations and it is available without any custom engineering, using mainstream tools. Level 6 is the most discussed and the most frequently attempted prematurely. Agents built on unreliable retrieval do not fail obviously. They fail plausibly, which is worse.

5. A 90-Day Implementation Path

This sequence assumes no dedicated AI function and no platform rebuild. It is designed to produce a defensible result rather than a demonstration.

Days 1 to 14: Identify the real target

Do not start with technology. Start by finding the tasks where people repeatedly assemble the same context by hand.

• Identify the five most repeated knowledge tasks in the business
• For each, record where the information currently lives, how long assembly takes, and who does it
• Select one task with high frequency, contained scope and a verifiable output
• Write down what “working” means in measurable terms before building anything

Deliverable: a one-page definition of the first use case, with a success measure.

Days 15 to 30: Prepare the information

This is the majority of the real work and it is not technical.

• Assemble the documents the chosen task depends on
• Establish one authoritative version of each; remove or archive the rest
• Add basic metadata: date, owner, status, scope
• Audit the permissions on the repository as it will actually be exposed
• Build the evaluation set: thirty to fifty real questions with agreed correct answers

Deliverable: a clean, permissioned, dated corpus and a test set.

Days 31 to 60: Build and measure

• Connect the corpus using mainstream tooling; resist custom engineering at this stage
• Require attribution on every answer
• Run the evaluation set and record the baseline
• Put it in front of three to five real users doing real work
• Iterate on retrieval configuration, chunking and instructions; re-run the evaluation after each change

Deliverable: a measured system with a known accuracy rate and a change log.

Days 61 to 90: Extend deliberately

• Add the second use case, reusing what was built
• Connect one live system if the use case genuinely requires current state
• Document what worked, including the configuration and the instructions
• Establish the governance minimum: who may connect what, review requirements, retention, escalation
• Decide explicitly whether to progress toward agentic execution, based on measured reliability rather than enthusiasm

Deliverable: a repeatable pattern, documented, with governance attached.

What to avoid in the first 90 days

• Buying a platform before understanding the use case
• Starting with agents
• Connecting everything at once
• Organisation-wide rollout before one team is getting reliable value
• Any project whose success measure is “adoption”

6. Cost, Effort and Return

Where the effort actually goes

In a first deployment, effort usually falls into five areas. Document preparation and cleanup is normally the largest; measure the rest in your own pilot:

• Document preparation and cleanup
• Permissions and access review
• Retrieval configuration and tuning
• Evaluation and iteration
• Model and interface work

The model, which is what most of the conversation is about, is usually the smallest part.

These proportions are practitioner judgement based on observed deployment patterns, not results from a controlled study. No credible quantified breakdown of deployment effort was found in the published literature. Treat them as directional, and replace them with measured data in any business case.

Where returns come from

Value arrives in three forms, in ascending order of size and difficulty:

• Time saved on existing tasks. Easy to measure, modest in size, often significant on drafting-heavy work, but it varies by task, tool and person.
• Tasks removed entirely. Larger, requires Level 5 or 6, applies to routine reporting, reconciliation and monitoring.
• Work that was not previously viable. Largest and least predictable. Analysis nobody had time to do, monitoring nobody had capacity for, responsiveness that was previously impossible.

Most business cases are built on the first category, which understates the return but is defensible. The third category is where the competitive difference usually shows up and it is almost never in the original business case.

The honest risk

The main financial risk is not overspending on models. Inference costs are falling and are rarely material at business scale. The risk is spending twelve months and significant internal effort building a system on disorganised information, producing something that works in demonstration and fails in use.

The mitigation is the sequence in section 5: small scope, real users, measured accuracy, extend only from what is working.

7. Measurement: What to Actually Track

Adoption metrics are the wrong instrument. Seat counts and message volumes tell you that people are using something, not that it is working.

Track instead:

Accuracy on the evaluation set. Percentage of known-answer questions answered correctly, with correct attribution. Recorded after every material change. This is the primary quality metric.

Rework rate. Proportion of outputs that required substantial human correction before use. Falling rework is the clearest signal of a maturing system.

Time to completion, before and after. Measured on the specific task, not estimated in aggregate.

Escape rate. Errors that reached a client or a decision. Should be near zero and monitored actively, since it is the metric that determines whether the programme survives its first bad week.

Coverage. Proportion of questions the system can answer from your own material rather than general knowledge. Directly reflects corpus quality.

Refusal rate. How often the system correctly declines. Include questions your documents cannot answer; a system that never declines those is guessing.

Report these monthly, in one table. Six numbers is enough to manage a programme.

8. Governance, Security and Compliance

8.1 The minimum framework

Regardless of size, an organisation using AI on business information needs written answers to:

• Approved tools. Which services may be used with company information, and which may not.
• Data classification. What categories of information may be processed by which tools.
• Connector authorisation. Who can connect a business system, and what review is required first.
• Review requirements. Which outputs require human sign-off before use, especially anything client-facing, financial or regulatory.
• Retention and training. What the provider does with your inputs, and for how long.
• Audit. What record exists of what the AI was asked, what it retrieved and what it produced.
• Incident response. What happens when the AI surfaces something it should not have, or acts wrongly.

This is a two-page document for most organisations. Its absence is what turns a manageable mistake into a reportable one.

8.2 Data protection

Under UK GDPR and its EU equivalent, processing personal data through an AI service requires the ordinary discipline: lawful basis, an appropriate processor agreement, clarity on international transfers, and a data protection impact assessment where processing is likely to be high risk. Systems that retrieve broadly across internal repositories are more likely to meet the high-risk threshold than single-purpose tools, because the scope of personal data they may touch is wider and less predictable.

Two points that are specific to AI and often missed:

• Training on inputs. Business and enterprise tiers of major providers generally do not train on customer inputs by default, while consumer tiers may. This distinction is contractual and it changes. Verify it for your specific plan rather than assuming.
• Retrieval widens scope. A connector does not just give access to the documents you had in mind. It gives access to everything in that repository that the user can see. The scope of the processing is the scope of the permissions, not the scope of your intention.

The ICO’s Guidance on AI and data protection is firmer than it is often reported to be. It states that in the vast majority of cases the use of AI will involve a type of processing likely to result in high risk, and will therefore trigger the legal requirement to carry out a DPIA. It still requires case-by-case assessment against the defined criteria, and sets no bright-line rule that retrieval-based systems always need one.

In practice, internal email and document repositories routinely contain personal data, and often special category data such as health information or trade union membership, which carries stricter lawful basis requirements and makes both a DPIA and proper advice more pressing. Broad-retrieval systems over such repositories will frequently raise exactly the issues the ICO associates with likely high risk. That is an application of the guidance rather than a quotation from it.

One distinction is worth holding onto, because both the ICO and the EU AI Act treat the two differently: AI that advises a human decision-maker is generally treated more lightly than AI that makes or substantially influences a decision about a person on its own, provided the human involvement is real. That alone does not settle whether a Data Protection Impact Assessment is needed. Where AI informs decisions about individuals, the risk of bias, unfair treatment and disparate impact needs assessing alongside the data protection questions.

This section is indicative and is not legal advice. Treat it as a set of prompts for a DPIA and for a conversation with whoever advises you.

8.3 Regulatory direction

European Union. The EU AI Act is Regulation (EU) 2024/1689, adopted 13 June 2024 and published in the Official Journal in July 2024. It is live EU law, phased in by stage: the prohibitions and general provisions applied from 2 February 2025, further provisions from 2 August 2025, and further obligations from 2 August 2026. Following amendments to the timetable, the main requirements for high-risk AI systems in the sensitive areas listed in Annex III apply from 2 December 2027, and for high-risk systems built into regulated products (Annex I) from 2 August 2028. Confirm these dates against official EU guidance before relying on them.

It reaches organisations outside the EU that place AI systems on the EU market, put them into service there, or whose system outputs are used within the Union. A UK business running internal systems for UK-only use is generally outside scope, but only for as long as that remains factually true of its systems and their outputs. If either crosses into the EU, scope follows.

United Kingdom. The UK has not enacted a horizontal AI statute. Regulation is delivered through existing regulators, principally the ICO for data protection, alongside the FCA, CMA, Ofcom and sector bodies, under the pro-innovation principles set out in government policy papers. Data protection reform has continued through separate legislation, but none of it is an AI Act equivalent.

Both positions continue to develop, and the phasing dates in particular should be confirmed against EUR-Lex before they are relied upon.

For most business deployments of the kind described here, the practical implications are transparency about AI use, human oversight of consequential decisions, and record-keeping. Organisations in regulated sectors, or making decisions affecting individuals’ rights, employment, credit or access to services, should take specific advice, as the obligations are materially heavier. Anyone acting on this section should confirm the current position, as the regulatory landscape is moving quickly.

8.4 The disclosure question

Decide early whether and how you tell clients that AI is involved in work delivered to them. There is no universal answer and the correct one varies by sector and contract. The failure mode is having no position and being asked.

9. The Ten Most Common Mistakes

• Treating it as a training problem. Prompt courses for staff while the underlying information stays disorganised.
• Buying the platform first. Selecting a vendor before defining a use case, then shaping use cases around what was bought.
• Connecting everything immediately. Maximum blast radius, minimum understanding, no way to attribute failures.
• Skipping the permissions audit. Assuming existing access controls were designed for a world where everything is discoverable by meaning.
• No evaluation set. Managing quality by anecdote, unable to tell whether changes helped.
• Feeding the model dirty data. Multiple document versions, no dates, no ownership, contradictory sources, and then blaming the model for contradictory answers.
• Starting with agents. Building autonomous execution on unmeasured retrieval.
• No attribution. Users cannot verify, so they either trust blindly or abandon the tool.
• Confusing memory with knowledge. Storing volatile facts as permanent ones and never reviewing them.
• Measuring adoption. Optimising for usage rather than outcome, and declaring success while nothing changes.

10. Worked Sector Examples

Professional services

Task: responding to a client query on a matter with three years of history.

Without context: the fee earner locates the file, reads back through correspondence, checks the engagement terms, drafts a reply. Forty to sixty minutes.

With context: the system retrieves the correspondence chain, the engagement letter and the relevant precedent documents, and produces a cited draft in house style. The fee earner verifies against the citations and amends. Ten to fifteen minutes.

Prerequisites: matter files organised and permissioned, house style captured, attribution mandatory, human sign-off before sending.

Digital marketing and affiliate operations

Task: checking campaign compliance across multiple merchant programmes with differing terms.

Without context: the operator opens each programme’s terms, checks current ad copy against them by hand, repeats per merchant. Hours, done infrequently, with drift between checks.

With context: current terms per programme are retrievable, live ad copy is queryable, and the system reports only the discrepancies. Historic breach correspondence informs what to watch. The check becomes weekly rather than occasional.

Prerequisites: current terms held per programme with dates, structured access to live campaign data, defined rules on what constitutes a breach, human decision on any change.

Operations and finance

Task: monthly reconciliation between two systems that do not agree.

Without context: export both, compare in a spreadsheet, investigate each variance manually.

With context: the system queries both sources directly, applies the reconciliation rules, and presents only the exceptions with the underlying records attached.

Prerequisites: structured access rather than document access, reconciliation rules written down explicitly, and no automated adjustment without human approval.

Sales and account management

Task: preparing for a client meeting.

Without context: the account manager checks the CRM, scans recent email, looks up the last order, and reviews the open ticket. Twenty minutes across four systems.

With context: a single brief covering account state, recent correspondence, open issues, order history and any changes since last contact.

Prerequisites: CRM hygiene, connected email and ticketing, permissions scoped to the account manager’s own accounts.

11. What the Models Get Wrong, and How to Contain It

Everything above assumes the model behaves. It mostly does, and then occasionally does not, in ways specific and predictable enough to design around. What follows is not a list of reasons to avoid AI. It is the list of things to build controls for.

Read the detail on each failure, and how to contain it

11.1 It invents things

The failure everyone has heard of, and still the most consequential. A model asked for something it does not know will produce a fluent, plausible, well-structured answer that is false. It does not hedge, because it has no internal sense of the difference. Invented case law, invented statistics, invented product features and invented citations complete with authors and page numbers are all routine.

Contain it by: grounding answers in retrieved documents rather than the model’s general knowledge; requiring attribution so every claim can be traced; asking it to quote the source passage rather than summarise it; verifying anything that carries consequence. Treat an uncited factual claim as unverified by default.

11.2 It forgets

Two separate problems that get confused.

Within a long conversation, earlier material fades. Instructions given twenty exchanges ago get quietly dropped. Information in the middle of a long input receives less attention than material at the start or end (Liu et al., 2023).

Between conversations, it retains nothing unless a memory feature is switched on and working. Yesterday’s careful setup is gone.

Contain it by: starting a fresh conversation when a thread gets long or drifts, and restating the essentials rather than assuming they survived; putting critical instructions at the end of a long input rather than buried in the middle; keeping standing information in a saved file or memory feature rather than in conversation history; and treating anything the model agreed to earlier as unreliable unless restated.

11.3 It is poor at arithmetic and exact recall

It predicts plausible text, which is a different operation from calculating. It will produce numbers that look right and do not add up, miscount items in a list, and lose precision on long figures. Asked to extract every instance of something from a long document, it will find most and quietly miss the rest.

Contain it by: never trusting unverified arithmetic; giving it a tool that actually computes rather than asking it to do the sum in prose; querying structured data directly rather than describing it; and treating “find all instances of X” as a first pass to be checked, not a complete answer.

11.4 It sounds identical whether right or wrong

There is no tonal difference between a well-grounded answer and a fabricated one. Human experts hedge, qualify, or say they will check. The model’s default register is uniform confidence, which removes the cue people normally use to calibrate trust.

Contain it by: instructing it explicitly to state uncertainty and to say when it does not know; treating fluency as no evidence at all; and making “what is this based on” a standard follow-up.

11.5 It agrees with you

Push back on a correct answer and it will often fold, apologise and produce a worse one. This is a known tendency in systems trained on human approval, and it is most dangerous exactly where you wanted a second opinion. It will also accept a false premise embedded in your question and build on it.

Contain it by: asking neutrally rather than leading; asking it to argue the opposing case; being suspicious rather than reassured when it changes its answer under pressure; and asking directly whether the premise of your question is sound.

11.6 It does not know what happened recently

Training data has a cut-off. Without a search tool or a connected system, it does not know about a price change, a company failing, a rule changing, or an event last month. It may answer anyway, from outdated knowledge, without flagging that the position may have moved.

Contain it by: enabling search or connectors for anything time-sensitive; asking what its knowledge cut-off is when it matters; and never relying on it unaided for prices, regulations, availability or current events.

11.7 It handles negative instructions badly

“Do not mention the discount” frequently produces a response mentioning the discount. Instructions phrased as prohibitions are followed less reliably than instructions phrased as requirements.

Contain it by: stating what you do want rather than what you do not; and checking output specifically against any prohibition that matters.

11.8 It is not consistent

Ask the same question twice and you may get materially different answers. This is inherent rather than a fault. It matters when the output feeds a process that expects stability, and it is why judging quality by impression is unreliable.

Contain it by: testing against a fixed question set rather than anecdote; and not building a process that assumes identical output from identical input.

11.9 The things it cannot know at all

It cannot know what was never written down. Why a client is difficult, the informal arrangement nobody recorded, a supplier’s real reputation, why last year’s decision went the way it did. Anything held in people’s heads is invisible to it, and it will not tell you so. It will fill the gap.

Contain it by: recognising that context solves the documented gap and not the undocumented one; and keeping a human in any decision where the unwritten history is what matters.

11.10 What this paper does not cover

Two live issues sit outside its scope and are worth naming rather than quietly omitting. The first is the provenance of model training data and the copyright questions attached to it, which remain contested and litigated. The second is bias and fairness in outputs, which matters most where AI informs decisions about people. Anyone deploying at scale, or in a context touching individuals’ rights, should take specialist advice on both.

11.11 The pattern behind all of these

Almost every failure above shares a shape: the model produces something plausible where it should produce nothing. It has no reliable mechanism for declining. That is why the controls reduce to a short list.

• Ground answers in real sources rather than recall
• Require attribution, always
• Verify anything with a consequence attached
• Keep a human between the output and anything irreversible
• Test against known answers rather than impressions

A system built this way still makes mistakes. The difference is that you find them.

12. How These Systems Fail, and How to Spot It Early

Failures in context systems are rarely dramatic. They are quiet, plausible and cumulative. The following are the recurring ones, with their symptoms.

Retrieval misses. The right document exists but is not returned, so the model answers from general knowledge, fluently and wrongly. Symptom: answers that are technically reasonable but not what your policy actually says. Detection: your evaluation set, run regularly.

Stale sources. Superseded material is retrieved alongside current material and the model has no basis to prefer either. Symptom: inconsistent answers to the same question. Detection: attribution, which makes the source visible.

Permission leakage. Semantic search surfaces material that was technically accessible but practically buried. Symptom: by the time you have one, it is an incident. Detection: audit before connecting, not after.

Context dilution. Too much marginally relevant material passed in, degrading attention on what matters. Symptom: answers that address the periphery of the question and miss the centre. Detection: compare output quality with a deliberately narrowed context.

Memory drift. Stored facts that were true once and are now wrong. Symptom: confident answers about a state of affairs that ended months ago. Detection: periodic review of what is stored.

Silent degradation after a model change. Behaviour shifts on upgrade, usually improving overall while regressing in specific places. Symptom: none, without testing. Detection: the evaluation set again.

Automation complacency. Reviewers stop reviewing because the output has been good for six weeks. Symptom: errors reaching clients. Detection: deliberate spot-checking, and rotating who reviews.

The thread running through this list: the same evaluation set catches most of it. Thirty to fifty real questions with known answers, run after every material change. It is the cheapest quality control available and it is almost universally skipped.

13. Where You Run It

The same model behaves very differently depending on the surface you use it through. This is under-discussed and it changes what is possible more than most people expect.

13.1 The three surfaces

Chat in a browser. You bring everything to it: paste the text, upload the file, describe the situation. It hands work back as text you copy out. Nothing on your machine is touched. Lowest capability, lowest risk, and correct for a great deal of individual use.

An application on your computer with access to your files. The difference is direction. It can open files where they actually live, work on them, and save them back. You stop being the courier between your documents and the AI. For most small businesses and individuals this is where the practical step change happens.

Agentic tools that work through a whole task. Desktop and command-line tools that move through folders, run code, transform data and carry out multi-step work against a defined goal. Originally built for software development, now increasingly used for ordinary document and data work. Highest capability, and it demands deliberate scoping.

13.2 What this changes in practice

Take a customer database export carrying duplicates, inconsistent formatting and dead records.

• In a browser chat, you paste a sample and it tells you how to clean it, or writes you a script. You then do the work.
• In an application with file access, you point it at the file. It opens it, finds the duplicates, normalises the formatting, flags the records it is unsure about, and writes a cleaned version alongside the original. You review the changes.
• With an agentic tool, it does that across a folder of exports, applies the same rules consistently, produces a summary of what changed, and can be re-run next month.

Same model. The difference is entirely in what it can reach.

The same distinction applies to a folder of quotes you want kept consistent, a set of spreadsheets needing the same correction, or a document you want revised in place rather than retyped.

13.3 Choosing

Use the least powerful surface that does the job.

• Browser chat for drafting, thinking, questions, and anything involving material you would rather software did not touch directly.
• Desktop application with file access when you notice yourself repeatedly copying content out of files and pasting results back in. That copying is the signal.
• Agentic tools when the task is genuinely multi-step and repeatable, and you have a way to check the result. Not before.

13.4 The trade-off to be honest about

Capability and blast radius rise together. A browser chat is less likely to change your files, but people can still share something sensitive or act on a wrong answer. An application with file access can overwrite the wrong file. An agent working through a folder can do it repeatedly before anyone notices.

Three rules make this manageable:

• Point it at a copy, or work somewhere with version history, until you trust it.
• Give it the narrowest folder that will do, not your whole drive.
• Review the changes before accepting them, exactly as you would review a new colleague’s first week.

None of this is exotic. It is the discipline you would apply to anyone new with access to your files.

Technical detail, optional reading. Sections 14 to 16 explain the parts of a context system, the discipline of managing context, and connectors and agents. Read them if you are choosing or building a system; skip them if you are deciding whether to start.

14. Anatomy of a Context Stack

The components below are not all required. Most organisations need three or four of them. The list is here so that vendor conversations are legible.

14.1 The model

The reasoning engine. Claude, GPT, Gemini and others. Frontier models are broadly comparable for most routine business tasks, and in those cases the differences that matter in practice are context window size, tool-use reliability, cost per unit of work, and data handling terms rather than raw benchmark scores. Specialised work - code against a particular stack, less common languages, safety-critical judgement - does show real differences between models, so test rather than assume.

Practical guidance: do not over-engineer model selection. Choose on commercial terms, data residency and integration support. Assume you will change model within eighteen months, and avoid architectures that make that painful.

14.2 The document store and retrieval layer

Why you care: this is the component that decides whether the AI quotes your current policy or a draft from 2019 that happened to be phrased more clearly.

Your material, prepared so it can be searched by meaning rather than by exact wording. This usually means a search that finds documents by meaning as well as by exact words; combining the two often works better than either alone.

What determines quality:

• Source hygiene. One authoritative version of each document. Superseded material removed or clearly marked, not left in the same folder.
• Chunking. How documents are split for retrieval. Get this wrong and the system spends its day quoting you half a clause with the qualifying sentence cut off. Split too small and context is lost; too large and irrelevant material crowds out the useful parts. Splitting on natural structure such as sections and clauses beats splitting on fixed character counts.
• Metadata. Date, owner, document type, version, jurisdiction, applicable entity. This is what allows the system to prefer current material over historic and to filter by relevance before ranking.
• Reranking. A second sort that puts the most relevant results first. Ask suppliers to show that it improves answers on your own material.

The point most often missed: retrieval quality is a document management problem wearing a technology costume. Organisations with disciplined document control get good results quickly. Organisations with fifteen years of undifferentiated shared drive get poor results and blame the model.

14.3 Memory

Durable storage of preferences, standing facts and working state across sessions.

Memory and retrieval solve different problems and should not be confused. Memory holds a small number of stable, personal facts: how this person writes, what they are working on, what they have already decided. Retrieval holds a large body of shared, versioned material.

Failure mode to watch: memory that records a temporary situation as a permanent fact. A note that a project is “in review” becomes wrong within a fortnight and then quietly poisons every subsequent answer. Memory needs review and pruning like any other record.

14.4 Structured data access

Spreadsheets, databases and reporting systems queried directly rather than summarised into prose first.

This matters more than it sounds. Language models handle numbers poorly when the numbers arrive as narrative text and handle them well when they can query a source and compute against it. Any use case involving figures, reconciliation or aggregation should be built on structured access, not on documents describing the figures.

14.5 Knowledge graph

An explicit map of entities and the relationships between them: which client belongs to which group, which contract governs which service, which supplier feeds which product line.

Honest assessment: valuable in specific circumstances, oversold in general. If your questions are mostly of the form “what does the policy say”, retrieval alone is sufficient and a graph is expensive ceremony. If your questions require traversing relationships, such as “which of our contracts are exposed if this supplier fails”, a graph earns its cost. Most mid-sized organisations do not need one in year one.

14.6 Tools and connectors

The interfaces that let the model retrieve live information and take action: search, code execution, file operations, and integrations with business systems.

The material shift here is standardisation. Rather than bespoke integration per system per vendor, the major providers are converging on standard connector protocols, most prominently the Model Context Protocol. Convergence is not completion: plenty of proprietary integrations remain in the market. The practical consequence is that the same systems can be used with different AI tools more easily, and switching providers should mean less rebuilding, though compatibility still needs checking. When evaluating suppliers, ask whether their integrations are standards-based or proprietary. The answer determines how trapped you are in three years.

14.7 Permissions and identity

Why you care: this is the one that turns into an incident rather than a disappointment.

The layer determining what each user’s AI is allowed to see.

This is the component most often deferred and least often survivable when deferred. The requirement is that the AI inherits the permissions of the person asking, enforced at retrieval time, not filtered afterwards. A system that retrieves broadly and then attempts to redact is a data breach waiting for its moment.

The classic incident is not exotic. Someone connects the AI to the shared drive. The shared drive contains a folder of salary reviews that was always technically visible and never practically discoverable. Search by meaning removes the practical obscurity. The permissions were wrong for years; the AI simply made that fact operational.

Recommendation: audit permissions on any repository before connecting it, not after. Assume the AI will find everything it is allowed to find.

14.8 Evaluation and observability

Why you care: without it you cannot answer “is this better than last month” with anything but a shrug, and you will not notice the day it starts getting worse.

The means of knowing whether the system is working.

Most deployments have no answer to “is this better than last month” beyond anecdote. The minimum viable version is a set of thirty to fifty real questions with known correct answers, run after every material change, with results recorded. This costs a day to build and is the difference between managing a system and hoping about one.

15. Context Engineering as a Discipline

If prompt engineering is phrasing the request, context engineering is deciding what the model sees. It is the more consequential skill and the one with almost no training market around it.

15.1 Relevance beats volume

A larger context window is not an instruction to fill it. Model attention degrades across long contexts, and performance on information placed in the middle of a very long input is measurably worse than on information at the start or end. This is the “lost in the middle” effect, demonstrated across multi-document question answering and retrieval tasks by Liu et al. (2023) and confirmed by subsequent work on positional bias (Hsieh et al., 2024). Twelve highly relevant paragraphs outperform two hundred marginally relevant ones, and cost less.

The discipline is aggressive selection: retrieve broadly, rank hard, pass through only what earns its place.

15.2 Freshness and precedence

Every retrievable document needs a date and a status. The system needs explicit rules about which source wins when two conflict. Without this, the model has no basis for preferring the current policy over the 2019 draft that happens to be phrased more clearly, and it will sometimes prefer the wrong one.

15.3 Structure survives retrieval; layout does not

Information encoded in visual layout, such as a table whose meaning depends on merged cells and colour coding, degrades badly when extracted. Information encoded in explicit structure, such as headings, labelled fields and consistent terminology, survives.

This has a practical implication for how the organisation writes things going forward. Documents written to be machine-readable, meaning clearly headed, consistently termed and explicit about their own scope and date, are more useful to both AI and people.

15.4 Attribution as standard

Why you care: it is the difference between staff who trust the system because they can check it, and staff who trust it blindly until the first visible error and then never touch it again.

Any system answering from internal documents should cite which document and which section. This is not a nicety. It is the mechanism by which users verify, the mechanism by which errors get traced to their source, and the single largest driver of whether staff trust the output. Systems without attribution are trusted uncritically for a while and then abandoned entirely after the first visible error.

15.5 Designed refusal

The system should be able to say that it does not have the information. This requires deliberate design, because the default behaviour of a fluent model is to produce a fluent answer. A system that answers everything is not more capable than one that declines occasionally. It is less trustworthy, because you cannot tell which answers are grounded.

15.6 Treat context as versioned

The instructions, retrieval configuration and standing information that shape outputs are effectively production configuration. They should be written down, versioned and changed deliberately. Organisations that let these accumulate informally end up unable to explain why last month’s output was better.

16. Connectors, Agents and the Model Context Protocol

16.1 What changed

Until recently, connecting AI to a business system meant a bespoke integration, specific to one AI vendor and one target system. Ten systems and two AI vendors meant twenty integrations to build and maintain.

Standard connector protocols collapse this. A system exposes its capabilities once, in a defined format, and any compliant AI tool can use them. The Model Context Protocol is currently among the most widely adopted of these across major vendors. The commercial significance is portability: standards-based integration substantially reduces vendor lock-in.

16.2 What agents actually are

An agent is a model given a goal, a set of tools, and permission to loop: decide, act, observe the result, decide again, until done. That is the entire concept. The sophistication is in the constraints, not the loop.

16.3 Where agents genuinely work now

The pattern that succeeds is narrow scope, defined tools, verifiable output, human review at a defined point.

Reliable current applications include:

• Research and synthesis across many sources, with citations
• Data reconciliation between systems, flagging discrepancies for human decision
• Monitoring for defined conditions and alerting
• Routine report production from stable sources
• First-line triage and routing
• Code and document review against a checklist

16.4 Where they do not yet

Open-ended objectives across many systems with no checkpoint. The arithmetic is unforgiving, and it is arithmetic rather than an empirical finding: assuming for simplicity that steps are independent and equally reliable, 95 percent per step over ten dependent steps yields roughly 60 percent end-to-end success, and twenty yields around 36 percent. Real chains are messier in both directions, but the direction of travel is the point. Published measurement of agent reliability on real multi-step business tasks remains thin, which is itself a reason for caution.

The failures are not random noise either. They are plausible, internally consistent, and require domain knowledge to spot.

Design rule: insert a human checkpoint before any irreversible action. Sending, paying, deleting and publishing are irreversible. Drafting, analysing and flagging are not. Automate freely up to the checkpoint; automate past it only when you have measured error rates on real work over a meaningful period.

17. Where This Is Heading

Three directions look reasonably clear from the current position.

Context becomes the differentiator, not the model. As frontier models converge in capability, the variable that distinguishes outcomes is what each organisation can put in front of them. This favours organisations with disciplined information management, which historically has been an unglamorous and underfunded function.

Integration standardises. The shift to common connector protocols means the integration layer becomes commodity infrastructure rather than a competitive moat for vendors. The practical benefit is portability. Organisations should be actively preferring standards-based integration on that basis.

Autonomy extends by increments, not by leap. Agents will handle progressively longer chains of work, but the constraint is compounding reliability, which improves gradually. The organisations that benefit will be those with the measurement discipline to know when a task has crossed the threshold from supervised to unsupervised. Those without it will either automate too early and get hurt, or too late and be overtaken.

The underlying claim is stable across all three: the model is the commodity, and the context is the asset.

18. Glossary

Agent - An AI system given a goal and tools, able to take multiple actions in sequence and adjust based on results.

Attribution - Citing which source document and section an answer came from.

Chunking - Splitting documents into retrievable segments. Method materially affects retrieval quality.

Connector - An integration allowing AI to read from or act within a business system.

Context window - The maximum amount of information a model can consider in one interaction.

Embedding - A numerical representation of text capturing its meaning, enabling search by concept rather than keyword.

Evaluation set - A fixed collection of test questions with known correct answers, used to measure system quality over time.

Hallucination - Confident generation of false information. Grounding answers in retrieved sources reduces it substantially without eliminating it, a direction consistent with published evaluations (Béchard and Marquez Ayala, 2024), though the magnitude is setup-specific and does not generalise to a headline percentage.

Knowledge graph - A structured map of entities and their relationships.

LLM - Large language model. The reasoning engine.

MCP (Model Context Protocol) - An open standard for connecting AI systems to external tools and data sources.

RAG (Retrieval-Augmented Generation) - Searching your own material and supplying the relevant parts to the model before it answers.

Reranking - A second-stage sort of retrieved results by actual relevance, applied before passing them to the model.

Vector database - Storage optimised for retrieval by semantic similarity.

19. References and Sources

Research cited

• Liu, N. F. et al. (2023). Lost in the Middle: How Language Models Use Long Contexts. arXiv:2307.03172. Multi-document question answering and key-value retrieval experiments showing significant performance degradation when relevant information sits mid-context.
• Hsieh, C. et al. (2024). Found in the Middle: Calibrating Positional Attention Bias Improves Long Context Utilization. arXiv:2406.16008. Confirms the positional bias and reports material gains from mitigating it.
• Bechard, P. and Marquez Ayala, O. (2024). Reducing Hallucination in Structured Outputs via Retrieval-Augmented Generation. arXiv:2404.08189. Enterprise workflow generation, comparing output quality with and without retrieval grounding.
• Alinejad, A. et al. (2024). Evaluating the Retrieval Component in LLM-Based Question Answering Systems. arXiv:2406.06458. Evaluates retrieval quality against downstream answer quality rather than retrieval metrics alone.

Regulatory and official sources

• Regulation (EU) 2024/1689 (the EU AI Act), adopted 13 June 2024, published in the Official Journal July 2024. Available via EUR-Lex.
• Information Commissioner’s Office, Guidance on AI and Data Protection. ico.org.uk.
• UK Government policy papers on the pro-innovation approach to AI regulation and implementation of the UK’s AI regulatory principles. gov.uk.

Claims deliberately left uncited

Evidence meeting a reasonable standard could not be found for the following, despite being widely repeated in industry material: enterprise AI project failure rates; measured time savings by knowledge-work task type; end-to-end task success rates for agents on real business work; quantified breakdowns of deployment effort; the magnitude of retrieval improvement from reranking; and documented incidents of AI surfacing internal data that was technically but not practically accessible. Where this paper makes claims in those areas, they are presented as practitioner judgement.

Next Steps

If this argument lands, the useful next action is not to buy anything. It is to find out where you actually stand.

• Work through Appendix A and score each line honestly. Most organisations find fewer than half in place, which is the normal starting position rather than a failing grade.
• Pick the single most repeated knowledge task in the business and write down what it costs you today, in hours.
• Build the thirty-question evaluation set for that task before you change anything, so you have a baseline rather than an impression.

Those three steps cost a day and will tell you more than any vendor demonstration. Everything else in section 5 follows from them.

Appendix A: Readiness Checklist

Score each item: in place, partial, or absent.

Information - Key documents have a single authoritative version - Documents carry date, owner and status - Superseded material is archived, not left in place - Terminology is used consistently across documents - Critical numbers live in structured systems, not prose

Access - Permissions on target repositories have been audited within the last year - Access is role-based rather than accumulated by history - There is a named owner for each repository - Sensitive categories are identified and separately controlled

Governance - Approved tools are documented - Data classification rules exist and are known to staff - Review requirements are defined for client-facing output - Provider data handling terms have been checked for the specific plan in use - There is an escalation route for AI-related incidents

Practice - At least one use case is defined with a measurable success criterion - An evaluation set exists - Attribution is required on internal-knowledge answers - Someone owns the programme - Results are reported against outcomes, not adoption

The checklist is a work plan, not a judgement.

Appendix B: Questions to Ask Any Vendor

• Are your integrations built on an open standard such as MCP, or are they proprietary?
• How does the system enforce user-level permissions, and is enforcement applied at retrieval or after?
• Does every answer carry attribution to source documents?
• What happens when the system does not have the information? Demonstrate it.
• How do we test accuracy against our own material before committing?
• What is your data retention period, and are our inputs used for training under our specific plan?
• Where is our data processed and stored?
• If we change model provider, what has to be rebuilt?
• What audit record exists of retrievals and actions?
• Show me a deployment in an organisation of our size and sector, and tell me what went wrong in it.

The tenth question is the most informative. A vendor with no honest answer to it has not deployed enough in comparable environments to be a low-risk choice.

AIDAN AI. Version 4, October 2026.

Prepared as a briefing document, not as legal or financial advice. Regulatory detail, vendor terms and tool capabilities move quickly; everything here reflects the position as at the date above and should be confirmed against current official sources before being relied upon for any decision.