The Owner's Guide to AI That Does the Work.
Six levels, each fixing one pain, each with a way to start today. Free.
What it does
The Antrix OS agent layer is the part of the system that runs without you at the keyboard. It's the system I run my own companies on; members get it with the AI Operators Guild. It takes the build workflow from the previous guide — the skills, the stack modules, the quality gates — and adds the machinery that runs it on a schedule, on a machine of its own, and reports back.
The pieces: a web dashboard where you set up projects, agents, schedules, skills, secrets and connectors; a daemon on a Mac that reports in every 30 seconds and opens a Claude Code or Codex session whenever the dashboard asks for one; personas, the five agent templates (fullstack-dev, designer, content, quality, research); schedules, the crons behind the daily report, the overnight run and the backups; the Operator OS folder on Google Drive, where context, deliverables and memory live; and Telegram, where the questions and the approvals reach you. Claude Code leads throughout. A second model plans independently; Copilot reviews the PR. For a business owner the same loop runs the Monday brief and the inbox pass instead of pull requests; the Guild's Antrix OS course installs it lesson by lesson, and members get the machine free.
Why it works
A solo developer's biggest constraint isn't skill — it's time and context-switching. You can only work on one thing at a time. You lose hours switching between projects. You can't ship while you sleep. This layer removes those constraints.
You define the work — GitHub Issues, feature descriptions, bug reports, or a schedule with a prompt — and the system executes it on its own. Features get built, reviewed, tested, and delivered as pull requests while you sleep, commute, or work on something else. Several projects run at the same time without conflicts, because each agent runs in its own session and each piece of work in its own git worktree.
In the morning, you read the report, review the PRs and merge what is good. You're the technical lead, not the line developer. Your job is direction and approval, not implementation. The system handles the rest.
How it works
Step 1: Phase 1: The dashboard, one place for everything
The dashboard is a web app (Next.js, deployed to Vercel from your own fork). It is the only place you configure anything: projects and their repositories, agents, tasks, schedules, skills, stacks, secrets, connectors. Everything you set there is written to a database (Supabase) that is the single source of truth. The Mac never holds a config file you edit by hand.
It is single-tenant by design. Sign-ups are off; you create one operator account, and every login needs a code from an authenticator app. /activity is the event feed: every spawn, every pairing, every failure, with its payload. When something goes wrong, that is where you look first.
Step 2: Phase 2: Pair a Mac with one command
Open Pair a machine in the dashboard. It shows a one-line install command with a pairing code that expires after 15 minutes. Paste it into a terminal on the Mac that will run the agents. The installer checks the code first, so a typo fails in seconds; then it installs what the agents need (Homebrew, Node, tmux, the GitHub CLI, the Claude Code and Codex CLIs), redeems the code, and installs the daemon as a background service. From a blank Mac to a paired one is 15 to 25 minutes, most of it downloads.
Two things happen by hand afterwards: claude auth login, and codex login if you use Codex. Back in the dashboard, the page flips to connected within about 90 seconds, and the Mac appears on /machines with its heartbeat ticking.
From then on every credential goes in /secrets: the GitHub token, the Telegram bot token, the chat id. The daemon picks each one up within seconds and puts it where the tools expect it. You never edit an env file on the Mac. Pair as many Macs as you like; they share the same skills, stacks and secrets.
Step 3: Phase 3: The daemon: heartbeat, and wanted versus running
One background process runs on each paired Mac. It sends a heartbeat every 30 seconds, and on every tick it compares what you asked for with what is actually running, then makes them match. You want an agent running and there is no session: it opens one. You pressed Kill: it closes it. A session crashed: the heartbeat goes stale, the agent flips to dead, and it is respawned if you still want it.
Each agent is a Claude Code (or Codex) session inside its own tmux session on the Mac, tagged with the agent's id so a Telegram reply finds its way back. The daemon keeps no state between ticks; it re-reads the database every time, so if it restarts it simply converges again. The same loop keeps skills, stacks and secrets on the Mac in step with the dashboard, and every 30 minutes it walks each repository's open GitHub Issues into the task list so agents can pick them up.
Earlier versions ran this as a handful of shell daemons and a watchdog. They were folded into this one process, and the cadence of every job is now a row you can see and edit on the dashboard, not a config file on the machine.
Step 4: Phase 4: Personas, and spawning an agent
Five personas ship as templates. fullstack-dev writes code across the stack: pages, components, APIs, database work, payments, fixes. designer produces design specs, not code; the fullstack-dev agent implements them. content writes copy, documentation and email sequences in your brand voice. quality reviews code, writes tests, runs security audits, and fixes what it finds. research is read-only: it explores a codebase or a market and hands its findings to the others. Each template is a plain file you can read and edit, synced to every machine.
An agent is created under a project: a name, a role, a model from the catalog (Claude and Codex models, grouped by provider), the repository it works in, the skills it may use, an orchestration mode, and a reasoning effort. Press Spawn. Within about ten seconds the daemon opens the session with the agent's prompt and skills, and the spawn lands on /activity. Press Kill when you want it gone.
Step 5: Phase 5: Schedules: what runs, and when
/schedules lists every recurring job as a row with a cadence you can toggle, edit, or trigger by hand. Two kinds. Internal ones the daemon runs itself, without opening a session: the overnight run (03:30, with a second sweep at 08:30) that hands unassigned GitHub Issues to agents, the daily report at 09:00, the health report at 08:00, the nightly database backup at 02:30, the project sync every 30 minutes.
And user schedules: a cron, a timezone, a prompt, a model, the skills, and the project it belongs to. When one fires, a normal Claude Code session runs the prompt. When its turn ends, the run is booked complete with the agent's own last message, and a Telegram line goes out if you asked for one. A run that stops making progress is killed and retried once; a second stall is reported as a failure.
The seeded user schedules are the ones I run: the inbox digest at 11:00, the weekly retro on Monday morning, the daily ops review at 07:15. Add your own from /schedules/new; the shape is in the block below.
Step 6: Phase 6: Skills, stacks and connectors
/skills is an editor over the skills the agents may use. Save, and the file lands in ~/.claude/skills on every paired Mac within seconds; edit it on the Mac and the dashboard picks that up too. /stacks holds the per-stack constraints (the Next.js rules, the Rails rules) the same way.
/connectors is how agents reach your tools: Gmail, Calendar, Slack and the rest through Composio, plus any custom MCP server you add. The agents never see the credentials. Each session talks to a small gateway on the Mac that checks who is asking, enforces the project scope and the tool allowlist, injects the key, and logs a digest of every call. The card on /connectors shows the status, the tools, today's call count and the last errors.
Step 7: Phase 7: The Operator OS folder on Drive
Code lives in git. Everything else an agent needs lives in one folder on a Google Shared Drive, mounted on every machine by Drive for Desktop: who you are and how you work, one folder per project with its brand, offers and memory, every deliverable an agent writes (outputs/, one file per day and topic), Claude's own memory, a mirror of the skills, and the MCP config a laptop needs. Every session gets it, whether the daemon opened it or you started it from your laptop. Nothing in it is loaded until a file is opened, so the folder costs no context.
Two internal schedules keep it in shape: os-sync (twice an hour) scaffolds a folder for every project and regenerates the generated files; os-outputs (every five minutes) indexes new deliverables into /outputs and sends a Telegram line for each one. A laptop joins with one command, ax-os bootstrap, and ax-os claude <project> starts Claude Code with the folder, the repos, the memory and the connectors wired in.
Step 8: Phase 8: Telegram: what reaches you, and approvals
Every notification goes to Telegram: start of work, PR opened, review addressed, done, and the three that need you: BLOCKED, APPROVAL NEEDED, FAILURE. Those three also go by email, so the inbox stays quiet and nothing that needs a decision gets lost. Reply in the chat and the daemon routes your message to the live session; @name addresses one agent, /agents lists them, /status asks the machine how it is.
That is the whole loop. The daily report says what happened; the pull requests wait on GitHub; the deliverables sit in /outputs; the questions sit in Telegram. You approve, redirect, or say no.
The shape of a schedule
# One user schedule, written out. It is a row on /schedules, # not a file on disk: the daemon reads it on every tick. name: inbox-digest cadence: 0 11 * * * # cron, evaluated in the row's timezone timezone: Europe/Belgrade project: my-business # which Operator OS folder receives the output model: (any Claude or Codex model in the catalog) skills: ax-inbox-digest prompt_md: Run /ax-inbox-digest for yesterday's mail. notify_on_complete: true # one Telegram line when the run completes keep_alive: true # leave the session open to talk to afterwards
AI prompt to get started
I just paired a Mac to my Antrix OS dashboard. Help me: 1) create my first project and connect its GitHub repository, 2) add gh_token and the Telegram secrets on /secrets and confirm gh auth status on the Mac, 3) spawn one fullstack-dev agent on a small issue and watch /activity, 4) turn on the daily-report and overnight schedules and check the first report in the morning.
Mistakes to avoid
- Running the agents on your personal machine — use a dedicated Mac. Agent sessions are heavy, and the daemon should not compete with you for the machine
- Skipping Telegram — without it you won't know when a run finished, a session died, or an agent is waiting on an answer
- Managing sessions by hand in tmux instead of from the dashboard — the daemon owns spawn, restart and cleanup. A session it didn't open is one it won't look after
- Editing env files on the Mac — every credential goes in /secrets; the daemon puts it where it belongs, on every machine
- Not reviewing overnight PRs carefully — autonomous doesn't mean unsupervised. Review every PR before merging. You're the technical lead, not the rubber stamp
- Turning on every schedule on day one — start with the daily report and one project, read a week of reports, then add the overnight run
Where to go from here
That's the whole system, the same one that builds and ships the projects on this site. Start small: one project, one overnight run, the PR reviewed in the morning. If you'd rather have it installed lesson by lesson, with the schedules that run a business rather than a codebase, the AI Operators Guild is where that happens; members get Antrix OS free.
Was this useful?
New guides land with you first: one process a business was doing by hand, and what it took to make it stop.