Set up Vyre

Vyre / Architecture

How Vyre is built.

The architecture, on one page.

Vyre is one product for a team and its agents. It runs on a server you own and on the computers your people use. This page shows the layers, how a call is checked, how an agent’s turn runs and how the Gate holds anything that leaves your server.

Three ideas shape all of it

01

One small trusted core

The code that decides who may do what, keeps the history and holds secrets is small and separate. Features are modules around it, and a module cannot invent a new kind of permission.

02

A person decides

Anything that leaves your server waits until a person has seen the exact words and approved them. An agent can ask. It cannot approve.

03

Secrets stay out of the model’s reach

A model sees a placeholder. The real value is put in outside the model, at the moment of sending.

The layers.

From the app to the kernel, and out to the world.

Every machine runs the same daemon. Its config says whether the machine is a server, a solo Mac or a device that joins a server, and that picks which modules start.

Surfaces

The Vyre appWeb, iPhone, Android, Mac and Windows
The vyre command lineFor the terminal on any machine
Outside AI toolsConnected over MCP
Straight to the door
RelayAway from home, an encrypted path to a server with no open port

One daemon on each machine

DoorWorks out who is calling, builds that caller’s chain and applies the role’s tool list

Work

  • Chats
  • Tasks
  • Records
  • Flows
  • Agents
  • Documents

Keep

  • Files
  • Vault
  • Memory

Outward

  • Gate
  • Publish
  • Connections

Run

  • Sessions
  • Providers
  • Model routing

Kernel

IdentityKeys and devices
GrantsAnd five roles
Event logHash-linked
Flow runnerRuns Flows
SealingSecrets, in a child process
Run
A person’s own computerSandboxed sessions in an encrypted workspace, computer use, the Mac app
Outward, only after a person’s yes
Outside servicesMail, calendar, Drive, Dropbox, payments and DNS

Kernel

Identity, grants and the five roles, the event log, tasks and approvals, sealing, and the Flows engine. Almost no dependencies, and the same code runs on a server, a phone and a browser.

Core modules

The services features are made of: records, chats, files, vault, the Gate, agents, sessions, publishing, documents and connections. Each is a folder with a manifest.

Apps

One Expo codebase for web, iPhone and Android, and the Mac and Windows shells around it. They talk to the daemon’s API and never read a store directly.

Relay

Lets a paired device reach a server with no open port. It carries only encrypted traffic between devices that proved each other’s keys.

Local helpers

Code on a person’s own computer: running a Space’s sessions in a sandbox, computer use, the Mac app.

How a call flows.

Every caller goes through the same check.

A person in the app, an agent in a session, a Flow step and an outside AI over MCP all make calls the same way.

  1. 1The callerA person, an agent or a Flow calls a tool by name.
  2. 2The doorBuilds the chain from facts the daemon verified itself, then applies the role’s tool list.
  3. 3AuthorizeThe kernel answers allow, ask or deny for this chain, this action and this resource.
  4. 4The toolA module tool does the work. Every read and write of a record goes through one gateway.
  5. 5The logEvery decision and change is an event: who, what, when and the full chain.

Allow

The tool runs as that chain, writes what changed and returns the result.

Ask

The call is held and becomes a task for a person.

Deny

The caller is told the thing is not found. The real reason goes to the log.

  • The chain is never a name or a header.It is the paired device, the signed session, the agent that person started and the Flow step. The call has the intersection of what every link may do, so an agent never has more than the person who started it.
  • The log can be checked.Events are hash-linked and checkpointed, so a rollback is detectable.

How an agent’s turn runs.

A message or a task in, tool calls back through the door.

  1. 1A message or a taskA message in a chat, or a task given to an agent by a person, a tool or a Flow step.
  2. 2Model routingStarts headless sessions and streams them to every surface. A chat is a Vyre thread, so changing provider mid-conversation loses nothing.
  3. 3Session driverOne driver for each provider: Claude, Codex, Grok or OpenRouter, on the account you added.
  4. 4The providerClaude Code, Codex and Grok run as their own command-line agents with only Vyre’s tools connected.
  5. 5Vyre’s toolsEvery tool call the model makes comes back through the door, as the person or agent the session belongs to.
On a person’s own computerA sandbox and an encrypted workspace that opens only while the Space leases its key. The chat shows where it runs.
On the serverWhen a session does not run on a person’s computer, it runs here. A chat can move between the two with its turns.
  • Waking on a task.The agent starts one job session with the task, its record and where it came from. It finishes the task, hands it on, or marks it stuck, and a job that ends without doing so is marked stuck with the reason.
  • Instructions.Each agent and each project has an AGENTS.md. A session starts in its project’s folder and reads it natively.

The Gate.

Everything that leaves your server waits for a person.

The Gate is the hold queue for an email, a text, a post, a payment, a delete and a publication.

  1. 1Wants to sendAn agent or a Flow asks, with the text, the recipient and the reason.
  2. 2HeldThe request appears in Needs you.
  3. 3A person readsThey read the exact words and edit them if they want.
  4. 4ApprovesWith a hardware proof over those exact words. It works once.
  5. 5The VaultThe credential is fetched at send time. The model never sees it.
  6. 6SentExactly the approved words.
  • An agent cannot approve, revise or reject.Those calls refuse an agent caller.
  • The proof is a signature over the exact request.It is made on the person’s own device with Face ID, Touch ID, Windows Hello or a passkey, and works once for that act only.
  • Outward is declared, not guessed.A connector marks each operation as read, draft, change, send, spend or delete, and anything undeclared cannot be called.
  • A failed send goes back to held.Two screens approving at once send once.

Where data lives.

On your server and on your devices.

Records

The built-in SQLite store, or one Twenty CRM database for each Space behind the same interface.

Files

The Space’s Drive: encrypted chunks over local disk, S3 or a device. Linked Google Drive and Dropbox folders stay at the source and are read through each person’s own account.

Vault items

Sealed at rest. A member’s own vault opens with their own master password and Secret Key.

Sealed fields

Only inside the sealing process, a separate child process.

Keys that prove a person is there

Hardware on the person’s device: Secure Enclave, TPM, StrongBox or a passkey. They never reach the server.

Chat sessions

The machine that ran them. A chat can move between a person’s computer and the server with its turns.

Go deeper

Every claim on this page is explained in the repository, with the code paths. The architecture overview takes ten minutes. ARCHITECTURE.md lists one page for each feature. An AI agent can follow Map your business onto Vyre to see how a business would run on it.

Read the overview ARCHITECTURE.md

See it working.

Set up VyreBack to vyre.run