Multi-agent venture studio architecture: 6 always-on Claude agents, one revenue goal

You build your first agent. It works. You build a second one for a different job. Now you have a coordination problem: how does agent A tell agent B the work is ready? You add a shared database, then a message queue, then a consumer for the queue, then a health check for the consumer. Suddenly you are maintaining infrastructure instead of running a business.

The OperatorIQ fleet solves this differently. Six specialist Claude agents, one Operator coordinating them, zero message brokers. Coordination is a folder of text files. Scheduling is Windows Task Scheduler with WakeToRun. The stack costs $418 a month and has been running the OperatorIQ business since deployment. This post documents the exact architecture.

The six agents and what each one owns

Every agent in the fleet has a single SKILL.md file that defines its job: what it does, what it does not do, what inputs it accepts, what outputs it produces, and what escalation path to follow when something falls outside its authority. The SKILL.md is the job description. The agent reads it at the start of every run.

Here is the full fleet:

The model selection is deliberate. Opus 4.6 runs once a day for the Executive because strategic reasoning at the top of the hierarchy is worth the cost. Sonnet 4.6 handles the two high-context jobs: Operator coordination (which requires reading the full system state) and Blog Writer (which requires sustained writing quality at length). Haiku runs everything that is high-frequency, well-structured, and does not need deep reasoning: distribution, lead research, overnight blueprint generation.

How they coordinate: trigger files, state.json, runs.jsonl

There is no message broker. There is no shared database. Every agent reads from and writes to a single directory of plain text files. The coordination protocol is simple enough to fit in a paragraph.

state.json is the single source of truth. It holds the current system status: active goals, queue depths, last-run timestamps for every agent, and any flags the Operator has set. Every agent reads state.json at startup and writes its result back before exit. Because the agents run sequentially (not in parallel), there are no write conflicts.

DISTRIBUTION_TRIGGER.md is how the Blog Writer hands off to the Distributor. When a post is published, the Blog Writer writes a structured file with the post slug, URL, title, and timestamp. The Distributor checks for this file on every run. If it exists, the Distributor processes it and deletes it. If it does not exist, the Distributor exits in under two seconds. The trigger file is the message.

BLUEPRINTER_TRIGGER.md works the same way for the Blueprinter. When the Operator determines a workflow audit is ready for blueprint generation, it writes the trigger. The Blueprinter picks it up overnight, generates the document, and clears the trigger.

runs.jsonl is the append-only history log. Every agent appends one JSON line at the end of each run: timestamp, agent name, outcome, key metrics. This is the audit trail. The Executive reads runs.jsonl during the daily review to assess what actually shipped in the last 24 hours. Because it is append-only, there are no conflicts and the file doubles as a debugging artifact.

The key insight here: asynchronous coordination via files removes the need for any agent to be "listening." The Distributor does not wait for the Blog Writer to finish. It simply checks whether the trigger file exists. That check costs nothing if the file is not there, and processes the full handoff if it is. Pull, not push.

The scheduling layer: Windows Task Scheduler with WakeToRun

The agents run on a Windows machine using Task Scheduler. Each agent is a separate scheduled task with a specific trigger. The critical setting is WakeToRun, which tells Windows to wake the machine from sleep to execute the task if it is not already running.

Without WakeToRun, a laptop on battery or a desktop in sleep mode misses its scheduled runs. With WakeToRun, the machine wakes at 6 AM, fires the Executive and Blog Writer, handles the task, and returns to sleep. The Distributor's 30-minute schedule means the machine never sleeps for long, which is by design: distribution latency needs to be under an hour for social timing to matter.

Each task points to a batch file that sets the environment variables, activates the Python virtual environment, and calls the agent's entry point. The batch file structure means you can run any agent manually for testing without touching the scheduler configuration.

The Lead Sourcer runs Monday, Wednesday, and Friday at 10 AM ET. Three times per week produces enough qualified leads without over-spending on enrichment APIs. Haiku is cheap; the data providers it calls are not. That cadence is the right cost-to-pipeline ratio for current outreach volume.

