Summary: Ninth Wave built Compass on Amazon Bedrock AgentCore as a multi-agent assistant for open finance onboarding. Seven specialists handle search, documentation, classification, field mapping, analysis, workflows, and readiness, with intent routing, task-specific models, and tenant-scoped grounding. Deterministic application code computes the readiness score, keeping the auditable metric separate from probabilistic model output.
Open finance onboarding means grinding through field mapping, API validation, and readiness scoring. Each bank exposes APIs with naming of its own and its own distance from the FDX standard, so an integration swallows weeks of specialist effort. Ninth Wave’s answer was Compass, an AI assistant built on Amazon Bedrock AgentCore, which turns that into a self-service portal where bank engineers and fintech partners meet in a shared workspace.
Why a single agent wasn’t enough
The team weighed self-hosted models on EC2 against a single-agent RAG pattern. Self-hosting bought control and charged overhead for it; the single agent was easier to stand up but fared worse across mapping, analysis, search, and Q&A. Going multi-agent costs more complexity upfront, and each specialist keeps a context and prompt of its own. Nothing competes for token space, and accuracy scales with task types.
Three design decisions matter here. Intent-based routing classifies once and sends the request to the right specialist. Per-task model selection matches lightweight models to high-volume tasks and higher-reasoning models to mapping and analysis. Tenant-scoped grounding assembles each bank’s own context before an agent runs, so one bank’s data never leaks into another’s session.
The architecture in practice
Behind a primary orchestrator on the Strands Agents framework sit seven specialist agents. Search ranks portal docs, documentation Q&A answers grounded questions, document classification groups uploads by type, field mapping lines FDX fields up with the bank’s API, analysis calls out drift and formatting gaps, interactive workflows guide onboarding, and readiness analysis writes narratives using Amazon Bedrock Knowledge Bases.
RAG retrieval belongs to readiness analysis alone. Grounding for the other six agents happens at the application layer, which leaves retrieval logic and ranking entirely to the team. Readiness analysis must synthesize across a corpus of FDX reference documents too large for one request, so RAG fits there specifically.
The readiness score is no model estimate: application code computes it deterministically from field mapping coverage. That is what satisfies audit requirements; a probabilistic output cannot get there.
Security and observability as first-class concerns
Compass serves external bank developers and internal users out of the same application, so every request is scoped to one tenant before any logic sees it. Traffic moves through CloudFront and AWS WAF and then an internal load balancer. ECS on Fargate validates sessions against an OAuth2/OIDC provider with MFA, and tenant identity flows downstream to scope every data query.
AI workloads run in a separate AWS account via a cross-account IAM role, which keeps blast radius contained. Per-agent metrics land in CloudWatch, alerts go out through SNS, and dashboards live in Managed Grafana. Dimensioning by agent lets regressions surface at the individual agent level, not only system-wide.
What this means for builders
The pattern is not “add an AI chatbot to onboarding.” It is a set of deliberate splits: deterministic scoring for auditability, RAG only where a corpus is too large to pass inline, and tenant-scoped grounding as a hard boundary. For any regulated workflow where multiple parties share model infrastructure, that is a useful template.
For teams weighing agent orchestration, the tradeoff is real. A multi-agent system costs more to build and run than a single RAG endpoint. But when task types carry different accuracy requirements and context windows are finite, separation earns its keep. The same reasoning holds for execution models for process orchestration: the trust you can place in the orchestrator depends on how cleanly each component’s job is bounded.
Delivery took five sprints, so this need not be a big-bang rewrite. Foundations first, then portal and automation, then agent integration, then hardening, then production rollout. Each phase stood on the one before it, with no waiting for a perfect architecture.