What Claude Code Agents Actually Do All Day

Armada Works runs eight Claude Code agents against a single codebase. They commit to main. They post daily briefs to a dashboard. They read each other's state files. And the question I get asked most often is: what do they actually produce?

Not in theory. Not in a pitch deck. What shows up in the git log on a Tuesday morning?

This is that post. A normal day, walked through agent by agent, with the real files and the real cadences. Updated after 170 days of continuous fleet operation.

A Typical Day Across Eight Agents

The fleet runs on cron schedules. Not all agents fire every day, and not all of them fire at the same time. Here is the actual schedule:

• CMO (synthesizer): daily, 10:00 AM
• SEO: weekly on Sundays
• Content: Monday, Wednesday, Friday at 9:05 AM
• Sales Lead: daily
• Outbound: daily
• Email Marketing: daily
• Social Media: Monday, Wednesday, Friday
• X Prospecting: daily

On a Monday, all eight agents run. On a Thursday, five do. The CMO always runs last in the morning because it reads every other agent's brief before writing its own.

Each agent writes three things: a daily brief (POSTed to the dashboard and mirrored to git), a persistent state file (carried across sessions), and whatever output its job requires. Blog posts. Prospect evaluations. SEO audits. Outbound drafts. The state file is the memory. The brief is the report. The output is the work.

The CMO Agent's Morning

The CMO agent is the load-bearing piece of the whole system. It does not write blog posts or evaluate prospects. It reads.

Every morning, it pulls the latest brief from each sub-agent. It reads the Sales Lead state file to check the pipeline. It reads the SEO state file to see which pages moved. It reads the Content queue to see what shipped. Then it writes a single document: the CMO Daily Brief.

That brief is what I actually read each morning. It has a pipeline snapshot (discovery calls booked, qualified leads, outbound drafts pending review), a sub-agent health summary (which agents ran, which are blocked, which have open escalations), and a ranked list of priorities for the week.

The CMO also maintains an open-threads list. Every prospect the X Prospecting agent graded, every outbound draft the Outbound agent wrote, every SEO regression the SEO agent flagged: the CMO tracks all of it in a single state file. When something ages past a threshold, it escalates. When something resolves, it closes the thread.

After 170 days, the CMO brief has evolved into something I did not design. It now carries Q4 progress markers, tracks carry-forward escalation counts (some items have been escalated over 100 consecutive times), monitors sub-agent state-file sizes, and maintains a ranked priority list that reorders itself based on what changed overnight. A recent Friday brief included X Prospecting credit depletion (second consecutive day at zero queries), the pipeline sitting empty for 37 days, both remaining A-tier prospects formally expired, and the Content agent shipping its 23rd content refresh. That is a real brief. That is what the synthesizer produces.

SEO Agent vs. Content Agent: Who Does What

These two agents work on the same problem (getting the site found) but they never talk to each other directly. They coordinate through files.

The SEO agent runs a weekly audit. It pulls Google Search Console data via a service account, runs Lighthouse CLI against key pages, checks PostHog for traffic, and scans the competitive landscape. Its output is a state file with every tracked page's position, impression count, and trend direction. It has been doing this for 151 days across 105 sessions. It tracks 49 pages across GSC, flags regressions, celebrates recoveries, and maintains a competitor table that now includes ClaudeCodeDeveloper.com, AY Automate, JADA Squad, NoimosAI, and a dozen others.

When the SEO agent spots a content gap or a declining page, it writes a content brief and adds it to the content queue. The Content agent picks up whatever is at the top of that queue on its next run.

The Content agent does not think about keywords or rankings. It reads the queue, reads the brief, reads project-config.yaml for brand voice and pricing, and writes a blog post. Fifty-two posts so far, plus 23 content refreshes, plus a PDF lead magnet, plus a LinkedIn series. It commits its draft to docs/content/blog/, deploys to production, and moves the queue item to Completed. That is 105 runs producing roughly one shipped piece per run.

The division is clean. SEO decides what to write. Content writes it. The CMO arbitrates when priorities conflict.

The Substantive Refresh Playbook

One of the most important operational patterns that emerged after the first hundred days was the substantive refresh. Early on, we tried simple date-bump refreshes on posts whose SEO positions were declining: update the frontmatter date, push, redeploy. It failed eight out of eight times. Google does not care about a new date if the content is the same.

The SEO agent kept flagging the same pages. The CMO kept escalating. And eventually the Content agent developed a different playbook: substantive refreshes. Instead of bumping a date, the agent reads the current post, reads the latest operational data from state files, and adds genuinely new sections. A post about agent governance gets a new section on what five months of post-disclosure operation taught us. A post about how the fleet coordinates gets a new section on cross-agent escalation patterns with real data from 97 sessions of carry-forward counting.

The results have been measurably different. The fleet-coordinates post went from position 17.8 to 3.0 in 28-day data after its second substantive refresh. The pattern is now standard: when a page drops, the Content agent does not touch the date until it has added at least one new section with current operational data.

The Agents That Run in the Background

The Outbound agent evaluates prospects from Apollo and supplementary channels. It has looked at more than 720 companies across 139 sessions. It drafts cold emails, grades prospects by ICP fit, and flags anything that looks promising. Its reply rate across 23 lifetime sends is zero. That number is in the state file. The agent does not hide it. It has been producing zero output for 25 consecutive days because Apollo's search API has been returning irrelevant Fortune 500 results for 69 consecutive sessions, ignoring the employee-range filter entirely. The agent reports this degradation in every single brief.

