Driving the Agentic Shift in Banking Adoption Governance and Scale [Testμ 2026]

The Golden Record Case

Humberto Enriquez gives the panel’s only production example. His bank recently went live with a system holding the customer golden record, using AI to identify duplicate customers at onboarding.

He contrasts it with the traditional route, doing the same matching manually with regular expressions, which he calls limited if you do it that way.

The agents assemble a specific set of data that resolves to a unique client, so an existing customer’s information is pulled up rather than running an entire onboarding from scratch. He claims two outcomes: no duplicate clients in the ecosystem, and a prompt display of everything already held on that customer.

Where there is no certainty, and several existing people resemble the person being onboarded, the operator picks the right one and can merge information between records. He calls this two sides of the coin: automation you can rely on, plus a human in the loop for the ambiguous decisions.

A second process then runs over everything created that day and re-checks whether each new record is genuinely unique, raising a fresh alert and retrying the merge if not. His stated reason is that when a human gets into the loop, you can get errors there too.

He frames the arrangement as joint responsibility between the agents and the people operating the systems. Worth noting for anyone benchmarking against it: no accuracy rate, match rate, volume, go-live date or time saved is given anywhere in the session.

Execution, Not Opinion

Mauricio Sanchez recalls that two or three years ago the assumption was that the first cases would be customer-facing interaction, so everyone worked on chatbots. That is where the hype began.

The challenge they hit was how humans actually work and how an agent actually interacts with people, which reframed the question for him.

His reframe is the useful part. The right question is not where an agent can offer its point of view, but where it can execute with a human supervising.

He names the real value as financial reconciliation and back office, which is what Humberto Enriquez had just described, plus more accurate onboarding and quick KYC and compliance.

He adds internal observability and technical support as a genuine open problem, covering the correlation between systems and the observability gaps that take systems down when the aim is to get back to production quickly.

His conclusion is that this is where the hype turns into reality, and that the chatbot is not the real deal.

Agent Versus Copilot

Javier Solano says the first thing to define is what a real agent is versus what is hype, and what separates an agent from a copilot.

Where he would start instead is a specific case in back office or in engineering itself, where you have the ability to test it and verify the output.

His closing warning is not to ride the hype by trying to solve every problem with agents now. The numbering of these filters is editorial; he lists them without labelling them.

Guardrails Before Behaviour

Humberto Enriquez starts from the failure mode. These engines hallucinate and can do it very quickly, especially when a lot of effort goes into the inputs.

He warns that prompt engineering itself can mislead, so he does not treat prompting as the control.

The method that follows is to set the guardrails properly first, then test how the agent behaves by deliberately forcing it to try to breach them.

He says that at the current level of maturity you cannot leave agents by themselves, and a human should stay in the loop at least for the next six months, immediately conceding that what they are discussing may change in three or four months. That is his own estimate rather than an industry timeline.

His structured-minds point closes the section: if the person guiding the agent has an unstructured mind working in unstructured situations, the agent will go that way too, so it is guardrails plus who is driving.

Distribution, Not Pass/Fail

Mauricio Sanchez opens flatly: you cannot test an agent the way you test a system, because an agent is a non-deterministic system.

The shift he asks for is from whether the test passed to the distribution of behaviour across many runs, meaning what happens when you run a lot of situations, real or hypothetical.

His first two principles are scenarios at scale, with enough situations to genuinely compromise the agent rather than a fixed suite the team wrote for itself, and human-graded golden sets built from realistic situations rather than synthetic pass criteria.

The third is a staged rollout in shadow mode before the agent is allowed to run autonomously, because you cannot leave the agent alone at any scale until it has been tested this way.

He insists on his own initiative that you do not need the same tools you use to test systems today. At this scale testing is not about typing; it is a system that helps you test the system, ending in agents helping to test agents.

Validating The Trajectory

Javier Solano says validating the output is not enough. If the agent calls another tool, you have to check the accuracy of the tool call itself.

The specific checks he lists are whether it called the right tool, with the right arguments, because a wrong call can send the agent down an entirely different path.

He wants the trajectory validated as a sequence: the right steps, in the right order, with no unnecessary actions executed.

Every step should be traceable with the retrieved evidence in order, not only to be auditable but to be sure each step was actually done, alongside task completion.

Stop behaviour gets its own test. If the agent does not know the answer it must stop, rather than hallucinate or take some other harmful action.

He treats every model version release as a change in production, since the vendor upgrades the model and it can produce a different result for a test you have already run. His estimate of a new version roughly every week comes without a vendor or a source.

Retesting Like Pentesting

The host draws the analogy himself. Regular security testing is done on systems every so often, so the same cadence should apply to agents.

Humberto Enriquez agrees that testing agents is an ongoing process whose purpose is to make the agents mature.

The strategy his team is looking into, explicitly not yet in place, is agents testing agents: a more mature agent testing one that is about to go live and is not yet as mature.

What he wants tested in the non-deterministic layer is whether the agent actually finishes its task, since a good tell that an agent is hallucinating is that it starts running in loops.

