This one is unreleased, so it does not get a name, a screenshot or a link. What follows is the shape of the problem and the part of it I worked on, which is the publishable half.
It is a backend platform that other applications call to add emotionally aware behaviour to their own products. It holds per-person memory, reads emotional signal from a conversation, decides whether an AI is allowed to act in a given moment, and keeps an auditable record of every decision and the reason for it. Partner engineering teams integrate over an HTTP API or an MCP server; an internal operations team runs tenants, keys, spend and audit trails through a console.
The reason it exists is that every product wanting this capability otherwise rebuilds the same untrustworthy half of it: memory that drifts, emotion inference nobody has calibrated, and no record of why the system did what it did.
I am one of about seven people on it. Before the company hired a CTO I spent months planning the system, and a good amount of that planning carried through into what actually got built. I had not done ground-up design at that scale before, and it is the part of this job I have learned the most from.
What I did
Metering, keys and budgets. API key lifecycle including rotation, revocation and expiry, per-tenant spend caps enforced at request time, usage aggregation with per-model cost attribution, a partner-facing usage endpoint, per-key rate limiting banded by how slow the capability is, and a prepaid credit ledger with an atomic balance.
Admin identity and the console. The hosted-auth session layer and the SPA auth shell, the actor and session schema, server-side roles, per-mutation actor attribution, and retiring a shared bearer token in favour of real sessions. Then the console itself: the invocation log with trace drill-down, capability config editing, a cross-tenant audit and decision-log viewer, server-side pagination, and the safety around destructive actions, which is an impact preview, a typed confirmation and an undo window.
The adoption surface. The MCP server, a partner-facing memory read and history surface, the quickstart on the docs site, and a reference demo with synthetic personas showing an affect trajectory and a refusal gate alongside the decision record that produced it.
What makes it hard
Tenant isolation has three layers and each fails silently. Postgres row level security constrains a table's owner, so a database whose tables are still owned by the bootstrap superuser has policies that are purely decorative, and nothing errors. The tenant identifier has to be set inside the same transaction as the query. And a shared package cannot import the database client at all, because generation writes that client back into the package and a bare import resolves to whichever copy got hoisted. Every one of those is invisible when wrong. The codebase forbids writing a tenant filter by hand precisely because a hand-written filter looks correct and proves nothing.
There is deliberately no gateway in front of the language models, and the reason was measured rather than assumed. A proxy in that position silently stripped a provider-specific parameter and broke every structured-output call, so failover runs in process instead. That has a subtle consequence: a failover chain sends one schema that both providers have to accept, and one provider's strict mode rejects what the other takes as-is. So a relaxed schema goes on the wire while the original stays the validator, and nothing loosened for a provider widens what the system itself will accept. The invocation record also stores the model that actually served rather than the one requested, because on failover those differ and both billing and evaluation key off it.
Generation fails closed. No key returns an error, never a synthetic answer shaped like a real one. The contract with a partner is that they degrade to "no memory", never to confidently wrong.
The deploy has traps that go green. Two services behind one hostname each need their own durable-jobs registration and both must be resynced; miss the second and its functions never register, quietly. A missing hostname variable makes the stack fall back to a local default, which produces a certificate nobody can reach and a redirect into a dead name, with nothing in the run log to say so.
What I took from it
- A safeguard that cannot fail loudly is not a safeguard. The tenancy work taught me to ask "how would I find out this is off?" before "is it on?"
- Write the decision down with the thing that would overturn it. Every architecture choice here traces to a measurement, and the ones with a stated falsifier are the only ones anyone can revisit honestly later
- Make the wrong thing impossible rather than discouraged. An admin mutation writes its attribution row in the same transaction as the change, so an unattributed write is not a thing you can express
- Fail closed when you are unsure, and be explicit that you did. A partner can design around "no answer"; nobody can design around a confident wrong one
- A green pipeline is evidence the pipeline ran, not that the thing works