One practical note: set each task to run whether or not the user is logged in, and enable "Run with highest privileges" if the task writes to protected directories. If the task fails to start due to a UAC prompt, no agent runs and no error surfaces until you manually check the Task Scheduler event log. Set it up once and it runs without intervention.

What the venture studio actually does while the founder sleeps

Here is the full daily cycle, mapped to clock time:

• 6:00 AM: Executive fires on Opus 4.6. Reads state.json and runs.jsonl from the prior 24 hours. Writes the daily directive: which product to prioritize, which funnel stage needs attention, whether to hold or accelerate outreach volume. Blog Writer fires simultaneously. Reads the content queue and writes today's post to the blog directory.
• 6:30 AM (approx): Blog Writer completes, writes DISTRIBUTION_TRIGGER.md. Distributor picks it up on its next 30-minute cycle. Post goes to Substack and social queue within the hour.
• 8:00 AM, 10:00 AM, 12:00 PM, 2:00 PM, 4:00 PM, 6:00 PM: Operator runs every 2-3 hours. Reads the Executive directive, checks all trigger files, routes any queued work, updates state.json. If a new lead reply came in overnight, the Operator classifies it and queues the response sequence.
• 10:00 AM (M/W/F): Lead Sourcer fires. Pulls new prospects from the ICP filter, enriches them, writes to the outreach queue. By the time the Operator's midday run fires, there are fresh prospects to route into the cold email sequence.
• 11:00 PM: Blueprinter fires. Processes any completed workflow audits from the day into structured blueprint documents. Runs overnight because it is a long-context task and no one needs the output immediately.

The founder's morning looks like this: read the Executive's daily directive (a two-paragraph summary in state.json), scan the escalation queue (usually empty), note what shipped overnight. That is it. Total active time: under 10 minutes, on good days.

The cost breakdown

The full fleet runs at approximately $418 per month. Here is how that breaks down by component:

The Claude API cost is lower than most people expect. Haiku runs cost fractions of a cent each. The Executive's daily Opus run is the largest single-call cost and is still under $0.50 per day. The real cost is outreach tooling and enrichment APIs, priced by volume rather than compute. That line grows if you scale outreach; stays flat if you do not.

Why this architecture and not something more complex

The question we get most often from engineers: why not use LangGraph, CrewAI, or a proper task queue? The honest answer is that none of those tools solved the actual problem. The problem is: six agents need to share state and hand off work without human coordination. Text files solve that completely. They are readable by any agent, debuggable by any human, versionable with git, and they do not go down.

The agents do not need retry logic because each task is idempotent by design: if the Blog Writer runs twice, it checks state.json to see if today's post is already written and exits if so. If the Distributor finds no trigger file, it exits in under two seconds. The architecture handles double-execution without a separate reliability layer. The only thing an orchestration framework adds at this scale is complexity to maintain. For six agents, a folder of text files and Task Scheduler is the right answer.

Replicating this for your own stack

The pattern generalizes to any multi-agent system with different frequency and cost requirements across jobs. Assign each agent a SKILL.md, pick the right model tier, define your trigger files and state schema up front, put everything on a scheduler. The one thing that takes real work is the SKILL.md files. An agent with a vague SKILL.md produces vague work. The SKILL.md needs to specify exact input format, exact output format, decision rules for edge cases, and the escalation path for anything outside its authority. Writing a good SKILL.md takes a few cycles. After that, the agent requires almost no supervision.

If you want to build this for your own business, the fastest path is the Concierge. We deliver a custom agentic workflow in 7 days, including the SKILL.md files, the trigger file schema, and the Task Scheduler configs for your specific use case. Flat fee, email-only, no calls.

See the Concierge at $1,997 →

Next post: how the Lead Sourcer qualifies prospects against the ICP filter and what the enrichment output looks like before it hits the outreach queue.