Fintechs usually assume that a team which builds software understands agents well enough to supervise them. So they ship first, train later, let one operations lead hold all the know-how, and treat an agent's authority as a setting. Each habit works at small scale and fails as the business grows, when held actions multiply and partners ask for evidence.
Why don't engineers make good reviewers by default?
Engineers understand how the agent is wired: its connections, its prompts, its logs. That is different from knowing whether a held payout to a merchant should go out. Reviewing is an operational skill: reading which bound held an action, checking the provenance of each fact, knowing the customer's limits and the red lines, and writing a reason someone else can follow.
Fintech engineers often end up approving held actions in the early days because nobody else is available. They tend to judge the draft by whether the agent behaved as designed, not by whether the outcome is right for the customer. A payout that the agent drafted correctly from a merchant's emailed instruction is still an external claim, and an external claim cannot authorise a payment. Train the people who will own the queue, even if there are only two of them, and move engineers out of approvals as soon as you can.
What does "ship now, train later" cost?
Fintech culture rewards shipping. An agent that drafts customer replies or prepares payouts can be connected in days, and training feels like a delay. So the agent launches and the operations team learns on live cases.
The cost arrives in two places. Customers get decisions made by people who did not yet understand what they were approving. And the agent's own progress stalls, because depth depends on evidence from real cases, and evidence built from untrained approvals cannot be trusted. Running the agent at depth 1 or 2 for a few weeks while the team learns on its drafts is not a delay. It is the shortest route to the depth the business wanted.
What happens when one person holds all the knowledge?
In many fintechs, one operations or compliance lead understands the agent: its bounds, its sources, why it holds certain payments and what to do when its certificate lapses. Everyone else asks them.
That works until they are on leave, ill or gone. Certificates lapse after 90 days, and a run that clears no depth drops the agent to depth 1 the same day. If that happens while the one person is away, the held queue fills and nobody knows whether the surge is normal. Spread the knowledge deliberately: at least two certified reviewers per agent, a written quick reference for abnormal states, and a handover routine when anyone leaves.
Why can't depth be set in the config?
Engineers expect autonomy to be a parameter. They want to switch the payouts agent to execute and move on. Under a governed operating system it does not work that way. Depth is earned, not configured: the agent's role sets the ceiling, evidence from Attest sets the depth, and the lower wins. Attest replays the agent against real cases from the fintech's own operation, and each of its seven gates must clear on its own.
Teams that do not understand this file tickets asking why the agent is "stuck" at depth 2, or try to route around the hold. Teaching the whole team, engineers included, what earns depth turns frustration into a plan: improve the sources, tighten the bounds, train the reviewers, and the evidence follows.
How should training keep pace with growth?
Fintechs can double operations headcount quickly. New hires arrive into a team where the agent already handles routine work, so they never learn the basics by doing them. They also arrive faster than the one experienced lead can coach.
Make agent review part of onboarding, assessed before anyone approves a held action. A fintech can adopt the practice of tying approval rights to a current certificate, depth by depth, so growth in headcount never quietly lowers the standard of review. Partner banks, payment schemes and regulators increasingly ask how a fintech oversees its automated decisions; a register of who is certified for what, with expiry dates, is a better answer than a slide.
What should a fintech do instead?
- Train the operations owners of each queue before launch, and move engineers out of approvals.
- Run every new agent at low depth while the team learns on its drafts.
- Certify at least two reviewers per agent, and write down what to do in abnormal states.
- Teach everyone, including engineers and founders, how depth is earned.
- Build assessment into onboarding and keep a register of certificates.
The general order is in the guide to training teams for AI agents. For a fintech's version, see how fintechs should train staff before deploying AI agents, the AI agent training plan template for fintechs, and how much AI agent training costs for fintechs. Wealth platforms run into a related set of habits, set out in what wealth managers get wrong about AI agent training.
Where the Academy fits
Pryme Intelligence Academy gives a fintech a route that matches its headcount. Founders and engineers take Foundations to learn how depth is earned. Operations staff take Operator, certified on two weeks of real review decisions. Whoever designs agents takes Builder, whose capstone is an agent certified in Attest to depth 2 or higher. Seats come with paid Pryme Intelligence plans, and the admin view tracks expiry.
Questions people ask
Should founders sit agent training?
Yes, at least the shared vocabulary. Founders set the pace of launches and often approve exceptions themselves. If they do not understand depth and verdicts, they will push for autonomy the evidence does not support.
Can a fintech outsource review of held actions?
It can outsource the work but not the accountability. If a partner reviews held actions, hold its people to the same training, assessment and register as your own, and check their decisions.
What is the smallest viable reviewer team?
Two certified reviewers per agent, so the queue never depends on one person. Add more as the volume of held actions grows, using the agent's shadow period to estimate it.