Aaron Wood

One gateway. Every product team's model calls run through it, and none of them name a vendor.

Problem

Model calls were going to spread across a large monolith, each with its own client, its own error handling, and no way to answer "what is this costing us, and for which tenant?"

Design

A single injectable service behind a narrow provider interface. Callers pass a model variation such as "normal" or "pro". No calling code anywhere names a vendor. Requests persist per tenant with input and output token counts, giving cost attribution and full history for free. I built and shipped that persistence layer myself, staged from development through staging to three production regions.

Result

Customer summaries, AI-generated preferences across two generations, message generation with brand-guideline enforcement, and the dashboard generator below all ship on the same foundation. Every rollout is gated per tenant. In production it carries enterprise tenants across those regions, and volume has grown substantially over the past year. Growth is nowhere near even between regions, which is why I describe the platform as a whole rather than quoting the flattering region.

Measured

The retry path is the one I have actually measured: in a representative week it roughly halved the user-visible failure rate, and no request ever exhausted its four-attempt budget. The per-request token accounting earned its place separately: it showed the busiest surface and the most expensive one were not the same: one feature carried a minority of the requests and most of the token spend, at several times the cost per call of anything else, because it ships a large context and gets a short answer back. Input dominates output by a wide margin across the platform, which puts the optimization on what gets sent rather than on what comes back.

Where the model stops

The preference engine on it is the clearest case of a call I keep making: the model extracts and classifies product attributes, but the matching itself is a weighting formula I designed, recency tiers against purchase consistency and clustering, with returns scored negatively. No model decides a preference. When that engine was rebuilt onto the warehouse for its second generation the formula was ported across unchanged, and the deterministic half was the half worth keeping.

PHP Vertex AI Gemini response schemas token accounting feature flags job queue

A short description goes in; a working dashboard comes out.

Problem

Every customer wants a slightly different view of their own data, and each one was a ticket: someone writes the warehouse SQL, someone lays out a screen, someone ships a release. That works for the first few customers and then it stops working.

Design

A generation job turns a plain-language request into a spec: warehouse queries, computed fields, and the UI components bound to them. The spec is data, not code, so the same definition can be validated, repaired, versioned, localized, and rendered on web and mobile.

Result

A dashboard that used to be a release cycle is now a generation job, with a human approving each one before it goes live. Built with a second backend engineer: I designed the generation, validation and repair pipeline, and I am the top author on the renderer.

How it is evaluated

The grading is deterministic, which is the kind I trust: every generated query is executed against the warehouse before a dashboard is shown, and the results have to be internally consistent, since a monthly total can never fall below the weekly one inside it. Nothing is graded by a model. Separately, for prompt work itself, I keep my own tooling: variants run repeatedly across model tiers, results stored and compared, and a second model used to grade the differences. Repetition is the point, because one good answer from a non-deterministic system is not evidence. A colleague later built the reusable version the team shares. Mine is the local one I iterate with, and the part worth knowing is why the input data has to be held constant or the comparison means nothing.

PHP BigQuery Gemini spec-driven UI job queue React Native renderer server-sent events

Drafts that start closer to how you actually write, and get closer over time.

Problem

A generated customer message is only useful if it sounds like the person sending it. A draft that reads like nobody gets rewritten from scratch, which is slower than not having it. On top of that, every brand has rules about tone, banned words, signatures and whether emoji are allowed, and those rules differ by channel.

Design

Prompt assembly is layered and ordered: who the message is for, then the sender, then the location, then the brand rules, then the channel. Above that sit personas at three levels of specificity, with the most specific winning, and each one is keyed per channel rather than per person: the same employee writing a text and writing an email are two different voices, and collapsing them into one flattens both. Every layer is separately gated, so any of it can be switched off for one tenant without disturbing the rest.

Result

Drafts that land closer to the sender's own voice, with brand rules enforced per channel underneath. It runs continuously across eighteen distinct request types, and the eighteen are not ad hoc: three subjects (the employee, the customer, and the relationship between them) times three operations (generate, refresh, evolve from a comparison) times two channels. The whole matrix is exercised in production. Mine since the first version, and still mine: I have maintained and extended it through every generation it has had.

PHP Gemini prompt layering job queue feature flags per-channel rules

Card-present terminals, gift cards, and online, behind one interface.

Problem

Multiple payment providers, physical terminals in retail stores, and real money in luxury retail, where a single basket can be worth thousands. When a terminal fails, the brand loses money and there is someone waiting at the counter.

Design

A provider-abstraction layer with connectors for each processor, per-tenant transaction logging, metrics, and provider health checks, so adding a processor extends the transaction flow rather than changing it.

What it taught me

An outage. A missing index made payments time out under load, and a handful of charges went through at the provider with no record of them on our side. The index was a real problem and we fixed it, but the timeouts exposed a second one: nothing durable was written before we called the provider, so an unknown outcome had nothing on our side to reconcile against. I built the attempt record: a row written before the call, with its own status lifecycle, its own table and its own indexes, so a charge cannot happen without something left behind to recover from. It is what the pending-attempt check below is looking at.

How it is watched

I designed the alerting framework that sits over it: scheduled reconciliation checks behind check and publisher interfaces, so a check knows nothing about where its alert goes and a publisher knows nothing about what raised it. The checks look for the things that should never happen, an orphaned transaction, an attempt stuck pending, an order with no customer token, a processor error code breaching its threshold. Seven other engineers have added checks and publishers to it since, without changing the interfaces, which is the same outcome as the connector seam and the reason I think the pattern is the point rather than either system.

Result

Still in production years later, and the count is the proof the seam held: I wrote the interface and seven of its connectors, and eight more have since been added by other engineers. It stopped needing me, which is the outcome you want from an abstraction. It is still the transaction path, running across multiple currencies and multiple providers, including card-present terminals in stores.

PHP card-present terminals gift cards distributed locking idempotency metrics