You asked for Postgres with row-level security multi-tenant isolation, and for verifiable proof rather than claims. So rather than describe the architecture, here it is running.
This page boots a genuine PostgreSQL instance compiled to WebAssembly inside your browser. Real tables, real CREATE POLICY statements, real SET ROLE. Nothing is mocked and nothing is sent anywhere — the database lives in this tab and dies when you close it. The SQL console below is unrestricted: run anything you like, including attempts to read another tenant's rows.
The application below never filters by tenant. Every button runs the identical query — SELECT name, state, status FROM partners ORDER BY id. Only the session's tenant context changes. The filtering happens inside Postgres, beneath the application, where a bug in the app layer cannot reach it.
This is the entire isolation mechanism. Eleven lines, applied once, and every future query against these tables inherits it — including queries written later by an n8n Code node, a dashboard, or a developer who has never heard of tenants.
Each button below is a real attempt to defeat the isolation, executed against the live database as the restricted application role. Run them. The point of this section is that the failures are produced by Postgres, not by validation code I wrote.
Unrestricted console, running as the application role app_user with the current tenant context. Try SELECT * FROM partners, or set the context to a tenant that does not exist, or attempt a cross-tenant UPDATE.
Your Phase 1 requirement was button-click approvals only, never automated sending. That is a database constraint here, not a convention. A row cannot reach sent without a recorded human approval — the trigger below rejects the transition, so an agent that decides to be helpful at 3am simply fails.
Preventing context rot in long-running agents. The honest answer is that you do not fix drift inside the agent — you make the agent stateless and put the state in Postgres. An agent that reconstructs its working context from a query at the start of every run cannot rot, because there is nothing accumulating to rot. What you then need is a way to notice when the model's judgement drifts, which is a different problem: a fixed set of canary inputs with known-correct outputs, replayed nightly, with the score written to a table and an alert when it moves. Drift becomes a number on a dashboard rather than something a client discovers six months later.
Six months unattended. Uptime is not the metric that matters — a workflow can run every night for six months and quietly produce worse output for the last three. The things that actually buy unattended reliability are all boring: idempotent steps keyed on a natural identifier so a retry cannot double-write, checkpointing per item rather than per run so a failure at item 400 does not replay items 1–399, dead-letter capture instead of silent swallowing, and the canary score above. All of it lives in Postgres, which is also why the database is the right place to start rather than the workflow canvas.
This prototype is the Phase 0 foundation in miniature: the tenancy model, the isolation, the gate, and the audit trail. It is a few hours of work, not a few weeks — which is rather the point of showing it instead of describing it.