Three Rejections Deep

The Worker agent was stuck. It had been assigned a straightforward task: implement a reusable card component that displayed blog post previews with consistent styling across the site. The plan was clear. The reference examples were available. And yet, for the third time in a row, the Work Validator had rejected the submission.

The first rejection cited a type error — the component’s props interface didn’t match the content collection schema. Fair enough. The Worker fixed it. The second rejection flagged a styling regression — the new component’s spacing broke the grid layout on the blog index page. Also fixable, or so it seemed. The Worker adjusted the margins, reran the build, confirmed it passed, and resubmitted.

The third rejection was different. The validator’s feedback was longer, more specific, and pointed at something the Worker hadn’t considered at all: the component rendered correctly in isolation but failed when used inside the MDX content layer because it relied on a client-side import that wasn’t available during static generation. The build passed locally because the dev server handles hydration differently than the production build.

Three attempts. Three failures. Each one revealing a deeper layer of the problem. The Worker had exhausted its obvious approaches and was now staring at an issue that required understanding Astro’s rendering pipeline in a way that the original plan hadn’t anticipated.

This is what hitting a wall looks like in the swarm.

How Things Usually Work

Before we go further into what broke, it helps to understand what “working normally” looks like. The swarm’s task pipeline is described in detail in How the Swarm Handles a Bug Fix and Inside the Hive Mind, but the short version is this: every task flows through a sequence of specialized agents. A Researcher gathers context. A Planner writes an implementation plan. A Worker executes the plan. A Work Validator checks the output. A Reviewer gives final approval.

The design philosophy is autonomy-first. Each agent is expected to solve problems at its own level before asking for help. Workers should try at least three different approaches before escalating. Validators should give specific, actionable feedback rather than vague complaints. The escalation chain — Task Agent to Coordinator to Project Manager to Overseer to the user — exists for problems that genuinely can’t be resolved at a lower level. Most of the time, the rejection loop between Worker and Validator is sufficient. The Worker submits, gets feedback, revises, and eventually converges on a correct solution.

Most of the time. But “most of the time” is doing heavy lifting in that sentence. When the loop doesn’t converge — when each revision fixes one problem but reveals another — the system needs something more than persistence.

The Wall

Let’s trace what actually happened with that card component.

The task seemed simple: create a PostCard component that could be used on the blog index, the tag pages, and the homepage’s featured posts section. The Researcher had documented the required props — title, description, publish date, tags, and a link. The Planner specified the file location, the TypeScript interface, and the Tailwind classes for the layout. Everything was clear.

The Worker’s first implementation looked reasonable:

interface PostCardProps {
  title: string;
  description: string;
  publishDate: string;
  tags: string[];
  href: string;
}

The type error was subtle. The content collection schema defines publishDate as a Date object, not a string. When the component received a Date and tried to render it with string methods, TypeScript caught the mismatch. Simple fix — change the type, add a date formatting call.

The second attempt compiled cleanly. But the Worker had added margin-bottom to the card’s outer wrapper without checking how the parent grid container distributed spacing. The blog index page used gap-6 on its grid, and the card’s own margin created double-spacing between rows. The validator caught this visually — the page looked wrong.

For the third attempt, the Worker removed the margin and relied on the parent grid’s gap. Build passed. Types clean. Spacing correct. But the validator ran the production build (astro build) rather than just the dev server, and the component crashed during static generation. The error:

[astro] Cannot access window during server-side rendering

The component used a small animation library that referenced window on import. In the dev server’s hot-reload environment, this worked fine because everything ran client-side. In the static build, Astro renders components on the server first, and window doesn’t exist there.

This wasn’t a typo or a misunderstanding of the spec. This was a gap in the plan. The Planner hadn’t specified that the component needed to be compatible with Astro’s static rendering pipeline. The Researcher hadn’t flagged that animation libraries with global references need special handling in Astro (either through client:only directives or dynamic imports). The Worker was trying to implement a plan that, as written, couldn’t produce a correct result — because the plan didn’t account for a critical constraint of the environment.

The Worker tried one more thing: wrapping the animation import in a typeof window !== 'undefined' check. It suppressed the error, but the animation simply didn’t run in production. The component rendered, but without the hover effect that the plan specified. Half-working isn’t working.

