Synth AI
An agent platform a company other than mine can run
An internal agent platform rebuilt as something an outside company can buy, run and trust with its own data — six agents, a workspace per team, and an approval step before anything leaves the building.
The problem
Internal tooling is written on the assumption that there is exactly one customer, and that customer is you. Every shortcut follows from it: one shared login, no roles, data access scoped to nothing because there is nothing to scope it against. The features look finished. The moment a second organisation signs up, almost none of it is safe, and the work of making it safe is invisible from the outside — which is why it is usually discovered after the first customer is already on the platform.
How it is put together
- 01
A workspace model where the organisation and the workspace are separate concerns, so one company can run several teams without duplicating identity or billing.
- 02
Six roles carrying forty-eight distinct permissions, applied by a reviewed table rather than by judgement at each call site.
- 03
An approval executor that sends only what a human has explicitly released, with a staff sign-off before any organisation's first outbound message and a kill switch above it.
- 04
A credit ledger with two buckets — a plan allowance that resets each period, and purchased top-ups that expire oldest-first — because a single counter cannot answer what a customer is owed when they cancel.
- 05
Model routing by task rather than by vendor: a small model classifies, a mid-sized one drafts and reasons, and the largest is reserved for the mode that asks for it.
The hard parts
Retrofitting tenancy onto routes that never had it
One hundred and sixty-three routes already existed, every one written when there was a single tenant. Adding a check to each by hand is how you get a codebase that is ninety-eight per cent protected, with the gap in a route nobody remembers. Instead the permissions were applied from a reviewed table — every route named explicitly, with the internal-only ones listed as internal-only — so the question at review time was "is this row right" rather than "did we miss a file". The proof is a test matrix that stands two organisations up and tries every route from each: zero reads across the boundary, and zero cases where a write to another tenant's record returned success.
A guard that runs in production, not in a report
A tenancy guard is easy to add in warning mode and easy to leave there for ever, because enforcing it risks breaking a request nobody has thought about. It ran in warning mode first, logged nothing for the whole period, and only then was switched to refuse. Enforcement is the only state that is worth anything — a warning nobody reads is a guard that has been disabled politely.
The parts that make it buyable are the parts with no demo
Sessions that rotate with a grace window so a refresh does not log you out, lockout on repeated failures, Argon2id rather than a fast hash, time-based second factor, an audit trail of every write, and an invite flow that does not leak whether an address is registered. None of it appears in a feature list and all of it is the reason a company is willing to put its pipeline in. The industry kits ship marked beta until an evaluation on labelled leads clears its bar, because a kit that looks complete and recommends the wrong prospects is worse than no kit.
Is your internal tool one customer away from being a product?
The gap is rarely features. It is tenancy, roles, approvals and billing — the parts nobody builds while there is only one user, and all of which have to be true before the second one arrives.
Get in touch