There's a huge opportunity right now in being the deployment layer for AI into the economy: the people and firms who get agents working inside real workflows. The work it takes to change how an enterprise operates is far greater than anyone realizes or would prefer, and in a bank, an RIA or an insurer every one of those changes also has to hold up in front of an examiner.
I've spent most of my career on the operating side of financial services. I was COO of a wealth management firm before I founded Vantage Point in 2018, and since then we've worked with 175+ clients. I've watched a lot of software get bought, installed and half used. AI agents are going to test firms in a different way, and I want to lay out what I think the work actually involves.
The model is the easy part
When leaders talk about AI, the conversation usually starts with the model. Claude or ChatGPT, Agentforce or something custom. That choice matters less than people think. The models are good, they keep getting better, and you can switch between them more easily every quarter.
What decides whether an agent does useful work is everything around it:
- Legacy systems need to move to the cloud. An agent can't read a core banking system, a policy administration platform or a desktop CRM it has no way to reach.
- Data organization and access need to be updated. Three versions of the same household, owners who left last year and empty fields produce confident wrong answers. So does an agent that can see data it shouldn't.
- Software needs to be connected to agents in new ways. MCP servers, APIs and connectors decide what an agent can see and do, and whose permissions it runs under.
- Workflows need to be reengineered for agents. Dropping an agent into a process built for people usually gives you the same process with an extra step.
- Human-in-the-loop design needs to be worked out for each process. Someone has to decide which outputs a person reviews, who that person is and what gets logged.
- Evals need to be built and maintained. You need a set of real cases with known right answers, run before launch and after every change.
- The whole system needs continual updates. New models ship every few months, vendors change features and connectors, and permissions drift.
None of it is glamorous, and most firms don't have the people to do all of it today.
Deploying an agent is a different job from deploying software
For twenty years, enterprise software projects followed a familiar pattern. You configured a tool, migrated the data, trained users and measured adoption. The company was enabled by the tool, and whether the work got done still depended on the people using it.
With AI agents, you're delivering actual work augmentation to the organization. You're deploying work output inside a process: a drafted client follow-up, a reconciled record, a prepared review, a case summary before escalation. The agent is doing part of someone's job.
That changes the implementation and enablement process completely. Sign-off has to rest on the output: the right answer on real cases, at a known error rate, with a person catching what the agent gets wrong. Training shifts toward supervision, so staff learn when to trust the output and when to send it back.
It also changes what happens after launch. A CRM that's configured well in January is usually still fine in June. An agent that scored well in January may not be, because the model underneath it changed, a field it reads was repurposed, or users started asking it things nobody tested. Somebody has to own it.
Why regulated firms feel this more
Financial services firms already run on supervision. FINRA expects broker-dealers to supervise communications. Banks run model risk management and third-party risk programs. Insurers are adopting written AI programs under the NAIC model bulletin. Every firm has recordkeeping obligations that don't care whether a person or an agent wrote the email.
Regulators have been consistent that existing rules apply to AI. So in a regulated firm, the deployment work includes mapping each agent to the obligation behind it, setting the data boundary with the security team, and keeping a record of prompt, output, model and approver that you can produce on request. That's more work up front. It's also the reason regulated firms that do it carefully will be able to move faster later, because the controls are already in place when the next use case comes along.
Who's going to do this work
I think we're going to see deployment approaches split by industry, by company size and by the specific problem inside a company. A community bank's first agent will look nothing like a global insurer's. A 40-person RIA needs someone who understands Orion, Salesforce and a compliance review queue and can wire them together, which is a different team from the one a global insurer hires.
Traditional systems integrators will modernize and adapt. New entrants will also be founded in this period, built from day one around deploying agents into specific workflows. Forward-deployed engineering, where engineers sit close to the business and ship working systems inside it, is going to be a big part of how this gets done. It's a great time to be a forward-deployed engineer, or a firm built around them.
What this means for a bank, an RIA or an insurer
If you run a bank, start with the data your first agent would read. Most banks have customer data split between the core, the loan origination system and the CRM. An agent that answers from one of them will be wrong in ways your customers notice. Fix the record first, then decide where a person reviews the output.
If you run an RIA or wealth firm, the strongest early use cases sit around the advisor: meeting briefs from household history, follow-up drafts and notes logged back to the CRM. They only work if households are clean and custodial data is in the CRM, and anything a client sees should go through the same review your compliance team already runs.
If you run an insurance agency, IMO or carrier, look at service and producer support first: policy status questions, commission and appointment questions, renewal preparation. Keep the policy system as the source of truth, and write down your AI program before the first agent goes live.
For all three, the next step is the same. Pick one workflow you'd like an agent to take on, and get the data underneath it scored before you choose a platform. We do that as a complimentary AI data readiness score: we score duplicates, completeness, ownership and access on the objects that workflow reads, and tell you whether to build now, fix first or migrate.
Related reading
- AI services for Salesforce and HubSpot teams
- AI compliance and supervision controls
- AI support and optimization after launch
Frequently asked questions
What is the AI deployment layer?
The AI deployment layer is the work of getting AI agents into real business workflows: moving legacy systems to the cloud, fixing data and access, connecting software to agents through MCP and APIs, redesigning workflows, designing human review, building evaluation sets and updating everything as models change. In regulated firms it also includes mapping each agent to supervision and recordkeeping obligations.
Why is deploying AI agents harder than deploying software?
Software gives staff a tool, and the work still depends on people using it. An AI agent produces work output inside a process, so it has to be tested on real cases, supervised by a person where the risk calls for it and re-tested when the model, data or permissions change.
What should a bank do before deploying an AI agent?
A bank should pick one workflow, score the data the agent would read across the core, loan origination system and CRM, and fix duplicates and gaps before choosing a platform. It should then set the data boundary with information security, decide which outputs a person reviews and plan how prompts, outputs and approvals are recorded.
How do RIAs use AI agents safely?
RIAs get the most from agents around the advisor, such as meeting briefs, follow-up drafts and notes logged to the CRM. Safe use means enterprise AI plans, least-privilege CRM access, clean household and custodial data, compliance review of anything a client sees, and records kept under the firm's retention rules.
What is human-in-the-loop design for AI?
Human-in-the-loop design decides which AI outputs a person reviews before they take effect, who reviews them, what they check and what gets logged. In financial services it usually covers client-facing communications, record changes and any decision that affects a customer's account or policy.
What are AI evals and why do they need maintenance?
Evals are sets of real cases with known correct answers that you run an AI workflow against to measure its accuracy. They need maintenance because vendors release new models every few months, data and permissions change, and users ask new kinds of questions, so a workflow that passed at launch can drift.