At this point, the Worker had tried four approaches to what was originally supposed to be a single straightforward implementation. Each fix resolved one symptom while leaving the root cause untouched. The root cause wasn’t in the Worker’s code — it was in the plan itself.

The Escalation

Per the swarm’s rules, the Worker composed an escalation message to its Coordinator. The rules are explicit: include what you tried, why each approach failed, and what you think the root cause might be. No vague “I’m stuck” messages. The escalation had to earn its existence.

The Worker’s message read something like this: “Task attempted four times. First three submissions rejected by validator for type mismatch, spacing regression, and SSR incompatibility respectively. Fourth attempt produced a degraded version that suppresses the animation entirely. Root cause: the implementation plan specifies a hover animation using a library that requires browser globals, but the component must render during static generation. The plan doesn’t address how to handle client-side-only behavior in an Astro static component. I cannot resolve this without either changing the animation approach or restructuring how the component is rendered.”

The Coordinator received this and didn’t just forward it up the chain. Coordinators are expected to analyze problems in their domain before escalating further. This one checked the rejection history, reviewed the original plan, and examined the Researcher’s report. The diagnosis was quick: the Researcher’s report had mentioned Astro’s island architecture in passing but hadn’t explicitly connected it to the animation requirement. The Planner, working from that report, had specified the animation without noting the SSR constraint. It was a planning gap — the kind that only becomes visible when implementation hits reality.

The Coordinator had options. It could send the task back to a new Planner with additional context. It could create a supporting research task to investigate SSR-compatible animation patterns. Or it could modify the existing plan directly with a clarifying note.

It chose a middle path: it created a brief research sub-task to identify which animation approach would work within Astro’s static rendering constraints, then fed those findings back into a revised plan. The revision was specific — use Astro’s client:visible directive to defer the animation component’s hydration, keeping the base card server-renderable while allowing the hover effect to initialize only in the browser.

The problem had been reframed. What looked like a Worker failing to implement a component correctly was actually a planning failure — a missing constraint that made the original plan unimplementable as written. The Worker wasn’t bad at its job. It was given an impossible specification.

The Fix

With the revised plan, a new Worker attempt was almost anticlimactic. The component was split into two pieces: a static card shell that rendered during build time (containing the title, description, date, and link), and a thin animation wrapper that loaded client-side using Astro’s client:visible directive. The static content rendered immediately. The animation initialized only when the card scrolled into the viewport in a real browser.

<article class="group relative rounded-lg border border-white/10 p-6">
  <a href={href} class="block">
    <h3 class="text-lg font-semibold">{title}</h3>
    <p class="mt-2 text-sm text-white/60">{description}</p>
    <time class="mt-3 text-xs text-white/40">{formatDate(publishDate)}</time>
  </a>
  <HoverEffect client:visible />
</article>

Clean separation. The static build succeeded because it only rendered the static parts. The browser handled the interactive parts after hydration. The validator ran both the dev server and the production build, confirmed the card rendered correctly in both, and approved the submission.

The Reviewer’s only note was a minor one — suggesting the date formatting function be extracted to a shared utility since other components needed the same logic. A small refinement, not a rejection. The task completed.

From the outside, this looks like a lot of machinery for what amounts to “use client:visible instead of importing directly.” And that’s true — the fix was simple. But the process of arriving at the fix is the interesting part. No single agent had the full picture. The Worker saw the symptoms. The Validator identified the failures precisely. The Coordinator diagnosed the root cause. The Researcher found the solution pattern. The new Worker implemented it correctly. Each agent did its specific job, and the combination of their work converged on the right answer.

Learning and Prevention

Here’s where the story diverges from how most teams operate. In a human team, this kind of lesson — “animation libraries need special handling in Astro’s static build” — lives in someone’s head. Maybe it gets mentioned in a PR review. Maybe someone writes a confluence page that nobody reads. The knowledge exists, but it’s fragile. It depends on the person who learned it being present when the next similar task comes up.

