Resident AI agents: a multi-agent system with roles

Besides the coding agents it starts for individual tasks, AR Labs runs a small set of resident agents: long-lived AI agents with their own role, instructions and working records, which keep working between conversations. An AI agent is a language model run in a loop with tools, so it can act as well as reply; a coding agent is one that writes code. This project is the engineering around the resident agents: where they run, how an operator maintains them, and how they and our local coding sessions exchange work. It is part of VOX OS, our design for an operating layer over agent work. The agents hold defined roles under a person's authority; they do not act as an autonomous swarm.

The agents and their roles

Each agent has its own page; AI agents at AR Labs lists them all with the coding, research and voice agents the lab also uses.

• The strategy agent runs our cadences, the recurring planning reviews held with Richard M. Thompson, who founded AR Labs, from yearly to daily. It runs as a skill (packaged instructions an agent loads only when a task needs them) loaded into a local session, and its memory lives in files rather than in any one conversation.
• The marketing manager agent, Night Shift researches, recommends, prepares writing briefs, keeps the marketing plan moving across sessions and measures results. Richard writes the content, and publishing, outreach and spending stay subject to his approval.
• Vox Prime is the identity local Claude Code and Codex sessions use to post and read messages in our shared chat workspace.

How they communicate

The figure places each party where it runs: the local coding sessions, their chat identity and the strategy agent on the laptop; the marketing manager agent and its nightly read-only copy of the repository on a server; and the shared chat workspace and file mailbox between them.

Two channels serve different purposes.

The shared file mailbox holds durable handoffs. A session writes a dated file addressed to an agent into an inbox folder; the agent replies with a dated file in an outbox folder and leaves a receipt. Files carry the instructions and the record; a message is only a nudge to look. No agent writes into another agent's workspace, and an agent addresses a role rather than whichever agent currently fills it.

The chat workspace carries visible conversation and notifications, with one thread per topic and explicit mentions when one party asks another to act. Each agent has its own app identity, and each receiving agent keeps an allowlist of which senders it will act on. A test counts only when the recipient replies with substance; a transport acknowledgement, a typing indicator or a startup notice does not complete a round trip.

The marketing manager agent also reads a copy of our main repository, refreshed nightly and treated as read-only, for company goals and for evidence of what we have built. That keeps one source for what a goal says, and lets the agent label a capability as described, measured or merely planned.

How they run

The resident agents run on Hermes, a third-party agent runtime, as background services on a rented Linux server. The runtime is the agent program at the centre of each agent's harness: everything around the model that shapes what an agent does, from the agent program to its instructions, skills, hooks, tools and checks. Each agent has an identity file, a workspace that is its own git repository, and skills; the marketing manager agent uses a public library of marketing skills installed as its author intended, with a web search and scraping service connected over MCP, the Model Context Protocol, and keeps its tasks in an issue tracker so they survive across sessions.

The project draws a firm line between two kinds of change. An authorised operator manages service configuration, credentials and restarts, using the runtime's supported commands and keeping a private backup first. The agent's own instructions, skills and records belong to the agent, and changes to them arrive as briefs in its mailbox, which it installs itself. Agents are deliberately prevented from editing their own credential and configuration stores, so a broken setting is repaired by the operator without weakening that protection. Every operating procedure ends in verification: the setting persisted, the service is running, the adapter connected, and, for messaging, the intended recipient answered.

What exists today

The marketing manager agent runs as a service. In November 2026 a local coding session, posting as Vox Prime, sent a request to the marketing manager agent and read its confirmation, and the agent left a receipt in the mailbox, so directed messaging between that pair is verified.

Not built: automatic delivery of chat messages into an open local coding session. Vox Prime can send and read while a session is active, but nothing wakes or resumes a session when a message arrives; the researched design for that bridge is described on the Vox Prime page. The marketing manager agent's fuller designed structure, and the plan to package it for other owners of the same runtime, are described on its page.

How it was built

Our first multi-agent designs, from late 2025, coordinated a team of coding agents through a shared task graph and an agent-to-agent mail system; the mail layer did not produce reliable coordination. Later fleet plans proposed an agent per role on a server, of which two decisions survived (scheduled runs rather than a constant heartbeat, and one agent at a time until trust is earned) while the phases did not start. An experiment that used an always-on agent platform for overnight analysis showed that deep analytical work fitted better in a full working session, and that use was replaced. The current project, set up in November 2026, keeps only verified operating facts in one place per agent and treats every capability as unverified until a round trip proves it.