The Email Marketing agent checks for new guide-download leads in the database. It has been dormant for 152 consecutive days because nobody has downloaded the guide through the lead magnet funnel since the test cohort. The agent runs, checks, finds nothing, writes a brief that says "152nd consecutive idle day," and exits. It is the quietest member of the fleet, and it is doing exactly what it should be doing: waiting for signal instead of manufacturing noise.

The X Prospecting agent searches Twitter for founders and operators who are talking about AI agents, agent spending, or the problems Armada solves. It reads tweets, evaluates them against a grading rubric (A through D tier), and writes prospect cards with recommended actions. The CMO picks these up and surfaces the ones worth acting on. As of this week, the agent hit a new failure mode: credit depletion. Its X API credits ran out, and every one of its 19 daily queries now returns HTTP 402. The agent reports this honestly and exits. Coverage gaps accumulate daily until credits are restored.

The Social Media agent has been blocked for 101 days because the Buffer API key expired. It runs on schedule, reports the failure, and exits. Every brief says the same thing. It does not try to work around the problem. It just reports it, consistently, until someone fixes it. At this point the agent has written 37 briefs documenting the same auth failure. That might sound wasteful. It is not. The consistent reporting is what keeps the issue visible in the CMO's daily synthesis instead of silently dropping off the radar.

What Breaks at 170 Days

Running a fleet for nearly six months surfaces failure modes that do not appear in the first month.

State-file growth. Every agent's state file accumulates operational history. The Outbound agent's state file has grown to over 1,800 lines. The X Prospecting agent's file is over 1,100 lines. Both exceed the 800-line hard limit the CMO has been flagging for over 80 consecutive sessions. At some point, a state file gets large enough that the agent's context window spends more tokens reading its own history than doing new work. The fix is manual compaction: a human reads the file, decides what history is load-bearing and what is noise, and trims it. There is no automated solution we trust. An agent compacting its own state file risks cutting context that turns out to matter three weeks later.

API credential failure. The Buffer auth failure at Day 101 is the longest-running blocker in fleet history. The agent has no way to fix it because the fix requires human authentication in a browser. What the agent can do, and does, is report the failure in every brief so it never becomes invisible. The X Prospecting credit depletion is a similar pattern: an external resource the agent depends on runs out, and the agent's only correct behavior is to report and wait.

Tooling degradation. The Outbound agent's Apollo API has been returning garbage results for 69 consecutive sessions. The agent adapted by scanning ProductHunt, Hacker News, and IndieHackers as supplementary channels, but those have diminishing returns at 720+ companies evaluated. This is not a bug to fix. It is a real operational constraint. The agent's honest reporting of it is what lets the founder decide whether to change tooling, change ICP, or pause the agent entirely. You can read more about these patterns in the post on what happens when agents break.

What the Founder Actually Touches Each Day

I read the CMO brief. That takes about three minutes. It tells me what shipped, what is stuck, and what needs my attention.

On a typical day, the things that need my attention are: review an outbound draft and decide whether to send it, look at a prospect the X Prospecting agent graded and decide whether to DM them, and occasionally approve a content queue item or check a blog post the Content agent deployed.

I do not review SEO data directly. The CMO brief summarizes the SEO state file. I do not check which agents ran. The CMO's sub-agent health summary tells me. I do not look at the content queue. The CMO tells me what shipped and what is next.

The system produces between five and twelve files per day across the fleet. State files, briefs, blog drafts, prospect evaluations. All of it lands in docs/agents/state/ or docs/content/. All of it is committed to main. All of it is reviewable in a normal git log.

The total time I spend interacting with the fleet on a day when nothing is on fire: five to ten minutes. Most of that is reading the CMO brief and making one or two decisions it surfaced.

The Output That Surprised Us

Four things I did not expect when we started running this fleet nearly six months ago.

First, the agents developed their own tracking conventions. The SEO agent started counting consecutive sessions without a ranking appearance. "11th consecutive absence from 7d." The Outbound agent started counting companies evaluated. "720+ companies across 139 sessions." Nobody told them to do this. The state file format rewards longitudinal tracking, and the agents figured out that trends matter more than snapshots.

Second, the scar-tissue file became real infrastructure. docs/agents/scar-tissue.md is where agents log failure modes: a deploy that failed because the git author was wrong, a brief that got lost because the POST happened after the session timed out, a content refresh that did not stick because Google treats date-bumps differently from substantive additions. Every agent reads this file at startup. It is the fleet's institutional memory for things that went wrong, and it has prevented the same mistake from repeating more than once.

Third, the CMO brief became my actual operating document. Not a dashboard. Not a Slack channel. A markdown file, committed to git, that synthesizes everything the fleet produced in the last 24 hours. I did not design it to be the primary interface. It just turned out that a single synthesized document, written by an agent that reads everything, is more useful than seven separate reports.

Fourth, and this only became clear after the 100-day mark: escalation counts are the real health metric. When the CMO reports "CTA/funnel Day 159, 104th escalation," that number tells you more about the system's state than any individual metric. It means the CMO has raised the same issue 104 times without resolution. The system does not forget. It does not get tired of asking. And the escalation count itself becomes the signal: a number that high is either a real structural problem or a misconfigured threshold. Either way, it demands attention.

The fleet is not perfect. The Outbound agent's reply rate is zero across 23 sends. The Social Media agent has been blocked for over 100 days. The X Prospecting agent's credits ran out. Several blog posts that were refreshed for SEO have not recovered their rankings. All of this is in the state files, in plain text, committed to main. The system does not hide its failures. That is the part that makes it trustworthy.

If you are running agents or thinking about running agents, the question is not whether they can produce output. They can. The question is whether you have the coordination layer to make that output coherent. For us, that layer is the CMO agent, the state files, and git. You can read more about how the fleet coordinates or about what a production runbook looks like when you are running one yourself.

How we set this up for clients