Many banks have taken agentic AI to proof of concept, but far fewer have taken it into production. The issue is rarely the model. It is what the model is given to work with. Data and documents arrive fragmented, without a shared view of what business terms mean, which rules apply, how fresh the facts are, or who is allowed to see them. An agent working from that material can sound confident and still be wrong in ways that are hard to spot and harder to explain to a regulator.
In regulated financial workflows, access to data is not enough. Agents need context: the business meaning, current facts, policies and permissions that make a task answerable. That context needs to be governed, which is the job of a context layer.
An agent is only as good as the context it receives
Take an agent asked to investigate a failed cross-border payment. To do that well it needs more than read access to a payments database. It needs the right customer and transaction facts, retrieved for this case and not a similar one. It needs to know what "settled", "returned" and "repaired" mean in this institution, not in general. It needs the policies that govern the next step, and the current operational state: is the counterparty bank under a cut-off, is there an open incident on that corridor?
Without that, the agent fills the gaps itself. It infers definitions, reaches for an outdated procedure, or blends two customers' records. Each output may look plausible, but nobody can say with confidence which facts and rules it relied on.
This is why so many pilots stall. The demo works on clean examples. In production, the variety of real cases exposes every inconsistency in the material the agent was given.
What a context layer does
A context layer sits between the institution's systems and its agents. Its job is to assemble what a task needs and supply it in a form the agent can use reliably. In a regulated setting, that context has to meet four criteria:
- Consistent. Business terms, entities and relationships are defined once and used everywhere, so two agents never work from two meanings of "customer" or "exposure".
- Permissioned. The agent sees only what the person or process it acts for is entitled to see, enforced at retrieval, not left to the prompt.
- Current. Each fact carries its source and freshness, so the agent knows whether a balance is live or last night's batch.
- Traceable. Every answer and action can be traced back to the facts, definitions and policies used to produce it.
In practice, the context layer assembles what the agent needs to know for the current task from several sources, retrieving and combining the right information at the right time:
- Instructions and guardrails. The agent's role, the rules it must follow and the constraints on what it can do.
- User context. The identity, role, permissions and preferences of the person it is acting for.
- Conversation context. The current dialogue and its history.
- Task context. The current goal, the plan and the actions already taken.
- Domain knowledge. Industry standards and rules, such as ISO 20022 and payment scheme rules.
- Enterprise knowledge. The institution's own policies, processes and documentation.
- Operational and historical context. Live data, past cases and relevant events.
Beneath it, a semantic layer gives enterprise data consistent business meaning and a unified view across systems. It maps data to business concepts, definitions and relationships, such as customer to account to payment. It applies common terminology across systems, and carries the access rules, policies and quality standards that govern the data.
The data itself stays where it is. Payments systems such as IPF, core banking, CRM, risk and fraud systems, reference data, the data lake, documents and external sources such as scheme rules and regulatory data are accessed in place, federation-first, without needing to move everything into one store. The agent receives the relevant context; it returns a response, decision or action.
Just as important is what stays outside the model. Access controls belong in the platform, not in instructions the model is asked to follow. High-impact actions, such as releasing a payment, changing a limit or closing a case, should pass through explicit approval steps that the agent cannot talk its way around. The model reasons; the surrounding architecture decides what it is allowed to do.
Start small, build context around decisions
The temptation is to build an enterprise-wide context layer first and find uses for it later. That route is slow and rarely survives contact with a real workflow. A better approach is to start with one bounded workflow and let its decisions define the context it needs.
- Pick a bounded workflow. Choose one with clear inputs, a known set of decisions and measurable outcomes, such as payment exception handling or a single step in customer onboarding.
- Map the decisions. For each decision, list the facts, definitions, policies and operational signals a skilled person would check.
- Build context for those decisions only. Model the terms, connect the sources, apply entitlements and record freshness and lineage.
- Test four things separately. Does the agent retrieve the right context? Does it apply the rules correctly? Are its actions safe and within limits? Does the business outcome improve?
- Expand autonomy on evidence. Move from recommending to acting only where testing shows the agent is reliable, and keep approvals where the impact is high.
Each workflow added this way extends a shared, governed model rather than another isolated pilot. Over time, the context layer becomes an asset the whole institution can build on.
From pilot to production
Agents will not earn trust in financial services by being cleverer. They will earn it by working from context that is consistent, permissioned, current and traceable, inside controls the institution owns. That is what turns an impressive demo into a workflow a risk committee can sign off.
Icon helps banks and financial institutions make that move. Our AI consultancy, architecture, design and delivery teams help select priority use cases and engineer and govern them through to production. Our data architecture practice builds the governed data models that give agents consistent, trusted context.
Talk to Icon about assessing a priority agent use case and designing the context layer and controls needed to take it safely into production.
