Agentic Solutions Platform
A governed boundary letting a third-party product’s AI agents use bank data without anyone losing custody of it.
- Duration:
- 2025
- Role:
- Lead Engineer
- At:
- Macquarie
Problem
The problem
A third-party product promised to automate business processes with AI agents. For any of it to work, those agents needed the bank’s data, and they needed to act on it: read, reason, send and receive email, produce reports the business would rely on.
So the question was not whether the agents were clever. It was whether a bank could let someone else’s agents near its data at all.
Challenge
What made it hard
My team owned the infrastructure, the data access design, the mail path and execution, for agents we had not written, running on a product we did not control, against data we did not own. Source teams provided datasets on their terms: parquet files, objects on S3, database access. We were accountable for what happened next.
The approach in place solved it per agent. Each solution got its own data pattern, and each pattern carried manual governance checks and auditability as an optional extra. Add an agent, duplicate the pattern. Add ten, and you have ten slightly different answers to the question "was this access allowed", none reviewable the same way twice.
Governance that depends on someone remembering is not governance. So I built a proof of concept for the alternative: an MCP layer giving agents a single generic pattern for querying these sources, with authentication, authorisation and audit as properties of the path rather than steps someone performs.
Architecture
How it is put together
Event-driven ingestion pulls from heterogeneous internal sources and normalises them into a retrievable layer. An MCP server is the only access surface agents get. Scoped retrieval runs through an internal RAG-as-a-Service built and owned by another team, which we integrated with rather than rebuilt, so agents receive retrieved context instead of credentials and a query language. AWS serverless throughout.
The most important line in the diagram is the one that is not there: no path from an agent to a source system.
Tradeoffs
What we chose, and what it cost
We chose
One generic access pattern over many bespoke integrations. Agents were given scoped, brokered context through MCP rather than credentials and a query language. Every access became something we could authorise and record, in the same shape every time.
We gave up
Bespoke solutions and separate infrastructure per agent. Per-agent infrastructure buys isolation: one agent’s load or failure cannot reach another, and each can be tuned to its own consumer. A shared access layer trades that for consistency, so the path becomes something that must not fall over. Genericity also costs design time before the first use case ships. Right trade when the number of agents is going up. Wrong trade for three agents that never change.
Outcome
What changed
By construction
governance and auditability are properties of the access path, not manual checks
Design intent, not a measured result.
One pattern
onboarding an agentic solution becomes adoption, not an integration project
Design intent, not a measured result.
Flat maintenance
the surface stops multiplying with the number of agents
Design intent, not a measured result.
Lessons learned
What this changed
The interesting problem in enterprise AI is not capability, it is custody. Anyone can connect an agent to data. The work is being able to say afterwards, precisely, what it saw and why it was allowed to.
Which turns the design question from "what can this agent do" into "what capability should the platform offer so every agent gets custody for free". Governance you have to remember to perform will eventually not be performed. It has to be the easy path, or solutions route around it.
Read alongside