How it works
// 01 DPI and pixel density
The graph is an SVG with agent nodes positioned on a circle around a central orchestrator node. Positions are calculated from the agent list at render time, so adding a new agent re-balances the ring without manual placement. Edges are simple straight lines with stroke properties animated via SMIL or requestAnimationFrame when a task fires.
// 02 Bleed and cut tolerance
When you trigger a task, an animation sequence plays. First, the orchestrator pulses (a radial glow driven by an SVG filter). Then, one or more edges animate outward by sliding a gradient along their stroke-dasharray. Each target agent pulses in response. After a simulated work interval (200 to 1200 ms per agent, randomized to feel natural), the edges animate back inward and the orchestrator pulses one more time to indicate the merged result.
// 03 Safe zone and trim accuracy
The agent registry is a typed TypeScript array stored alongside the component. Each entry carries name, description, color, and a short tool list. Adding an agent is a one-line change. The firing pattern for a given task type is also data-driven: a task archetype (copy write, devops fix, CRO review) declares which agents it activates, which lets the widget showcase different orchestration patterns instead of the same fan-out every time.
// why this exists
the Berserk Stack thesis, visualized
The Berserk Stack is the set of specialized Claude agents I use to ship work at velocities that used to require a team. Each agent has a narrow brief (copywriting, CRO, SEO, devops, security review, case study analysis) and its own prompt, tool set, and file ownership boundary. A single request from me fans out to multiple agents running in parallel, their outputs merge through an orchestrator, and the result lands in the repo as a PR. This widget is a live visualization of that graph.
What you see is an SVG graph with a central orchestrator node and a ring of named agent nodes around it. When a task fires, the request pulses from the orchestrator outward to the relevant agents, each agent pulses through its work, and responses flow back to the orchestrator where the output is merged. Hover any node to see what that agent does. Click the 'fire a task' button to trigger a simulated run and watch the graph light up.
The visualization is not a toy. It runs off the same agent registry that powers my actual build workflow, so the names, descriptions, and tool sets you see are the real ones. When I add a new agent to the stack, this widget updates automatically. When I rebalance an agent's file ownership (so it cannot step on another agent's claim), the edge weights in the graph shift accordingly.
Why show this publicly? Because the claim that one person can move at team velocity sounds like marketing until you see the mechanism. The Berserk Stack is the mechanism. It is not magic. It is a small number of parallel processes with clear boundaries, coordinated by a single human who understands what each agent is good at and where they fail. The graph is the easiest way to explain that structure without walking through every prompt file.
The widget is purely visual. It does not call the live agents (that would leak my prompt library and cost money per render). The firing animation is pre-recorded from a real task run, but the graph topology is live.
Frequently asked questions
What is an agent in this context?
A specialized Claude instance with its own system prompt, its own tool permissions, and a narrow responsibility. Agents are how I split a complex task into parallel work streams without losing coherence.
Is this actually running live agents?
The visualization is replayed from real task runs. It does not call live agents per render because that would leak proprietary prompts and burn API credit for every page load.
How many agents are in your stack?
Currently fifteen specialized agents plus a coordinating orchestrator. The number grows as I add capabilities. The graph updates automatically when the registry changes.
Can multiple agents work on the same file?
No. Each agent has a file ownership boundary declared in the project's AGENTS.md. If a task needs two regions, the orchestrator sequences them to avoid merge conflicts.
What tool does this use to coordinate agents?
Claude Code's agent system, with git worktrees for physical isolation and a shared notes directory for coordination messages. The orchestrator is another Claude instance with the agent registry in its context.
How is this different from a typical LLM pipeline?
A typical pipeline is sequential: step 1, step 2, step 3. This is parallel. Multiple agents work simultaneously on different regions of the same repo, and their outputs merge back through the orchestrator instead of chaining through each other.
Why show the agent stack publicly?
Transparency. The claim that one person can ship at team velocity sounds like marketing unless you can see the mechanism. This widget is the mechanism in one glance.
Can you build a version of this for my company?
Yes, though the agent design is the bulk of the work, not the visualization. The stack has to be tuned to your codebase, your security posture, and your team's workflow for it to pay off.
What happens when two agents produce conflicting output?
The orchestrator runs a reconciliation pass. If the conflict cannot be resolved automatically (for example, two different copy directions for the same headline), the task surfaces a human review request instead of shipping the wrong version.