For operators already running more than one AI agent, with nowhere to see what they did.
One Operator. One Dashboard.
A Fleet Of AI Agents Behind It.
Once you run more than one agent, the bottleneck stops being what they can do and starts being where you say yes. This is the full build of a local-first command centre: the stack, the action queue every agent writes into, the phone layer, the voice call, and the eight copy-paste prompts that build each piece.
One approval surface
Every agent proposal lands in the same queue
Four teams behind it
Each in its own project, own memory, own scope
Approve from your pocket
Web, installed app, or a spoken word
The Bet
Agents Propose, You Decide, Executors Apply
One sentence that every other decision in this build falls out of. Get it wrong and you are building an admin panel.
Picture several agent teams, each in its own project with its own skills, memory and scope. An orchestrator that owns the portfolio view. An assistant that owns email and calendar. Sales, marketing and content teams alongside them. They run all day and they produce all day.
The dashboard is where all of that lands. It is not an admin panel bolted onto a product. It is the product: one surface where you see state, approve proposed work, route it, and talk to the orchestrator by text or voice.
01. Agents propose
Teams run on schedules, process meetings, watch inboxes. Everything they want done becomes a proposal, never an action.
02. The human decides
One surface. Approve, reject, vary with a comment, delegate, or snooze. This is the only place autonomy is granted.
03. Executors apply
Mechanical code applies the decision. It creates the task, posts the handoff, appends to the file. It never decides.
The design bet is one sentence: agents propose, the human decides, executors apply.
Every other decision in this guide falls out of that one. When you are unsure how to build a piece, ask which of the three jobs it is doing. If a component is doing two of them, split it.
Foundations
Boring Where It Can Be, Unusual Where It Counts
Every piece is either mainstream or absent, and the absences are the interesting part. Fewer moving parts is what lets an agent hold the whole system in its head.
The stack is deliberately conservative. Every piece is either mainstream or absent, and the absences are the interesting part. Fewer moving parts means an agent can hold the whole system in its head, which matters a great deal when agents write most of the code.
Layer
Choice
Why
Framework
Next.js App Router, server components
Pages are server-rendered reads of local data. Almost no client JavaScript outside the interactive islands.
Database
SQLite via better-sqlite3, WAL mode
Synchronous, zero config, one file. The schema bootstraps itself on open, so a fresh machine just works.
Styling
Tailwind plus one shared token file
Design tokens live in one CSS layer, synced verbatim across sibling apps.
UI primitives
Hand-rolled on Radix
Cards, tables, badges, meters. No heavy kit to fight.
Agent runtime
Claude Code CLI
The chat and voice brains spawn the authenticated CLI. No API keys in the app.
Fallback brain
A local model on the same machine
Chat talks to a brain interface, not a vendor. Degraded beats down.
Voice
LiveKit over WebRTC, plus a Python worker
Voice detection, speech to text, text to speech. The worker never thinks.
Desktop
Tauri v2
A thin native shell, not an app.
Network
Tailscale
A private mesh that replaces the entire auth layer.
Scheduling
A plain cron worker
Deterministic jobs run as code. A model session wakes only when judgement is needed.
Quality gate
Lint, typecheck, test, build
One command. Agents run it before claiming done.
Data flow: sources to screen
YAML state file
Portfolio truth: projects, goals, priorities
External APIs
Analytics, ads, search console, CRM, scheduler
Agent outputs
Briefs, reports, wiki pages, markdown mirrors
Sources
SQLite
One file, WAL mode, about 45 tables. Self-heals on page load.
Projection
Next.js
App Router, server components, every page force-dynamic
API routes
Every mutation explicit, no server actions
App server
Browser
Desktop web
Installed PWA
Phone home screen
Tauri shell
Native Mac app
Surfaces
Decision: no client state library.
No store, no query cache. Server components read SQLite fresh on every request, and a tiny client component refreshes the route every 60 seconds and on tab focus. With one user and a local database, cache invalidation is a problem you can simply refuse to have.
Decision: no server actions.
Every mutation is a named API route. That makes each write path a contract other things can call: the desktop shell polls one route for its tray badge, the voice worker posts to another, external agents push to a third. A server action would hide those contracts inside the framework.
Decision: files stay the source of truth.
The database is a projection, never the author. A YAML file holds portfolio state, sync is one-way into SQLite, and it never writes back. A drift check flags when the current week rolls forward but the content underneath is stale, and paints a red banner rather than serving old plans under a fresh date. Silent staleness is treated as a bug class of its own.
If you want the wider view of what belongs in a stack like this and how to keep track of it, build your own AI stack covers the manifest side, and context engineering covers what the agents read before they touch any of it.
Foundations
The Action Queue: Where Agents And Humans Actually Meet
Not a message broker. One SQLite table, and the entire human-in-the-loop contract encoded in its columns.
The centrepiece is one SQLite table. Not a message broker, not a service: a table. Every piece of work an agent wants done lands here as a row, and the whole human-in-the-loop contract is encoded in its columns.
action_queue
kindtask, reply, insight, content, or a maintenance fix
teamwhich agent team's consumer drains it
originwho produced it: an agent, you, voice, an external peer
laneauto (team-internal, born approved) or approve (waits for you)
statusthe lifecycle below
payloadJSON: destinations, routing attributes, a summary line, subtask steps
Row lifecycle
Born
The human decides
The executor applies
Undo reopens a decided row, but refuses once the row is applied. The calendar task or the message now exists in the real world, and the database does not get to pretend otherwise.
Producers
Rows arrive from everywhere. Agent skills insert via a small CLI against the same table. A meeting processor extracts follow-ups from each client call. A reconciler compares portfolio state against the calendar. Voice dispatch inserts from speech. External agents push over token-gated HTTP. Deduplication is a queue-level contract, not each producer's problem.
Decision: destinations resolve at insert time.
Every producer must say where the work goes before it ships the row. A routing table decides it: delegate to a person, the client's own tool, the team board, or your calendar. Producers too dumb to decide, like a regex, set a needs-routing flag and the board makes you route before approving. Approval never guesses.
Two-tier consumption
Approved rows drain in two tiers. A headless executor runs first on a plain cron scheduler: no model, just code that applies mechanical destinations. Its gate contract is charmingly unix. Empty output means nothing is left. Any output wakes a Claude session to handle the rows that need judgement. Most cycles never spend a single token.
Delegation, three ways
To a person
The row waits in a waiting-on-others lane while the assistant agent writes and sends the handoff. Approving the row is approving that send.
To an agent team
The row moves to that team's queue pre-approved. Your delegation is the approval.
To a client
Draft only. The executor writes the ask and inserts it back as a new reply row for approval. Nothing reaches a client without a second tap.
The queue only earns its keep once several agents write into it. For how to design the teams on the other end of it, read AI agent orchestration, and multi-agent systems explained for where those setups usually break.
Enjoying the guide?
Enter your details to unlock the remaining insights. We'll also send you the complete guide as a reference.
The Screens
The Screens An AI Dashboard Needs
Around 45 pages that reduce to nine repeatable surface types, and the reason none of them call an external API at render time.
Around 45 pages, grouped by agent team in the sidebar. They fall into a small number of repeatable surface types, and that taxonomy is the useful part. Each team gets its own section built from the same primitives, so adding a team is mostly adding pages, not patterns.
Approval board
The queue. Pending, stuck, failed, delegated and snoozed lanes. Keyboard triage, batch decisions, a routing modal, per-team tabs.
Swipe deck
One card at a time for phone triage. Right approves, left rejects, everything undoable.
Portfolio and goals
Project status buckets, weekly priorities, a goal cascade with pace meters, and the drift banner.
Activity feed
Every routine fire, brief and capture on one timeline, so the fleet is auditable at a glance.
Chat
Streaming conversation with the orchestrator. A chat answer becomes a queue row with one click.
Voice call
A live call with the agent, with captions and on-screen task cards.
Knowledge maps
Force-directed graphs over the wikis, with full-text search into a transcript archive.
Analytics
Cross-platform web, paid and organic dashboards fed by daily sync jobs.
Pipelines
Kanban boards for content stages and calendars for drafts, mirroring each team's working folders.
Sync to local, render from local
The analytics pages pull from a stack of external APIs: web analytics, search console, paid ads, CRM, email, social. None of them are called at render time. Daily sync scripts fetch each platform into SQLite, and every platform is wrapped in its own error handling with a sync-status row, so one failed API never aborts the run and every gap is visible on the dashboard.
Decision: no charting library.
Zero chart dependencies. Line charts are about 200 lines of hand-rolled SVG with a nearest-point hover tooltip. Knowledge maps are canvas force-directed graphs sharing one set of stateless draw helpers. Everything else is a component system: stat cards, delta badges, tone-coded meters, kanbans, calendars, timelines. Total control over theming, and no fighting a library's opinions for the two chart types you actually need.
The pattern generalises: treat every external API as a sync source, not a live dependency.
Pages stay fast, the dashboard still works when a vendor is down, and rate limits become a batch problem instead of something your screen has to explain.
If you already have dashboards and want the AI layer on top of them rather than a rebuild, our sister agency covers the six approaches in AI-powered reporting for existing dashboards.
The Screens
Wikis That Compound Instead Of Decay
Do the thinking when you write, not when you ask. The difference between a knowledge layer that gets cheaper every month and one that burns tokens forever.
Under the dashboard sits a set of wikis. A meeting wiki holding every call as a synthesised page plus the full verbatim transcript. A system wiki mapping the AI estate itself: frameworks, skills, automations, and how they connect. Per-team wikis where each team folds in what it learns. They share one design rule that makes them work.
Decision: synthesis happens at ingest, not at query.
Writing is where the thinking happens. When a meeting lands, an ingest skill files it once: a page with decisions and actions, entity pages for people and companies, cross-links into connection threads, and the raw transcript into a full-text index. Every later question is a cheap read. The alternative, re-deriving context from raw transcripts on every query, burns tokens and never compounds.
01. Index-first routing
Agents read a generated index and routing file before searching, so most queries resolve without touching the search layer at all. Indexes are generated by a maintenance script, never hand-edited.
02. Two search layers
SQLite full-text search for exact matches over transcripts, a vector index for semantic recall. Both are fallbacks behind the index.
03. One gate to the source API
Exactly one skill may call the meeting recorder's API, and only when the wiki misses. The fallback files what it fetched, so a miss enriches the wiki instead of leaking around it.
04. Rendered, not buried
The dashboard draws each wiki as a force-directed graph with full-text search, decision registries, and decide-in-place cards that feed the action queue straight from a wiki page.
The payoff is a flywheel.
Agents answer from the wiki. Wiki gaps trigger ingest. Ingest improves the wiki. The next answer is cheaper than the last. This is the one part of the system that gets better while you sleep, which is why it is worth starting early even if it is rough.
The meeting wiki has a full build of its own in the meeting wiki brain, and the wider case for wikis over raw retrieval is in build an LLM wiki for your AI stack.
In Your Pocket
Your Phone Becomes The Approval Surface
An installed app with no service worker on purpose, a swipe deck built on raw touch events, and a Mac shell with ceilings written into its own README.
Approving from a laptop is fine. Approving from a queue in your pocket while the kettle boils is what actually clears the backlog. Three surfaces get you there, and none of them is a rewrite.
The Mac shell
The native app is Tauri v2 wrapping the hosted dashboards. It has hard ceilings written into its own README: at most two static HTML files, a poller that only polls, no external sends, no sidecar process. Everything real lives on the server. The shell adds what only a native app can.
App-wide switching
Cmd-1 to Cmd-4 jump between sibling dashboards via a native menu, with a dedicated shortcut straight to the approval board.
Global hotkeys
A quick-capture box from any app, a summon key, and a clipboard capture that deliberately never echoes clipboard contents into the notification, because it could be a password on a lock screen.
Tray and dock badge
A 30-second poller reads one JSON endpoint and keys new work off the highest row id, not the count, so approvals between polls never read as new items.
Self-healing
If the server is down, the shell bounces to a local launcher page that health-checks and retries every 3 seconds, then returns on its own.
An origin allowlist
Exact origin matches only. Any other link opens in the default browser, and remote pages get zero native access.
Trade-off: work around the OS, in writing.
The current macOS release has a status-bar bug where tray icons register but never render. Rather than fight it, the shell documents the bug, keeps the tray code for when the fix lands, and promotes menu accelerators plus the dock badge to primary. Honest constraint notes in the repo beat clever workarounds that rot.
The PWA layer
Each dashboard ships a web manifest with standalone display, a dark theme colour and maskable icons, so it installs to a phone home screen as its own app. iOS gets the full treatment: translucent status bar, viewport cover for notched screens, and safe-area insets padded back in CSS.
Decision: no service worker, on purpose.
The data is live and local, so offline caching would only serve stale state. A command centre lying to you from cache is worse than one that says it cannot reach the server. Freshness comes from the 60-second refresh loop instead. Install is add-to-home-screen, nothing more.
Decision: one HTTPS origin for the whole fleet.
All sibling dashboards mount as paths on a single origin behind the mesh VPN. The reason is an iOS quirk: cross-origin links inside an installed app open in browser chrome, while same-origin links stay chrome-free. One origin makes the dashboard switcher feel like moving between tabs of one app.
Below 768px a shared mobile shell takes over: a fixed bottom tab bar with four pinned tabs plus a swipe-up sheet holding everything else. It is one file with zero dependencies, synced verbatim across all sibling apps by a design-sync script alongside a shared token layer. Change the design once, every app follows.
The swipe deck
The phone's fast lane is one pending action per card. Swipe right to approve, left to reject. The gesture handling is a small hook on raw touch events, and the details are where it earns its keep.
Intent detection
The drag only engages when clearly horizontal, beyond 14px and more than 1.5 times the vertical movement, so scrolling through a card never fights the gesture.
Commit threshold
The larger of 120px or 40% of card width, then a 220ms settle.
Fly first, act second
The card animates off screen before the API call fires. Waiting for the server before moving read as a glitch. Optimistic motion plus an undo button reads as speed.
Touch-cancel handling
iOS fires a cancel event when the system claims a gesture, on edge swipes or a notification pull. Without handling it, a card freezes mid-transform.
Keyboard parity
Desktop keys route through the same commit functions, so a keypress plays the same animation as the swipe.
The voice screen uses a different trick for paging on mobile: CSS scroll-snap, one full-screen pane per task, no gesture code at all. New panes only append to the right, so a task arriving mid-read never shifts the one being read.
In Your Pocket
Voice: Split The Ears From The Brain
A live call, not push-to-talk. The model gets no tool that can approve anything, and that is the whole safety design.
Voice is a live, always-listening call, not push-to-talk. The architecture splits cleanly: a Python worker owns the audio, and a dashboard API route owns all the thinking. Keeping those apart is the whole trick.
Voice pipeline: one utterance
Phone browser
Mic published to a room. Wake lock held for the call.
Client
Python worker
Voice detection, then speech to text. Coalesces fragments into one turn. Speaks a filler line if the brain is slow.
Ears and mouth
/api/voice/turn
Ordered dispatch. Deterministic before model.
1. Spoken approval
Regex plus last-turn task match
2. Undo
Refused once applied
3. Queue a task
Verb-anchored, needs routing
4. Quick capture
Straight to the inbox file
5. The model
Under a hard time budget
Brain
Text to speech
Markdown stripped first, or it reads the asterisks aloud.
Live captions
Streamed to screen. Task mentions spawn on-screen cards.
Out
Decision: the model cannot approve anything.
Spoken approval is a route-level regex, not a model tool. The agent's toolset refuses to emit an approved status at all. The route recognises your own words, resolves the target from the single task named in the agent's previous reply, and refuses bulk approval outright. Then it calls the identical function the on-screen approve button calls, so speech and tap mean exactly the same thing. Undo reverses it while unapplied.
What makes it feel like a phone call rather than a demo
Utterance coalescing
Voice detection splits one thought into fragments. Each fragment waits a short merge window so the whole thought posts as one turn.
Honest latency
The worker speaks a neutral filler line after 5.5 seconds, which buys the brain a 60-second budget without dead air. Timeouts produce a spoken line, never silence.
Wake lock
A phone that sleeps mid-sentence drops the mic and reads as the agent hanging up. The screen is kept awake for the call and the lock reacquired on tab focus.
Scoped tokens
The browser only ever receives a short-lived, microphone-only room token, and rooms dispatch a named agent explicitly, so two voice agents on one server never join each other's calls.
One ordering module
The spoken task numbers and the on-screen cards read from the same list function, so task three always means the third card.
This is the short version. The full voice build, including turn detection and pre-roll, utterance merging, the latency budget, and the four failures that make a live call go quiet, is in build an AI voice assistant that answers to you.
This is an internal agent you talk to, not a customer-facing one. If the job is answering the phone instead, our sister agency covers that build and its costs in AI voice agents for business.
Operations
A Private Mesh Instead Of A Login Page
One choice that removed the auth layer, provided real HTTPS, and made the phone work from anywhere with nothing exposed. Plus where to actually run it.
The whole fleet runs on one always-on machine, every service bound to loopback, with Tailscale terminating HTTPS and publishing each app on the private mesh. That one choice did a surprising amount of work.
It replaced the auth layer
No login page, no sessions, no password reset flow was ever built. Access is device enrolment: your phone is on the mesh or it is not.
It provided real HTTPS
Valid certificates without owning a domain. Not cosmetic: browsers refuse microphone access and wake locks on insecure origins, so the voice call literally requires it.
It made one origin possible
The proxy mounts each sibling app as a path on a single hostname, which is what keeps the installed app free of browser chrome.
Zero exposed ports
Nothing listens on the public internet. The phone works from anywhere, and the attack surface stays at home.
Where to host it
The architecture has one real requirement: everything shares a disk. Source-of-truth files, SQLite, the app and the agent sessions must live together. Anything that satisfies that works.
Mini PC at home
The reference setupOwned hardware, one-off cost, data never leaves the house. You own uptime: power, restarts, a process manager that survives reboots.
VPS
Works identicallyIt is just a Linux mini in someone else's rack. Monthly cost, better uptime, no home network dependency. Your files and agent credentials now live off-site, so disk encryption and provider trust matter.
Cloud platform plus managed DB
Fights the designServerless separates compute from disk, which breaks the shared-disk assumption. SQLite becomes a managed database, file mirrors become object storage, and agent sessions need somewhere else to run anyway. Possible, but you rebuild the architecture rather than host it.
A useful middle path: keep the agents and files on a machine you own, and treat cloud only as backup.
The mesh makes location irrelevant to the phone in your pocket either way, so this is a cost and trust decision rather than a technical one.
Trust boundaries
There is no login screen. Access control is the mesh: the dashboard binds to loopback and is only reachable by enrolled devices. On top of that, every endpoint an external process can write to carries its own bearer token that fails closed. If the environment variable is missing, the endpoint refuses everything rather than allowing everything.
- →Peer agents on other machines can push proposals in, but only into the pending lane, never past it.
- →Dispatch out to a peer agent is dry-run first, lands in that agent's own vetting gates, and is never retried blind.
- →The mechanical executor holds the external credentials. The dashboard records decisions and little else.
The machine underneath all of this has its own full build in your AI operating system, on a machine that never sleeps, and the short version of why an always-on box changes things is in the always-on server piece.
Operations
Agent Teams, And The Folders That Scope Them
They have access to email, calendars, CRM and money. The file hierarchy is what keeps that power in its lane, and capability walls beat trust.
The agent teams are sibling projects on one disk. Each has its own instruction file, its own state file, its own skills and memory folder. They have access to a lot: email, calendars, CRM, chat, accounting, the wikis, the queue. The hierarchy of the file system is what keeps that power scoped.
portfolio root/ ├── STATE.yaml portfolio truth: every agent reads it, one skill writes it ├── INSTRUCTIONS.md the map: who owns what, where outputs go ├── rules/ shared rules, loaded by path when relevant ├── orchestrator/ the PM agent: portfolio view, the dashboard, dispatch ├── assistant/ email, calendar, briefs. The ONLY agent that sends ├── sales/ marketing/ content/ │ team projects, each with own instructions, │ skills, memory and wiki ├── clients/ one folder per client, one subfolder per project, │ each with its own state file. Teams are walled out. └── outputs/ plans, reports, docs: fixed folders, never the root
Read down, write in your lane
Any agent may read up the hierarchy for context: the root state file, the shared rules. Writing is scoped. A team writes inside its own folder, outputs go to fixed folders, and client folders are denied to teams that do not serve that client.
State files are the API between sessions
Every project carries a small YAML state file. A new session reads instructions, then state, and is current in seconds. No agent depends on chat history surviving.
Capability walls beat trust
Every team can draft an email. Exactly one agent holds send permission. The others physically lack the tool, which is a much stronger guarantee than a prompt asking nicely.
How handoffs work
01. Structured handoff, not shared context
When one agent passes work to another it writes a handoff block: recipient, context, goal, key points, tone, deadline. The receiving agent starts clean from that brief. Nobody parses another agent's transcript.
02. The queue is the transport
Cross-team work rides the action queue. A dispatch skill pushes a row to the target team, you approve if it is external-facing, and the team's consumer drains it inside its own scope. Delegation between teams is a row changing lanes, fully audited.
03. Session handoffs are files too
When a session ends mid-stream it writes a handoff document: what was done, what remains, the constraints that must not regress. The next session starts from that file, and checks the handoff folder before planning anything.
04. Peer agents stay at arm's length
An autonomous agent on another machine can propose work into the queue over one token-gated endpoint, and receives directed tasks through its own vetting gate. Neither side can reach into the other's files or bypass the other's approvals.
The method files those teams actually run are skills. If you have not built one yet, start with agent skills: one file that runs a whole method.
Method
How To Build It, And In What Order
How to code and how to prompt when agents write the code, the Karpathy lens that names what this is, and the six-step order that keeps every step useful on its own.
Nearly all of this system was written by Claude Code sessions, steered by one operator. That only works if the repo is built to be legible to an agent, and the prompts are built to constrain one. The working rules, in the order they matter.
How we code
Contracts live in the repo, not in chat
Each app carries a README stating its data-source contract and hard ceilings. Agents read them before touching code, and review against them.
Comments record incidents, not narration
The markdown-stripping regexes are annotated do-not-rewrite with the dated incident that created them. A future agent inherits the scar tissue, not just the code.
Spec first for anything structural
Bigger changes get a dated design spec in the repo, approved before build. The mobile shell, the routing modal and the voice screen all started as specs.
One gate for done
A single check command runs lint, typecheck, tests and build. An agent claiming completion without a green gate is lying, and the gate makes that visible.
Fail loudly, defer honestly
Executors defer what they cannot decide rather than guessing, and failures land in a visible needs-attention lane. Silence is the only unacceptable outcome.
Cron before Claude
Anything deterministic runs as plain code on a scheduler. A model session is the expensive tier, woken only where run-time judgement is needed.
How we prompt
Plan before build
Non-trivial work starts in plan mode: the agent explores, proposes, and only codes after approval. Design disagreements are cheap in a plan and expensive in a diff.
Describe the incident, not the fix
Talk works on my phone but not the laptop produced a secure-context preflight with a helpful error. Prescribing a fix would have patched the symptom.
State constraints as invariants
The model must have no tool that can approve survives a hundred sessions. Please be careful with approvals survives none.
Small verified increments
One bottleneck per session, gate green, then the next. Big-bang prompts produce big-bang debugging.
Instruction files are context engineering
Always-loaded files stay small and point to detail on demand. A bloated root instruction file taxes every single turn.
The Karpathy lens
Andrej Karpathy's Software 3.0 framing describes what this system is: a partial-autonomy app. His principles map onto it almost one to one.
Autonomy slider
The two queue lanes. Team-internal work runs on the auto lane, anything external-facing waits on the approve lane. Autonomy is set per action, not per system.
Fast generation-verification loop
The whole interface exists to make verifying agent output faster than doing the work: keyboard triage, the swipe deck, spoken approval. Seconds per decision.
Keep the agent on a leash
Fail-closed tokens, no approve tool for the model, undo blocked after real-world effects, drafts instead of sends. The leash is enforced by routes, not by prompt politeness.
Interfaces for auditing agents
The activity feed shows every routine fire, failures surface in a needs-attention lane, the drift banner calls out stale state. Trust is built by making agent work inspectable.
Build for agents as users
READMEs written to be read by agents, a CLI so terminal agents can use the queue, generated indexes so agents route cheaply. The repo treats agents as first-class operators of itself.
If you build this, build it in this order
Each step is useful on its own the day it ships, and each one makes the next easier.
Foundation
Section 02The Next.js and SQLite scaffold, the UI kit, the check gate.
The action queue and the board
Section 03The table, the decision endpoint, the CLI, then the approval board. From this day, agents can propose and you can approve.
Sync and surfaces
Sections 02, 04The one-way file sync with its drift check, then the portfolio, goals and activity pages over the projection.
Phone layer
Section 06The manifest, the mobile shell, the swipe deck. Triage moves to your pocket.
Network
Section 08Mesh VPN, one HTTPS origin, service manager. Now it is reachable anywhere and survives reboots.
Voice and the desktop shell last
Sections 06, 07Both ride on everything above, and neither blocks the others.
The wikis grow alongside from whenever you start filing meetings. The earlier the better, because compounding needs time more than it needs code.
The prompting half of this has a guide of its own in Claude plan mode, and the trigger layer that feeds the queue on a schedule is covered in Claude Code routines.
AAfleetfleetofofagentsagentswithoutwithoutaasharedsharedsurfacesurfaceisisnotnotaateam,team,ititisisaagroupgroupchatchatyouyouhavehavetotoread.read.GiveGivethemthemoneonequeuequeuetotowritewriteintointoandandoneoneplaceplaceyouyousaysayyes,yes,andandthethebottleneckbottleneckmovesmovesfromfromwhatwhattheytheycancandodototohowhowfastfastyouyoucancandecide.decide.EverythingEverythingininthisthisguideguideisisaadifferentdifferentspeedspeedofofsayingsayingyes.yes.
Jump back to a section
If the word orchestration is still doing a lot of work in your head, start here. The command centre is what it looks like once it is running.
Read next
Primary sources