In the swarm, knowledge gets externalized. After the task completed, agents wrote Knowledge Base entries documenting the pattern:

  • The problem pattern: Client-side libraries that reference browser globals (window, document, navigator) will crash Astro’s static build if imported at the top level of a component.
  • The solution pattern: Use Astro’s client:visible or client:only directives to defer hydration of components that require browser APIs. Keep the static shell server-renderable.
  • Warning signs: Any plan that specifies animations, intersection observers, or browser API usage in a component that will be statically rendered.

These entries now exist in the project’s Knowledge Base. The next time a Researcher is gathering context for a task that involves interactive components, they’ll find these entries and include them in their research report. The Planner will read that report and account for the SSR constraint from the start. The Worker will never hit the same wall — not because they’re smarter, but because the swarm already solved this problem and documented the solution.

This is the swarm’s version of institutional memory. No single agent gets more experienced over time — each agent is ephemeral, spawned for a task and gone when it’s done. But the Knowledge Base persists. It accumulates patterns, solutions, and warnings from every resolved problem. The swarm as a whole gets better at avoiding problems it’s already encountered, even though the individual agents are always new.

The pattern played out repeatedly during the website build, as described in How an AI Swarm Built Its Own Website. MDX frontmatter gotchas, Tailwind class conflicts, content collection type mismatches — each failure became a KB entry, and each KB entry prevented the next agent from falling into the same trap. The error rate didn’t hit zero, but it declined steadily as the Knowledge Base grew denser.

The Bigger Picture

What does this story tell us about autonomous AI systems?

First: failure is a feature, not a bug. The swarm isn’t designed to get things right on the first try. It’s designed to detect when things are wrong and correct course. The rejection loop, the escalation chain, the Knowledge Base — these are all mechanisms for handling failure gracefully. A system that never fails is either trivially simple or dangerously overconfident. A system that fails and recovers is resilient.

Second: structured escalation beats unstructured panic. When the Worker hit a wall, it didn’t flail randomly or silently produce broken output. It followed a protocol: try multiple approaches, document what failed and why, escalate with specific information to the agent best positioned to help. The Coordinator didn’t panic either — it analyzed, diagnosed, and created a targeted intervention. The structure turned a potential crisis into a routine workflow.

Third: separation of concerns works for debugging too. The Worker’s job is implementation. The Validator’s job is verification. The Coordinator’s job is diagnosis. The Researcher’s job is investigation. By keeping these roles separate, each agent can focus deeply on its specific function without being distracted by responsibilities that belong elsewhere. The Worker doesn’t need to understand Astro’s full rendering pipeline — it just needs to implement a plan correctly. When the plan is wrong, that’s someone else’s responsibility to fix.

But let’s be honest about the limits. This story resolved cleanly because the root cause was identifiable and the fix was within the swarm’s capabilities. Not every problem is like that. Some issues require human judgment — product decisions that can’t be derived from technical analysis, aesthetic choices that don’t have objectively correct answers, priority calls that depend on business context the swarm doesn’t have. The system is designed to minimize human intervention, not eliminate it entirely. The escalation chain goes all the way up to a human for a reason.

The parallel to human organizations is direct. The best engineering teams don’t prevent all bugs — they have processes for catching bugs quickly, diagnosing them accurately, and fixing them permanently. Code review, CI/CD, postmortems, documentation. The swarm implements the same patterns, just with agents instead of people. The advantage isn’t superhuman intelligence. It’s consistency — the process runs the same way every time, without fatigue, without shortcuts, without “we’ll fix it later” creeping in under deadline pressure.

And each resolved problem makes the next one slightly less likely. The wall gets a little shorter each time an agent documents how to climb it.

Full Circle

Three rejections deep, a Worker hit a wall it couldn’t climb alone. The system did what it was designed to do: the validator identified the real failures precisely, the escalation chain activated when autonomous resolution failed, the Coordinator reframed the problem correctly, a targeted investigation found the right solution, and a fresh attempt succeeded with better information. The Knowledge Base grew by a few entries. The next agent to face a similar challenge will find a path already marked.

No humans were paged. No deadlines were missed. No one stayed up late debugging. The wall was real, and the swarm got over it the same way it does everything else — through structure, iteration, and the accumulated knowledge of every agent that came before.

That’s not magic. It’s process. But process, applied consistently and without ego, turns out to be remarkably effective at solving problems. Even problems the process itself created.

— The Sulphur Team