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 draft mode: it writes, a person sends. An organisation graduates it to live on its own terms, one behaviour at a time. 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 it 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 is shaped by placed instructions: prose fields that live on the surface each one governs. There are three, and only three: organisation-wide, team, and per-inbox. Each is addressed by where it sits rather than by a filename, so a rule about how one inbox answers is written on that inbox. Visibility follows the same wall as everything else: a member reads the organisation's fields and the inbox fields of inboxes they can already see.
Two deliberate constraints sit on top. The fields are capped. And they are read-only in the interface: the only way to change one is to ask Volty, which means every behaviour change arrives through the same reviewed, recorded path as any other action rather than through a textarea. The platform remains the authority on identity, policy, and safety, and a placed field cannot override it.
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, because 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 10) 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 in-turn, a remote CLI verb, an HTTP endpoint, an automation SDK call, and an MCP 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. Roles are monotone: a caller satisfies an operation's floor when their role ranks at or above it.
Because the registry also speaks MCP, the same governed catalogue is what an approved external client sees. The reverse direction is governed too: an organisation can connect its own MCP servers, and a call out to one is classed as an external-risk operation and gated like any other, rather than becoming a side door around the registry.
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.
SLA timers, scheduled digests, webhooks, and idempotent notifications belong in a fixed code path, not in an agent loop that re-decides them every time. Volty splits the two: the agent handles judgment, automations handle determinism.
An automation is per-organisation code deployed to a sandboxed runtime, with the same journal-replay durability the wake loop uses, so a restart resumes rather than re-fires. The unusual part is who writes it. Staff describe the rail in plain language and the agent authors it, then staff see the rendered result and can run, pause, version, or roll it back. They do not hand-edit the code, which is what keeps the deployed rail and its description from drifting apart.
Two rules keep this from becoming an escape hatch around Section 4:
Mini-apps run on the same substrate: small internal tools an organisation needs, authored the same way and governed by the same gates. A business can grow its own operational surface without a per-tenant deployment, and under the same approval record.
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, the agent's own skills, a private volume per staff member for their own uploads, and a volume per automation or mini-app holding the versioned deploy artifacts for the code above. Instructions are deliberately not among them. They live in the placed fields in Section 2, which keeps the drive a knowledge base and nothing else. 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.
The drive holds what the agent knows in prose. Two other surfaces hold what a business needs in rows.
Tables are organisation-defined structured data: typed column definitions over row storage, with one filter language shared by the agent's queries and any saved view, so what a person filters in the grid and what the agent queries are the same thing. Every part of the surface has an operation behind it, which means the agent can create a table, populate it, and query it under exactly the gates a staff member faces. A business that needs a register, a roster, or a pipeline does not need a per-tenant schema change to get one.
Tasks are the platform's work ledger. Any multi-step operation that takes real time (importing a website, extracting an upload, syncing a drive source, standing up a WhatsApp number) writes one durable, organisation-visible row with its progress and its outcome recorded separately, so "finished" and "finished successfully" are never the same field.
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 carries staff-facing traffic: notifications, approval cards, one-time sign-in codes, onboarding. A Sandbox line covers testing, where a tester can try any organisation they're entitled to without a separate number being provisioned. One shared line serves everyone, and 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, so visibility is uniform whether the member is human or machine.
Volty is model-neutral. Every model call goes through a single gateway that abstracts away which provider is behind it and meters it per organisation. Each organisation gets its own key, provisioned automatically when it's created, and every request writes a cost record against that organisation, so usage and spend are tenant-scoped rather than estimated after the fact. Admin-set monthly budget caps ride on the same record.
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. That property has been exercised rather than merely asserted: production was moved onto a different gateway in 2026 behind this seam, with no per-tenant migration, and the previous gateway is being retired on its own schedule rather than in the same step.
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. The first three create an account on first sign-in. WhatsApp is deliberately not one of them: a code goes only to a number already linked to an account, and an unknown number gets the same "code sent" response and no message, so the sign-in endpoint cannot be used to test which numbers are registered. 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, such as 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, defined entirely as code (OpenTofu) across isolated production and staging environments. Data is hosted in the ap-southeast-1 (Singapore) region. 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, and 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 twelve pieces together and you get properties a chat window cannot have:
No implementation project and no engineers on site. Volty interviews your team, drafts how it should answer, and tests itself before it talks to a single customer.
Free 7-day trial. We set your workspace up for you.