A B2B wealth-planning platform had an AI demo users loved — and none of the architecture, permissions, or governance that regulated banking partners require. We re-engineered it into a grounded, explainable, multi-agent financial assistant, without rebuilding the engine that already worked.
Published with the engagement anonymised at the client's request — a confidentiality bar we treat as part of the deliverable.
A growth-stage fintech whose B2B SaaS platform puts a “virtual family office” in the hands of investment advisors and wealth managers — and, increasingly, banks. Identity withheld at the client’s request.
A conversational-AI proof of concept that proved demand but couldn’t survive contact with a regulated buyer — inconsistent answers, no permission model, no infrastructure, no audit trail.
A three-service, multi-agent assistant grounded in the platform’s own planning engine via MCP — explainable answers, safe conversational writes, watertight RBAC, streamed in real time.
In production — five planning scenarios live, five more scoped, ahead of wider banking-partner rollout.
The client is a growth-stage financial-technology company in North America. Its B2B SaaS platform gives investment advisors, wealth managers, and financial professionals the kind of sophisticated wealth-planning tooling that was once the preserve of the ultra-wealthy — founded by experts in tax, law, and financial planning with a mission to democratize access to those strategies.
Day to day, the platform models a client’s entire financial life and projects it forward: retirement readiness, debt payoff, spending capacity, net worth, real-estate decisions, life-expectancy assumptions, and market-performance scenarios. Advisors build a base plan and alternative scenarios, adjust assumptions through toggles and sliders, and re-plan live to show clients the impact of a decision.
The platform optimises for three things: advisor productivity, trust and explainability — answers an advisor can stand behind and repeat to a client — and enterprise readiness, the compliance and security bar that lets it sell into regulated banks. That third one is where this story begins.
The client had already built an AI proof of concept that let users ask natural-language questions — “when will I be debt-free?”, “can I afford this?” — and get conversational answers from its planning engine. It proved real demand. It was also, deliberately, a demo: a few predefined scenarios, and none of what a regulated deployment requires.
Intentionally narrow, with no architecture for enterprise deployment. Extending it to a broader audience meant a complete rebuild — the shortfalls were structural, not cosmetic.
Without a structured generation approach, outputs varied and couldn’t be justified. In a compliance-sensitive setting, an answer no one can explain is a liability, not a feature.
Advisors and end clients have fundamentally different access rights — and the PoC had no reliable way to enforce those boundaries across shared and cloned scenarios.
No automated pipelines, no separate dev / test / prod environments, no monitoring. Reliable iteration — the basic rhythm of a production product — was impossible.
Banking partners require audit trails, data-protection controls, and exportable records. None existed — which blocked enterprise deployment entirely, on its own.
No trace of which data produced which answer, no latency or error visibility, no cost lens. You cannot operate — or defend — an AI system you cannot see into.
The gap between a compelling demo and a deployable product was the direct blocker to the client’s growth strategy — expanding into regulated banking environments. In that context, an assistant that gives inconsistent or unexplainable answers isn’t merely a product weakness; it’s a liability. The client could show promise, but couldn’t sell the capability to the banking partners it was targeting.
Focaloid engaged as the client’s AI engineering partner with a clear brief: enable a secure, scalable deployment with a financial partner. The constraints below weren’t aspirations to grow into — they were set as hard requirements before development began.
Every figure computed by the platform’s real planning engine — never estimated from the model’s general knowledge. Deterministic, repeatable, correct.
Every answer traceable to the tools that produced it and the scenario it describes — something an advisor can stand behind and a bank can audit.
Role-based access on every call, no cross-client exposure, PII minimised in logs, every write confirmed, idempotent, and exportable for audit.
The decision that shaped everything: modernise the AI layer, keep the engine. The client’s financial-planning logic and APIs already worked — years of domain expertise encoded in a calculation engine advisors trusted. The mandate was to build a modern LLM architecture around that engine, not to replace it. No rebuild of what already worked.
Mapped the existing PoC, user workflows, permission requirements, and compliance needs. Output: a formal BRD with 31 Given/When/Then acceptance stories.
Designed the multi-agent system, access-control model, and compliance framework — with accuracy, explainability, and security fixed as constraints.
The production assistant across the planning scenarios: advisor and client permission workflows, conversational plan adjustments, safe write controls.
Audit logging, data-protection controls, monitoring, automated pipelines — validated for regulated deployment, with the enterprise roadmap defined.
Scope discipline as a safety feature. Phase I was deliberately bounded to the platform’s financial-insights workspace: no chat beyond it, no direct profile edits, no ungrounded advice, and external bank / payroll / tax integrations explicitly deferred to Phase II. In a regulated build, what the system refuses to do is part of the design.
Embedded in the platform’s financial-insights workspace, the assistant lets an advisor or client ask financial questions in plain language and get accurate, explainable answers grounded in the client’s real plan — and safely make what-if changes by conversation, seeing the projected impact before anything is applied.
The simulation on the right replays the delivered experience: a two-stage flow where the system first selects and runs the right tools against the platform’s real engine, then narrates the verified results — never inventing a number.
Illustrative conversation with representative data — in the delivered product every figure is computed live by the platform’s planning engine.
The assistant is three independently deployable Python services with deliberately separated jobs: the agent reasons, the MCP server provides safe structured access to the platform's data, and the history service manages state. Each scales, deploys, and fails on its own — in a production financial tool, one slow component must never take down the rest.
The return path is live. AWS AppSync Events stream the agent's work back to the frontend over WebSocket — stream_start → tool_start → tool_end → tokens → done — so users watch the assistant check their retirement goal in real time instead of staring at a spinner.
The as-delivered system — redrawn from the engagement's architecture documentation, anonymised.
A user asks a question in the chat UI. The platform backend invokes the AI Companion via its Bedrock AgentCore Runtime endpoint — secure, serverless, session-isolated.
The agent mints a short-lived session token carrying user, client, and scenario identifiers, then connects to the MCP Tool Server with it.
A single-purpose orchestrator classifies the question and hands it to the right specialist — retirement, debt, market variance, what-if, or summary.
The specialist calls one or more MCP tools, which call the platform's live REST APIs — pulling real plan data and running the actual calculation.
The response streams back through AppSync as it's generated — tool status first, then tokens — so the user sees the work, live.
History, presence, and feedback persist via the History service — the conversation resumes exactly where it left off, on any device.
The full reasoning path lands in Langfuse with per-turn token cost — a quality lens and a cost lens from day one.
Every answer is a live recalculation of the client's actual financial plan — scoped, logged, and recoverable at every step in the chain.
Any team can wire a model to an API. The engineering that makes an AI system bank-deployable lives in a handful of deliberate choices — each one below is as-built, not aspiration.
A single generalist agent handling retirement math, debt payoff, market stress-testing, and summarisation in one prompt tends to blur its reasoning across domains — and pick the wrong tool. So the orchestrator's only job is to read the question and route it; five narrowly-scoped sub-agents each own their tools and their prompt.
Models are tiered to the work: Claude Sonnet 4.5 runs the orchestrator and the two complex-reasoning specialists (retirement, what-if); Claude Haiku runs the contained, single-purpose lookups — materially better latency and cost with no accuracy loss where it matters. Optional AWS Bedrock routing supports enterprise model-hosting requirements.
"What if I retire today?" deserves an answer computed by the real retirement model — but it must not corrupt the client's live plan. Several tools follow a deliberate three-beat pattern:
The tool changes the scenario parameter — retirement age, a toggle — inside the platform's engine.
The recalculated projection is read back from the engine — the same math the advisor's dashboard runs.
The change is rolled back. The user has a real answer; the plan is exactly as it was.
Exploration stays non-destructive by design. The user gets an answer computed by the platform's actual model — not a language model's guess — without permanently altering their financial plan. When they do want the change kept, that's a different, explicit path: the confirmed-write flow below.
A default limit of 15 tool calls per request prevents runaway loops where an agent gets stuck retrying a tool — cost and latency stay bounded, always.
Regex checks catch obviously out-of-scope or purely conversational messages before they ever reach the LLM — saving cost and latency on traffic that needs neither.
Watches tool responses for UI-relevant signals — a slider value the frontend should update — and threads them into conversation state without the agent handling UI logic.
Financial scenario calculations can take a few seconds. Rather than a silent wait, the agent publishes a sequence of typed events as it works, batched up to five per publish and signed with AWS SigV4. The frontend subscribes to a per-scenario channel, so each user only ever receives their own conversation's events.
In a trust-sensitive domain, "the agent is now running your variance analysis" beats a spinner — users see how an answer was reached while it's being reached. It also makes a compelling live demo: the system visibly thinking with real tools, not theatre.
Letting users change toggles and retirement sliders by chat risks unintended, irreversible changes to a financial projection. Every conversational write follows the same six-beat contract — and unsupported, unsafe, or permission-violating actions are refused with an explanation, not attempted.
The assistant proposes the change with explicit before / after values.
The projected effect on the plan is shown before anything happens.
Nothing is applied until the user explicitly says yes.
Idempotent writes keyed by request ID — a double-send can't apply twice.
The scenario recalculates through the platform's engine.
The assistant narrates exactly what changed — and it's all in the audit trail.
Every layer of the system is scoped to exactly the data a request is authorized to touch. The AI agent can never accidentally pull or act on a different client's financial plan, because the boundary isn't a prompt instruction — it's the token architecture.
Forwards a delegation token alongside each message — the user's authority, delegated to the agent.
Short-lived (15-minute) token carrying the user, client, and scenario identifiers. Nothing broader.
The JWT rides as a bearer token on every tool call — no token, no tool, no exceptions.
The MCP server resolves the correct API credentials for that specific client's data — and only that client's.
Chat context is always bounded to this triple. Every conversation thread is namespaced by it, every checkpoint keyed by it, every tool call scoped to it. A cross-client leak isn't caught by review — it's structurally unrepresentable.
When a client asks the assistant to edit an advisor's read-only scenario, the system doesn't error, and it certainly doesn't comply. It politely declines, explains why, and offers the safe alternative — cloning the scenario to experiment freely. In a regulated build, a well-designed "no" is a feature with a UX.
The first production architecture was proven and conventional: both services on AWS EKS, an SQS FIFO queue between the platform and the agent, CircleCI stitching it together. It worked — and it carried the full operational weight of Kubernetes. Mid-engagement, the client asked about Amazon Bedrock AgentCore. We researched the trade-offs and migrated both services — an architecture decision made on evidence, not inertia.
Zero code changes to reasoning, tools, or the MCP protocol — only the deployment target moved.
| Aspect | Before — EKS + SQS | After — AgentCore |
|---|---|---|
| AI agent & MCP hosting | Kubernetes cluster (AWS EKS) | AgentCore Runtime — serverless endpoints |
| Message delivery | SQS FIFO + long-polling loop | Direct endpoint invocation |
| Scaling | Manual replica configuration per service | Automatic, independent per service |
| Deployment pipeline | CircleCI → ECR → EKS manifests | AgentCore SDK / CLI deploy |
| Security | K8s secrets + custom JWT middleware | IAM-verified platform-layer controls |
| Execution locking & session namespacing | Custom DynamoDB locks + scenario namespaces | Unchanged — carried over intact |
| Infrastructure management | Clusters, nodes, manifests, namespaces | Zero — fully managed |
LangGraph conversation checkpoints, token-usage records for cost tracking, and user feedback.
Why: relational, durable, and exactly the structured checkpoint format LangGraph needs — conversations resume across sessions and devices.
Active-user presence per scenario (10-minute TTL) and execution locks with a 5-minute crash-safety expiry.
Why: high-frequency, low-latency, TTL-driven lookups — the exact shape DynamoDB is best at. Two open tabs can't double-process a message.
Self-hosted LLM tracing and observability, plus a custom per-turn usage callback priced against a cache-aware cost table.
Why: a quality lens and a cost lens from day one — isolated from core application data. Local dev runs the whole stack via Docker Compose + LocalStack, no cloud required.
We separate two kinds of claims — deliberately. The build facts below are as-delivered and verified by the engineering team. The impact figures are the joint delivery team's projections, and stay labelled that way until live production usage data confirms them. Buyers in regulated industries appreciate the difference; so do we.
Less manual effort to move from PoC to production-ready deployment — weeks, not months, to regulated-deployment readiness.
Faster releases with three fully automated environments and deployment pipelines replacing hand-run processes.
Faster readiness for enterprise banking-partner deployment versus the original proof of concept.
Less time digging through dashboards — advisors answer client questions conversationally instead of re-reading charts.
Less advisor–client back-and-forth to explain projections and plan changes — the assistant explains as it answers.
Faster client onboarding driven by AI-guided interactions — plus ~50% smoother advisor workflows overall.
†Projected impact, estimated by the joint delivery team and reviewed by engineering — pending measurement against live production usage. The product is now in production; we publish measured figures only once they exist. Build and scope facts above are as-delivered.
| Before — the proof of concept | After — the production assistant |
|---|---|
| Narrow, predefined scenarios; couldn't extend without a rebuild | 10+ planning use cases in one conversational interface — modular and extensible |
| Inconsistent, unexplainable answers | Deterministic, explainable, data-grounded answers via MCP and a select-then-narrate flow |
| No multi-role permissions | RBAC on every call; cross-role and cross-client exposure structurally impossible |
| No environments, pipelines, or monitoring | Automated environments and CI/CD — later simplified further onto serverless AgentCore |
| No audit, data-protection, or governance controls | Audit trails, data-protection controls, exportable records, full observability |
| A promising demo — not deployable to banks | Deployment-ready for regulated banking partners |
It is rare to see an external team develop such a strong understanding of both the business requirements and the underlying technical architecture in such a short period of time.
A level of ownership that feels much more like an extension of our internal team than a traditional vendor relationship.
The architecture decisions above weren't just about this release. The modular service split, the MCP contract, and the serverless runtime were chosen so the platform can scale to enterprise deployment without another rebuild.
We take AI experiments to bank-deployable — explainable, permission-safe, auditable — without rebuilding what already works. Governed at every gate, shipped at AI speed.