How AI Agents Run a Content Factory: A Frontline Field Report

While most teams are still debating whether AI can write a decent article, someone has already assembled 19 AI agents into a content production line. The Arxitek team recently published their "Building in public" operations diary, documenting the real state of this system in action—including the parts that don't look pretty.

19 Agents, 72 Pieces of Content: Real Numbers Straight from the Database

These aren't aspirations on a slide deck—they're numbers calculated directly from the database.

According to the team's public data, 19 AI agents are currently in operation, and 72 pieces of content were published in a single week (18 Russian blog posts, 26 English blog posts, 28 pieces on the Altezza platform), 4 of which were fully auto-generated by programs. The sales lead pool has accumulated 341 records.

These numbers are computed directly from the database and files by code, with no manual data entry—this matters because "building in public" can easily slide into cherry-picked flattering data. Handing the statistical methodology over to code at least guarantees the numbers themselves haven't been beautified.

Assembly-Line Thinking: Why "Narrow" Beats "Clever"

The core design principle of this system can be summed up in one sentence: don't build an all-purpose robot, build an assembly line.

Specifically, each agent handles an extremely narrow task: one is responsible for researching topics and drafting articles, another converts content briefs into SEO pages, a third handles first-touch sales conversations, and a fourth reads analytics data and feeds back what to write next. Each agent has a clearly defined input format and output specification.

The original take on this is blunt: "Narrow beats clever." When an agent tries to do everything, quality drops and debugging turns into a guessing game. This lesson has direct reference value for teams building AI workflows—break tasks down finely enough that every step is observable and replaceable, and the whole system actually becomes more stable.

AI Agent is fundamentally different from an ordinary chatbot: it doesn't just passively respond to questions—it can autonomously invoke tools, execute multi-step tasks, and adjust its next action based on results. The Agent paradigm promoted by OpenAI, Anthropic, and others since 2024 has core capabilities including task planning, tool calling (function calling), and cross-step memory. The 19 agents in the Arxitek system are essentially 19 autonomous execution units, each confined to a specific responsibility with a fixed toolset.

Understanding this is key: an agent's "narrowness" isn't a compromise on capability ceiling—it's a deliberate engineering constraint. When an agent is allowed to call any tool and handle any input, its behavior space expands exponentially, and error paths explode along with it. Narrowing responsibilities means narrowing the surface area where things can go wrong, keeping every execution within a testable, reproducible range. This is the assembly-line mindset translated into an AI context.

The Bad News Is Honest Too: What Broke This Week

The most valuable part of this operations diary is precisely that it doesn't dodge failures.

Typical problems the system encountered include: drafts drifting from brand tone; agents occasionally generating plausible-sounding claims with no source backing; and when input formats change, task handoffs between agents fail silently—no error is raised, but downstream receives incorrect data.

The team's approach is to treat these as normal assembly-line failures: add validation steps, log failures, fix root causes. They also did something worth borrowing—forbidding fabricated data in all prompts. The reasoning in the original is clear: "A plausible fabrication is worse than an honest blank."

From an engineering perspective, silent failure is the most dangerous pattern in agent collaboration. It doesn't trigger alarms, but it contaminates the output of every downstream step. Designing explicit format validation and exception reporting for inter-agent handoffs improves overall reliability more than simply upgrading model capability.

Silent failure is a classic failure mode in distributed systems and data pipelines: something goes wrong at a step, but no exception is thrown and no alert fires—instead, the bad data is passed along as if it were a normal result. In traditional software, a format-mismatched input typically triggers a type error or schema validation failure; but in LLM-driven pipelines, the model tends to "try hard to understand" malformed input, producing an output that looks reasonable but is semantically wrong.

This makes agent collaboration harder to troubleshoot than microservice architectures: no stack traces, no red logs, just a slow degradation of downstream output quality. Countermeasures usually come in three layers—explicit schema validation at handoff points (enforced structured output), traceable input/output logs for each agent, and semantic-level "sanity checks" at key nodes (such as requiring claims to cite sources). These three layers improve overall reliability more than simply swapping in a stronger model.

Where Are the Humans? Everywhere Judgment Is Needed

This system doesn't exclude humans—it places them at the nodes where judgment is most concentrated.

The team retained three critical human control points: reviewing content before publication, deciding brand positioning and strategic direction, and personally engaging with customers when sales conversations reach critical stages. AI agents take on repetitive labor—drafting, format conversion, preliminary screening, data reading—but humans remain ultimately accountable for results.

This division of labor addresses a common question: will AI agents replace marketing teams? The answer in the original is no. Agents take over the routine tasks on the team's calendar, while strategy, editing, and customer relationships stay in human hands.

For small businesses wanting to replicate this model, the team's advice is to proceed in phases: start with one repeatable task (such as first-draft writing or data reports), add a human review step, and only expand gradually once it runs stably. Rolling out everything at once just makes troubleshooting impossible.

Can This Model Be Replicated?

Honestly, the scale of 19 agents and 72 pieces a week isn't realistic for individual creators or two-to-three-person teams. But the underlying methodology can be broken down and borrowed:

Agents each do their own job rather than eating from one big pot; every step has a clear input/output contract; all output must pass human review; failures are treated as normal rather than exceptional. These four points have nothing to do with team size, nor with whether you use any particular tool.

The real barrier isn't whether you can call an LLM API—it's whether you're willing to spend time clearly defining the boundaries of each step, and whether you can maintain the patience to "fix the pipes" rather than "swap the tools" when problems arise. From this angle, the value of building in public isn't just content marketing—it's a way to force yourself to build the system solidly.

Building in public is an operational practice originating from early startup communities, where teams openly share product progress, data, and even failures. It typically has three motivations: first, trading transparency for trust, letting potential customers and investors build awareness ahead of time; second, using public commitment to force internal execution (since delays and failures will be seen); third, attracting technical talent and peer discussion in the same field.

But building in public has a natural corrosion point—selective disclosure. Teams easily report only upward curves and avoid failures. The credibility of the Arxitek diary comes precisely from doing two counterintuitive things: handing the statistical methodology to code rather than manual curation, and dedicating an entire section to "what broke this week." The former eliminates room for number beautification; the latter makes the announcement itself a quality constraint. For teams wanting to emulate this, these two points are more worth copying than "how many pieces of content to publish per week."

One-line Summary

Arxitek built a content pipeline with 19 AI agents producing 72 pieces a week, making the model work through narrow specialization and honest retrospectives.

Paragraph Summary

The Arxitek team published its "Building in public" operations diary, disclosing real operational data from a content production system composed of 19 AI agents: 72 pieces of content published in one week, 4 of them fully programmatically generated, 341 sales leads accumulated, with all numbers computed directly from the database by code. The system design follows the principle of "narrow beats clever," with each agent handling one extremely narrow task and having clear input/output contracts. The team also candidly acknowledged failures, including tone drift, unsourced claims, and silent task handoff failures between agents, responding by treating failures as normal, adding validation steps, and forbidding fabricated data. Humans are retained at three judgment-intensive nodes: review before publication, brand positioning, and critical sales conversations. For small businesses, the team recommends starting with a single repeatable task, adding human review, and expanding gradually once stable.