Failure communication matters as much as the happy path. When the agent realises it cannot complete the task it has to tell the user promptly, and know how to correct itself and get back on track.

He notes agents do not stand alone, since there is a model behind them, so its answers and the way the customer is addressed also need controlling. He mentions evaluation frameworks without naming any.

Voice Is Still Exploratory

Asked directly whether they have experimented with voice agents, Humberto Enriquez says they are at an exploratory stage and claims nothing in production.

His structural point is that a voice agent does not really think for itself. It has other agents behind it, so it is an orchestration of agents that all have to work together to deliver value.

Customer service moves to a different level, because the voice agent has to understand the tone of the conversation and find ways to defuse a frustrated customer. His illustration of an upset caller is explicitly hypothetical rather than an incident his bank handled.

He credits current technology with being able to read the room, which is an unquantified claim from a team still in exploration, and cautions that voice puts you at a different level of AI where you need solid ground to do it properly.

Mauricio Sanchez warns that voice sounds like the evolution of a decision tree and is not that easy. Legacy integration comes first, covering the interactive voice response system and the traditional systems around the agent, because it is not only the agent but the whole ecosystem.

Routing is a real constraint, since a phone line connects to a system that has to hand the caller to the agent, which is nothing like a chatbot in a web context. Testing also has to span different situations in different languages with different localisation.

He recounts a project they had to roll back after assuming it would be easy to evolve a conversational chatbot into a voice-controlled agent. No client, date, scale or cost accompanies it.

Observability Is Not Optional

Mauricio Sanchez states that observability and risk control are not a nice-to-have and not optional, and have to be designed at the same time as the agent.

His reasoning is sector-specific, since in banking you are dealing with money, sensitive data and situations that are risky beyond the institution itself, which is why he calls it regulatory and mandatory. He cites no specific regulation, regulator or jurisdiction.

His three ingredients are detection that something is happening, tracing where it is happening, and correction.

For correction he points back to agents working with agents, and says the real challenge is having the correct design to fall back on when the worst happens.

Javier Solano ties observability to the design question directly: once you know the worst thing the agent could do, observability is what tells you how fast you will realise it went wrong.

Start From The Worst Case

Javier Solano says the thing that changed his mind on testing was to stop asking what success looks like with agents and ask the opposite: what is the worst thing an agent can do?

The two questions that follow are how fast you will know something went wrong, and what happens next.

He requires full traceability of every step, including how the planning was done, and if another tool was called to get data, validating both that input and the output.

The last rung is where he locates reputational and operational damage, which is why declining beats answering wrongly.

Data Is The Elephant

Asked for technical lessons from deploying into core banking, Humberto Enriquez’s answer is to take care of your data, because data is the elephant in the room with agents.

His observation about the panel itself is sharp: they had spent the hour on how agents behave and how to control them, and not on what they feed on. His causal claim follows, that if your data is not properly curated your hallucinations get deeper, legacy or not.

He treats consumption as solved. There are tools in the market, you can put your APIs on an MCP server, and agents can consume the information in the bank’s systems, so you will find a way.

He deliberately says legacy is not the problem here, since banks already have integration layers and already operate, and legacy systems serve a different purpose than serving the AI. His summary is proper data in the proper place at the proper time.

Mauricio Sanchez immediately qualifies that. What was made to sound obvious is integrating a deterministic system with a non-deterministic one, and the integration layer is only obvious to a bank engineer because a bank cannot operate without one.

His hard claim is that you cannot delegate agent operation directly to a core or legacy system, because that system was designed differently from an agent, which makes the integration layer mandatory and perhaps the most critical part of the work. The captions drop the negation in that sentence, and the surrounding argument makes the intended sense unambiguous.

Q & A Session

The chat supplied both closing questions, and the panel took them in turn.

• How can we build automated regression tests for agents when the expected output is not deterministic but the business outcome still needs to be reliable?

  Host: From what we see at our own company, you test an agent with another agent. Score the runs on evaluations against criteria rather than as pass or fail, and read the resulting percentages as your readiness signal. That is only a partial answer to this, so come and find me afterwards and we can go into it properly.

  Mauricio Sanchez: Go back to the same three things. Look at the behaviour across many iterations rather than a single run, build golden sets from realistic scenarios and have humans grade them, and stage the rollout with shadow mode before you hand over any autonomy. You also need the proper tooling to benchmark those tests, otherwise you have nothing to compare a run against.

• How can organisations audit and test the security bounds of external APIs and tools triggered autonomously by agents?

  Humberto Enriquez: That is a tough one. Think of it as prompt injection and jailbreaking: you have to test not only the functional matters but how the agent can be cracked, how efficient its trajectory is, how robust and aligned it is, and how resilient it is to attacks. I would not implement that agent by agent. Put a layer of security on top instead, the same way an API manager protects your APIs. I do not want to advertise anyone here, so I will not name a product, but the market is getting ready for these concerns.

This session was part of Testμ Conf 2026, which ran across three days of sessions on agentic engineering and quality. Registrations for the next edition are already open on the Testμ Conference 2027 page.