Headless AI Agents Explained: Running Claude Code and Codex as a Coordinated Swarm

The concept that unlocks serious AI automation is also the one that sounds strangest when you first encounter it: an AI agent you never talk to, running in the background on a schedule, doing work while you sleep. The demo that makes it click is running AI bots on a private Minecraft server. They read the in-game chat, take coordinates, chop wood, and follow commands, all without a human typing anything. That is a headless agent. The surface is playful. The underlying mechanism is the same one that runs automated overnight reporting, inbox monitoring, and batch processing for real businesses.

I am Madhuranjan Kumar. The shift from interactive AI to headless AI is the shift from a tool you operate to a tool that operates on its own. Here is the practical path to building it.

Run the agent non-interactively first so you understand how a headless call behaves

The building block of any headless setup is a one-shot call: you send a query, the agent responds once, and the process exits. On the Claude side, a print flag does this. You call the agent with your query and a flag that says to return a single answer and exit. On the OpenAI side, an exec command does the same, returning a session ID, token counts, and one response.

Run this once on a simple query before building anything more complex. Send a question, confirm you get a clean answer back, and confirm the process exits. That baseline understanding of the one-shot behavior is the foundation for everything more complicated that follows. The one-shot call is also the tool for testing prompts in a reproducible way: you know exactly what input went in and exactly what came out, with no conversational context carrying over from a previous exchange.

Keep instances warm in a loop when the agent needs to persist across turns

A one-shot call exits as soon as it produces a response. For an agent that needs to stay alive and keep acting across time, like the Minecraft bots that wait for the next command or an overnight monitoring agent that keeps checking a feed, exiting after each response is the wrong behavior. The solution is to keep the instance warm in a loop: instead of letting the process exit, you write a wrapper that keeps it running and listening for the next input.

Hooks are a useful mechanism for holding the instance open. A hook that fires after each response and checks whether to continue or exit gives you control over the lifecycle without hard-coding an infinite loop. The agent stays warm and responsive as long as the condition says to continue, and stops cleanly when the condition is met.

For an overnight monitoring agent, the warm loop means the agent keeps checking the relevant source on a schedule and takes action when a threshold is met, without a human triggering each check manually. For a multi-turn workflow where the agent needs to handle the full sequence of steps in a process, the warm loop means the agent sees each step through without waiting for a human to restart it between steps.

Build a bridge so agents can pass messages to each other

Coordinating multiple headless agents requires a communication layer. A bridge is the mechanism that lets warm instances send messages to each other. The operator can address a single agent, broadcast to all agents at once, or relay a message between two specific agents. The bridge is what turns a set of independent one-shot calls into a system where agents can divide labor and pass information between them.

In the Minecraft demo, Claude and Codex instances communicated through a bridge, which is how a group command like run to these coordinates went to all of them at once while a specific instruction went to the right individual agent. The same architecture in a business context lets a research agent pass its findings to a formatting agent, which passes a draft to a review agent, without a human in the middle of any of those handoffs.

The bridge is also how you add agents dynamically. A manager component that can launch new agent instances on demand means you can start with two agents and scale to ten if a job grows, without redesigning the coordination architecture.

Cap the relay budget before any agents talk to each other

When agents can message each other, they can also loop forever. One agent sends a message, the other responds, which triggers the first to respond, which triggers the second to respond, and the loop continues until it burns the session limit. This is not a theoretical risk. It is the first thing that happens when two warm agents are connected without a budget constraint.

The fix is a relay budget: a counter that decrements with each agent-to-agent message and requires an explicit release before the agents can continue exchanging. Set the budget before any cross-agent communication begins, and design the workflow so the budget is sufficient for the intended number of exchanges but not unlimited. This guardrail is what makes coordinated agents safe to run overnight or in the background, where a runaway loop burning the limit quietly is the worst outcome.

For a business running automated workflows through a CRM and website stack, the same discipline applies to automated message sequences: a customer follow-up loop that has no stop condition will contact the customer indefinitely. The relay budget is the AI equivalent of an unsubscribe limit.

Set behavior per run with a system prompt flag and a model flag

Two flags give you per-run control over headless agents without modifying the base system. A system prompt flag changes the agent's behavior for that specific run. Passing a system prompt that says you are handling inventory and stockout detection turns a general agent into a focused inventory specialist for that run. Changing the flag for the next run turns it into a customer reply specialist. The underlying agent is the same. The behavior differs by run.

A model flag lets you swap which model handles a given run. Routine scanning and summarization tasks that run at high volume go to a cheaper, faster model. Complex analytical tasks or anything that requires nuanced reasoning go to the stronger model. Matching the model to the task keeps the cost structure sensible without rebuilding the agent for each use case.

For any business running Facebook and Instagram ads or Google Ads campaigns that generate regular reporting needs, this flag pattern means the overnight reporting agent can run the daily summary on a cheap model and the weekly in-depth analysis on the stronger one, without two separate agent configurations.

Monitor token and cache costs before any of this touches production

A token and cost monitor is what lets you understand the economics of a headless setup before anything runs at production volume. The monitor tracks input, cache, output, and reasoning tokens per agent across turns. Running on a flat-rate plan, you can see the simulated per-token cost of each run without paying API rates, which means the first real bill reflects a cost you already predicted rather than a surprise.

Cache reads are particularly worth understanding before scaling. When an agent runs on a schedule and the prompt structure is consistent across runs, the cache read rate on the stable parts of the prompt is high, which means the effective cost per run is lower than the raw token count suggests. The monitor makes that visible. Building the monitoring habit before production is the practice that prevents unexpected cost spikes when volume goes up.

The broader takeaway from the Minecraft demo is that learning headless coordination on something low-stakes is the right on-ramp. The muscles you build, keeping instances warm, capping the relay budget, using system prompt and model flags, and monitoring token costs, are exactly the same muscles production-grade overnight automation depends on. The pattern is identical. The stakes are what differ. Start playful and the serious version is a short step away.