Most banks that piloted generative AI spent their first year on prompts: templates, prompt libraries, training courses on how to phrase a request. That work was useful for chat assistants. It is the wrong unit of control for agents, which plan, call tools and work through many steps on their own. This is the first of five parts on the discipline that replaces it, context engineering, and on what it asks of a bank. It sits alongside the series on AI-assisted software delivery, which covers a different problem: AI that writes code, rather than AI that runs inside a business process.

The timing is not academic. On 15 October 2026 the Financial Stability Board published its final sound practices for the responsible adoption of AI, and strongly encouraged boards and senior management to use them when building their AI governance and control frameworks[1]. In the data governance practice, the report uses the term itself: banks should apply access controls, classification and retention requirements to all data accessible to an agent, wherever it sits and whether it is structured or not, and it calls this "context engineering"[2]. When a global standard-setter adopts an engineering term, it is time for executives to know what it means.

What changed

A prompt is the instruction a person writes. The context is everything the model actually sees when it acts: the system instructions, the user's request, documents retrieved from a knowledge base, the results of tool calls, the conversation so far and anything the agent has stored in memory. In a chat, the prompt is most of the context. In an agent working through a twenty-step task, it is a small and shrinking share, because each step adds tool output and intermediate results.

Anthropic's engineering team describes context engineering as "the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference", and sets the goal as "the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome"[3]. The word that matters is smallest. The instinct in most organisations is to give the model everything, just in case. That instinct is wrong.

Why more context makes agents worse

Two pieces of research make the point. In 2023, Liu and colleagues found that language models do best when the relevant information sits at the beginning or end of a long input, and that performance drops when it sits in the middle[4]. Models have improved since, but the underlying issue has not gone away. A July 2025 study by Chroma tested 18 models and found that "across all experiments, model performance consistently degrades with increasing input length", and that "even a single distractor reduces performance relative to the baseline"[5]. The authors call this context rot.

A distractor is a passage that looks relevant but is not. Banks are full of them: last year's version of the credit policy, a superseded fee schedule, a product sheet for a different jurisdiction, a customer note about a different account. An agent that retrieves all of them has not been given more knowledge. It has been given more chances to be confidently wrong. Anthropic's advice is to treat context as "a finite resource with diminishing marginal returns"[3].

A bank does not have a prompt problem. It has a data supply chain problem, and the agent sits at the end of it.

The four ingredients of an agent's context

It helps to break the context into four ingredients, because each has a different owner and a different failure mode.

  1. Instructions. The agent's goals, its rules and its limits: when to escalate, what it must never do, which policy applies. These are policy, and should be owned like policy, with versions and approvals.
  2. Knowledge. Documents and records retrieved at run time, usually through retrieval-augmented generation (RAG). This is where staleness and distractors come from. Part 2 of this series covers it.
  3. Tools. The functions the agent can call, and what they return. Protocols such as the Model Context Protocol (MCP) standardise how models connect to data sources and tools, and its specification is explicit that tools "represent arbitrary code execution and must be treated with appropriate caution"[6]. Part 3 covers permissions.
  4. Memory. What the agent carries from one step, session or customer to the next: summaries of earlier work, notes it writes for itself, preferences it has learned. Anthropic describes techniques such as compaction, where a long history is summarised into a fresh window, and structured note-taking outside the window[3]. Memory is the ingredient banks think about least and should worry about most, because it persists.

The FSB draws the line I would draw. It asks institutions to strictly separate an agent's predefined goals, permissions and rules from the data it can access to achieve them[2]. In practice that means the instructions are owned by the business and risk, and the knowledge, tools and memory are owned as data, with entitlements. Mixing them, for instance by pasting customer data into a system prompt template, makes both harder to control.

Context is an attack surface

There is a security reason to care, too. A language model cannot reliably tell the difference between data it is reading and instructions it should follow. OWASP ranks prompt injection first in its 2025 list of risks for LLM applications, and notes that indirect prompt injection occurs "when an LLM accepts input from external sources, such as websites or files"[7]. For a bank, external sources include customer emails, uploaded documents, trade documents, supplier invoices and web pages an agent reads during research.

The FSB names a related risk, memory poisoning, where attackers inject malicious data into an agent's knowledge base or retrieval store to influence its behaviour over time[2]. The implication is that every source feeding an agent's context needs the same question asked of it: who can write to this, and what happens if they write something hostile?

What this looks like in one workflow

Take an illustrative case: an agent that prepares periodic KYC reviews for corporate clients. A prompt-engineering approach writes a careful instruction ("review this client's file against our KYC policy and flag any gaps") and connects the agent to the document store.

A context-engineering approach asks different questions. Which version of the KYC policy applies to this client's jurisdiction and risk rating, and how is only that version retrieved? Which documents in the file are current, and how are expired ones kept out? Can the agent see transaction data, and if so, for which accounts and over what period? Does a registry lookup return the whole filing or only the fields the review needs? If the agent writes notes to itself on one client, can those notes ever surface during another client's review? And when a reviewer later asks why the agent flagged a gap, can the bank show exactly what the agent saw at the time?

None of those questions is about wording. All of them decide whether the output is right, and whether the bank can defend it.

Why this is a control question, not just an engineering one

The FSB asks banks to keep records that let them trace what an agent did, including "what information and tools it accessed" and whether it acted within its permissions[2]. That is only possible if context is assembled deterministically, in code, and logged. An agent whose context is whatever a similarity search happened to return that afternoon cannot be audited.

It also changes who is accountable. In the UK, the FCA's Mills Review of 6 July 2026 expects AI to move from assisting people to systems that "recommend actions, initiate transactions, and execute decisions within agreed parameters"[8]. The agreed parameters live in the context. Somebody has to own them.

What to do on Monday

  • Inventory the context, not just the agents. For each agent in production or pilot, list its instructions, knowledge sources, tools and memory, and name an owner for each.
  • Separate instructions from data. Version and approve instructions as policy. Govern knowledge, tools and memory as data, with entitlements and classification.
  • Curate before you connect. Before pointing an agent at a document store, remove superseded and out-of-scope material, or tag it so retrieval can exclude it.
  • Assemble and log context in code. Make it possible to reproduce exactly what an agent saw for any action it took.
  • Treat every input as untrusted. Map which sources an outsider can write to, and test agents against hostile content in those sources.
  • Read the FSB's agentic sections with your data team, not only your AI team. The FSB places context engineering inside data governance, and that is where most of the work lands.

Prompt engineering asked how to talk to a model. Context engineering asks what the model is allowed to know at the moment it acts, and that is a question banks have been answering for people for decades. The next part of this series turns to the largest ingredient: retrieval and memory, and how to architect what an agent knows, from RAG to long context to memory stores, with the trade-offs each brings in a bank.