The architecture behind Voltade's managed, multi-tenant AI agent platform.
One deploy serves every business, isolated by row-level security. A new tenant is an INSERT, not a deployment.
It learns from your team's corrections and remembers — getting better week on week, without a retraining cycle.
Every action is a typed operation: shadow by default, logged to the row, and reversible.
Volty is a managed, pooled, multi-tenant AI agent platform. Every organisation that signs up gets one dedicated business agent — it answers on WhatsApp and email, remembers its customers, learns from the team, and acts in the tools the business already uses. There is no per-tenant build and no per-tenant deployment: every organisation runs on one shared codebase, one database, and one set of infrastructure, isolated from each other by design.
That single sentence hides three architectural commitments that took two years and 100+ deployed agents to settle on.
First, isolation is enforced at the data layer, not the application layer. Every row in the database is tagged with the organisation that owns it, and the database itself refuses to return rows that don't belong to the organisation making the request. One organisation cannot see another's data even if the application code has a bug.
Second, every capability the agent has is a typed operation in our codebase. The agent cannot take an action that isn't a declared operation with a defined role and risk level. There is no hidden orchestration layer underneath, and no way for a prompt to invent a new power.
Third, the agent is supervised by default. A new agent ships in shadow mode — it proposes, a human decides. An organisation graduates it to live on its own terms. Every customer-affecting action is recorded, bounded, and reversible.
The result is the difference between a clever assistant you talk to and a colleague your operations team will actually let near a paying customer. The rest of this document is how it works.
Most "AI platforms" are really one instance per customer, stood up by hand. That model is slow to provision, expensive to run, and drifts: every customer ends up on a slightly different version, and a fix in one place doesn't reach the others.
Volty takes the opposite stance: one deployment, one main branch, one database, organisation = tenant. A new organisation is created with a single record; there is no environment to spin up, no instance to configure, no migration to schedule. Everyone is always on the same version, and an improvement ships to every business at once.
The hard part of pooling many businesses into one system is keeping them apart. Volty does this with row-level security (RLS) in Postgres. Every table that holds tenant data carries an organisation key, and an RLS policy on the table only returns rows matching the organisation set for the current request. The organisation is set per-transaction, never globally, so it cannot leak between requests that share a connection. Isolation is a property of the database, enforced on every read and write — not a filter the application has to remember to apply.
The same wall has a second floor inside it: an organisation admin can see the organisation's shared work, but cannot read into an individual staff member's private inbox. Trust boundaries run between businesses and between roles within a business.
A common instinct is to let a business build many bots, one per task. We tried that and removed it. Volty gives each organisation exactly one agent, platform-provisioned and named "Volty," and lets the business shape its behaviour rather than assemble a fleet.
Behaviour varies by overlays: a base instruction set for the organisation, refined by an inbox overlay, refined by a per-channel overlay (tone, format, length). The overlays are composed by scope — each is included only when it matches the conversation it's in — so they never overlap at runtime and there is no precedence engine to reason about. The base remains the authority on identity, policy, and safety; overlays only add.
This mirrors how the leading agent platforms actually work: one configured agent with layered personality, not a swarm. It keeps the mental model simple for the business, keeps the safety story coherent, and keeps the door open — the underlying tables still allow multiple agents, neutered at the surface, so future collaboration roles need no migration. Identity and model are platform-owned; white-label identity (custom name, avatar, sender) is a paid-tier entitlement, while the customer-facing disclosure line stays editable at every tier.
Volty's agent is not a server waiting in a loop. It runs in wakes — bounded executions triggered by something that happened: an inbound message, a staff note, an approval decision, a scheduled follow-up, a heartbeat. Each wake is scoped to one conversation in one organisation and runs under that organisation's data boundary.
A few properties make this safe at platform scale:
The turn loop itself is built on a dedicated agent engine; every model call is routed through the gateway (Section 8) under the organisation's own key, so usage and cost stay tenant-scoped.
This is the heart of what makes Volty bounded. Every capability is an operation — a single typed declaration in our codebase. One declaration produces up to five surfaces from the same definition: a command the agent can run, a remote CLI verb, an HTTP endpoint, an automation SDK call, and (opt-in) a direct agent tool.
Two things ride on every operation: a role (admin, staff, or contact) and a risk class (safe, customer-affecting, external, or budget-affecting). Those gates apply on every surface, every time. The agent cannot do something a contact-role caller couldn't, and a customer-affecting operation is checked for authority before it runs — whether it's the agent, a staff member, or an automation calling it.
The payoff: there is no second, hidden way for the agent to act. If a power exists, it's an operation, and it's governed. If it's not an operation, the agent can't do it.
Volty's agent doesn't keep its knowledge in a prompt or a black-box vector store. It keeps it in a drive — a versioned file store that both humans and the agent share. Borrowing git's data model (content-addressed blobs, a working tree, immutable snapshots) without git itself, the drive gives every change a history.
The drive is partitioned into scopes: the organisation's knowledge base (the agent reads it), a per-contact memory (the agent writes what it learns about each customer), what the agent knows about each staff member, and the agent's own instructions and skills. Small text lives inline in the database; everything larger lives in object storage, written ahead of the database record so a dangling reference is structurally impossible.
At the start of a wake the agent's workspace is materialised; at the end, a snapshot captures what changed — the agent's "commit" for that turn. That snapshot history is not a bolt-on audit log; it is the record of how the agent's understanding of your business evolved, who changed what, and when. This is also how the agent improves: it learns from your team's corrections and writes them back, getting better week on week without a retraining cycle.
Volty separates three things that are usually muddled together: the agent (the actor), the channels (the transports a business owns — its WhatsApp Business number, its email), and the platform lines (shared Voltade infrastructure).
Businesses bring their own channels: a WhatsApp Business number via official Cloud API embedded signup, and email over SES, Gmail, Outlook, or IMAP. These route into the organisation's inbox, owned by the organisation, walled by RLS.
Two shared platform lines sit alongside: a Relay line for staff-facing traffic — notifications, approval cards, one-time sign-in codes, onboarding — and a Sandbox line for testing, where a tester can try any organisation they're entitled to without a separate number being provisioned. One shared line serves everyone; routing disambiguates who's who. No per-tenant phone-number provisioning.
Channels are pipes; inboxes are containers, and they're where the privacy model lives. An inbox is either individual (one person, optionally with delegates) or shared (a team, with explicit membership). Membership is enforced by RLS: a person — including an organisation admin — cannot see conversations in an inbox they're not a member of.
That means the privacy boundary isn't a setting that can be misconfigured into an open door. A staff member's individual inbox is invisible to the rest of the organisation by default, and team inboxes show only to their members. Delegation is explicit and can expire. The agent is enrolled into inboxes the same way a person is — visibility is uniform whether the member is human or machine.
Volty is model-neutral. Every model call goes through a gateway (Bifrost) that abstracts away which provider is behind it — GPT, Claude, or others — and meters it per organisation. Each organisation gets its own virtual key, provisioned automatically when it's created; usage, requests, and cost are tracked per tenant and rolled up for operators.
This is why "Volty runs on the same models you trust" is literally true: the intelligence comes from the frontier model providers; Volty adds the business context, the memory, the channels, the operations, and the governance around them. It also means routing and cost can be tuned per organisation without touching the agent, and a provider can be swapped without a rebuild.
The gateway is careful with prompt caching — it forwards provider cache controls unchanged and keeps tool definitions stable — so repeated context stays cheap and fast.
Volty is passwordless. People sign in with Google, Microsoft, an email one-time code, or WhatsApp — and an account is created on first sign-in. Identity is multi-tenant: a person can belong to more than one organisation, and there are two admin tiers — platform admins (Voltade, across tenants) and organisation admins (within their own business).
The subtle part is authority during a wake. The agent's permissions are re-derived every turn from the principal it's acting for, and enforced at the moment a tool runs — not assumed once at the start. A staff member steering the agent in one organisation can't have that authority bleed into another. There is no ambient "admin mode"; there is only the authority of the specific caller, checked at the specific action. This is what closes the confused-deputy gap that most agent stacks leave open.
For approvals that arrive outside a logged-in session — an approval card in WhatsApp — a one-time signed link carries just enough authority to decide that one action, and nothing more.
Volty runs on AWS in Singapore, defined entirely as code (Terraform/OpenTofu) across isolated production and staging environments. Compute is on managed containers behind a load balancer; the database is managed Postgres fronted by a transaction-pooling proxy (the same proxy discipline that makes the per-transaction isolation in Section 1 reliable). Object storage holds the drive's larger files.
Secrets are never in the repo: encrypted at rest, decrypted only where needed, and generated fresh on each infrastructure apply for internal credentials. Operators get read-only, single-sign-on access with no long-lived keys; operator tools sit behind a zero-trust gateway. Deploys are continuous from one branch, with database migrations run as a gated step. Cloudflare fronts the application for WAF and DDoS protection.
None of this is visible to the businesses on Volty — which is the point. The infrastructure is the part you should never have to think about.
Put the ten pieces together and you get properties a chat window cannot have:
A language model is the brain. Volty is everything around it that makes the brain safe to put in front of your customers. That's the difference between a demo and a business you can run on it.
This document describes Volty's architecture as designed and, in large part, as built. Some capabilities described here — particularly tenant-authored automations and multi-agent collaboration — are in active development as of publication. Voltade favours mechanism over implementation detail: the shape of the system is settled even where the last mile is still landing. For the engineering specifics behind any section, talk to us.
Custom AI agents, deployed in weeks. Singapore SMEs claim up to 50% PSG support; we handle the AIxDL claim on your behalf where it applies.
Free scoping. No commitment.