It depends less on the agent than on the bank. Building a narrow agent is quick. What takes time is getting read access to the right systems, testing on the bank's own cases, independent validation and committee approval. A read-and-draft job can go live within a few months; anything that moves money takes longer, and should.
Where does the time actually go?
Teams new to agents expect the build to dominate. In a bank, it rarely does. Writing the agent's brief and connecting it to a test environment is the short part. The long parts are the ones every bank change goes through, with a few extra steps because the system acts.
| Stage | What happens | What drives its length |
|---|---|---|
| Scoping | Pick the job, list capabilities, set what stays with people | How narrow the job is |
| Access | Read access to core systems, data agreements, security review | The bank's integration and security queue |
| Test set | Pull past cases with known outcomes, including hard ones | Whether case records are clean and retrievable |
| Testing | Replay, score each capability, fix and retest | How many capabilities and case types |
| Validation | Independent challenge by model risk or equivalent | Whether the agent is in the model inventory |
| Approval | Risk committee, data protection review, outsourcing review | Committee calendar |
| Shadow running | Agent works alongside staff; outputs compared, not used | How quickly enough cases accumulate |
| Live, narrow | Limited team, low limits, close monitoring | Review date set at approval |
The general picture for any business is in how long it takes to deploy an AI agent. In a bank, access, validation and approval stretch it.
What makes a bank deployment faster?
Choosing the right first job does more than anything else. A job where the agent reads and drafts, the output is checked by a person, and mistakes are cheap to correct moves through every stage quickly. Payment investigations are a good early job for bank agents for exactly this reason: the cases are well recorded, the outcomes are known, and nothing moves without a person.
Other things that help:
- read-only access first, so security review is simpler;
- a test set that already exists, such as closed cases in a case management system;
- a validation team involved from scoping, not handed a finished agent;
- a named business owner with time to attend to it.
Customer-facing agents bring extra steps, including disclosure that customers are dealing with an AI system and a clear route to a person. Compare how long it takes to deploy an AI support agent for those.
What makes it slower?
- Asking for payment capability in the first release.
- An agent that spans several departments, each with its own approver.
- Test cases that need manual clean-up before they can be used.
- Late discovery that logs must be kept in a particular form or for a particular period. In the EU, record-keeping duties under the AI Act apply to some uses; see how long to keep AI agent logs under the EU AI Act.
- No exit plan. Committees ask how work returns to people if the agent is stopped.
An illustrative plan
Take a mid-sized bank deploying an agent to prepare responses to payment tracing requests from other banks. The agent reads the payment record and the request, drafts a reply, and a person sends it.
Scoping and access run together over the first weeks, since the agent only needs read access to the payments system and the case queue. The test set is a few hundred closed tracing cases. Testing and fixing take several rounds, mostly on edge cases such as returned payments and partial amounts. Validation runs in parallel once the first results are in. Committee approval follows at the next scheduled meeting. Shadow running lasts until the team has compared enough drafts to trust the pattern. Then it goes live for one team.
Adding the next capability, such as sending routine replies without review, is a second, shorter cycle because the access, the test set and the approval route already exist.
What should you plan for from day one?
Plan for the exit as well as the launch. Every deployment should know how work goes back to people if the agent is paused, and how long that takes; see how to take work back from an AI agent. Plan for revalidation too: model updates, new sources and process changes all restart part of the cycle. The bank-wide limits on what agents may do are in AI agents in banking: what they may and may not do.
Where Pryme fits
Pryme shortens the testing and evidence stages rather than the bank's own governance. Agent Studio turns the job description into a candidate brief, and Attest replays it against the bank's own cases and scores each gate separately. The resulting evidence and the record of every verdict go straight into validation and committee papers.
Questions people ask
Can a bank skip shadow running?
It can, but it loses the cheapest evidence it will ever get. Comparing agent drafts with staff decisions on live work shows problems that a historical test set misses.
Does a bought agent deploy faster than one built in-house?
Only if it can be tested on the bank's own cases and fits its controls. Otherwise the bank still has to produce that evidence, and the time moves rather than disappears.
How long does each later agent take?
Usually less, because access patterns, test methods and approval routes are reused. The first agent pays for the path.