AI architecture
Seventeen architecture decisions before the first sprint
An AI research platform for analysts, where the hard parts were not the models. I wrote the decisions down — including prompt-injection defence and per-subscription isolation of the vector store — before anyone started building.
- Written down and numbered before build, not after incidents
- 17 decisionsWritten down and numbered before build, not after incidents
- Subscription boundaries enforced inside the vector store
- Isolation at retrievalSubscription boundaries enforced inside the vector store
- Circuit breakers, load shedding and quotas as design, not as patches
- Failure behaviour specifiedCircuit breakers, load shedding and quotas as design, not as patches
The client
An investment research firm in the United States building an AI-native platform for its analysts, where content access is governed by what each client subscribes to and a leak across that boundary is a commercial incident.
The engagement
An architecture phase producing a high-level design and a numbered decision series, delivered as packages before build.
The problem
In an AI platform for a research business the models are the easy part. The hard parts are access isolation across subscription tiers inside a shared vector store, conversation memory, streaming versus request-response service boundaries, token accounting, behaviour under load, and prompt injection — every one of which is cheap to decide up front and extremely expensive to retrofit once the platform has users.
What I did
I insisted the architecture be written as a numbered decision series rather than as a diagram, because a diagram records a shape while a decision record captures the alternatives and the reason — which is what a reviewer, an auditor or the next engineer actually needs. Seventeen decisions covered the protocol strategy, the orchestration framework, isolation of vectors by source and subscription, dialogue memory, streaming, authentication, migrations, service separation, caching, circuit breakers, load shedding, token quotas, prompt-injection defence, asynchronous exports, history and feedback capture. Treating injection defence and quota exhaustion as architecture rather than as hardening tasks is the difference between a platform that degrades and one that fails in front of a client.
What was built
A hybrid interface strategy combining a conventional API with a model-facing protocol, agent orchestration, a vector store with per-source access isolation so subscription boundaries hold at retrieval time, streaming separated from request-response services, and explicit operational behaviour under load — circuit breakers, load shedding, token accounting and quotas.
On the table at the end
- High-level design with sequence diagrams
- Seventeen numbered architecture decision records
- Risk matrix
- Data-lake design
What it changed
Front-loaded the decisions that are expensive to reverse — access isolation, protocol strategy, quota and failure behaviour, injection defence — so the build started with a documented, reviewable architecture instead of accumulating them as incidents.
How it ran
- 01
Decisions, not diagrams
A numbered decision series capturing alternatives and reasons, so each choice can be reviewed and revisited on its merits.
- 02
Isolate at the data layer
Per-source, per-subscription access enforced inside the vector store, because filtering at the application layer eventually leaks.
- 03
Separate streaming from request-response
Different services with different scaling and failure characteristics, decided before they were entangled.
- 04
Specify failure behaviour
Circuit breakers, load shedding, token accounting and quotas designed in, so degradation is a designed state rather than an outage.
- 05
Treat injection as architecture
Prompt-injection defence given its own decision record alongside authentication and isolation, not left as a later hardening ticket.
Other work
All case studies →- Capital markets
An agentic core with a human gate on every state change
A thirty-year financial house wanted autonomous AI in a regulated business. I designed the agents to propose and people to approve, then priced it against a payback date instead of a benefit narrative.
- Insurance
Sequencing the data foundation before anyone bought an AI agent
A financial group wanted AI scoring across five affiliates. I proposed one affiliate, eighteen weeks, and a data readiness report before a single model — because the alternative is an agent trained on data nobody has reconciled.
- E-commerce
Reading the money path first
A small commerce platform was days from taking real payments. I reviewed the trust boundaries before the features and found an order that could mark itself paid.
Something similar on your plate?
Thirty minutes, no deck. I will tell you whether it is worth doing at all.