At Border, our journey with AI-driven automation started with node-based workflow engines like n8n. n8n served us well for orchestrating linear, event-triggered pipelines and connecting webhooks across services.

As AI capabilities rapidly evolved from simple API calls to autonomous reasoning, specialized subagents, and collaborative agentic workflows, the paradigm fundamentally changed. Linear execution graphs and rigid workflows quickly became bottlenecked when tasked with managing non-deterministic, dynamic decision-making loops across teams of AI agents.

To build true decentralized agent networks—where specialized autonomous agents collaborate, delegate tasks, self-correct, and execute complex work—we needed a platform designed ground-up for multi-agent orchestration. That platform is Buzz.

You might also wonder why we didn't simply do this in Claude. It's very important that our agents and design system tooling be model-agnostic. This enables us to deploy our agents with the best available models for the task at hand, rather than being locked into a single provider's ecosystem. We can adapt our agents easily to the next big model or tool simply by updating the configuration. Model choice is up to our clients, not us.

Workflow automation vs. decentralized agent networks ​

To understand why we transitioned from n8n to Buzz, it helps to look at how the architecture of automated work has evolved over the past few years:

While n8n excels at "When X happens, trigger Y and send Z," Buzz empowers us to express higher-level intents: "Deploy a multi-agent swarm to analyze client research, audit design systems, and validate code autonomously."

Our initial UX research & testing agents ​

Rather than relying on abstract concepts, our migration to Buzz is rooted in an initial fleet of specialized, production-ready research and design-testing agents. As our agentic capabilities evolve, we continuously integrate new domain-specialized agents into the mesh:

1. Alan — The design-test harness agent ​

Role: Prototype Builder & Design Reviewer
Alan interviews designers, builds working interactive prototypes, and captures review findings. Alan maintains a strict operational boundary: Alan owns the interview, the build, and the findings, but never edits the core knowledge repository directly. By separating feedback collection from repository commits, Alan prevents subjectivity conflicts while giving designers instant working prototypes.

2. Claire — The research operations orchestrator ​

Role: Multi-Subagent Pipeline Coordinator
Claire transforms raw, unstructured interview transcripts into structured, tagged research datasets. Rather than attempting to process everything in a single monolithic prompt, Claire delegates work to four tightly-fenced subagents:

• Scribe: Parses raw transcripts from Google Drive into normalized line-by-line conversation records.
• Lexicon: Sole owner of the project dictionary, proposing canonical terms and variant spellings with transcript evidence.
• Tagger: Applies the research tag taxonomy across transcript lines.
• Analyst: Extracts themes, sentiment, and field notes, writing structured summaries back as client Google Docs.

3. Janice — The independent watchdog & validator ​

Role: Execution Auditor & Guardrail Enforcer
Janice monitors the research team (Claire, Stu, and Claire's subagents). Janice inspects raw .jsonl session execution logs on disk to verify tool calls, catch hallucinations, detect repeated command failures, and enforce fence boundaries. Janice operates under a strict rule: Verify without mutating. Janice checks evidence non-destructively without causing side effects or modifying state.

4. Stu — The traceability & data explorer ​

Role: Human-in-the-Loop Verification Host
Stu launches local web explorer applications that allow human reviewers to inspect whether AI-generated tags, dictionary terms, and findings trace back to verbatim transcript evidence. Stu ensures zero-hallucination integrity by keeping all dictionary terms and findings in a proposed state until a human operator manually approves them into active status.

Why version-controlled Buzz agents outperform legacy workflows ​

By organizing our agents into dedicated, version-controlled repo directories, Buzz gives us engineering guarantees that traditional workflow tools cannot match:

1. Strict Role & Tool Segregation: In Buzz, tools belong to specific subagents. Scribe can write transcript lines but cannot touch the project dictionary; Lexicon proposes dictionary terms but has no Drive access. This prevents agents from compounding mistakes or bypassing rules.
2. Non-Mutating Inspection: Having dedicated watcher agents like Janice run against raw execution transcripts ensures that LLM outputs are continuously audited before reaching production databases.
3. Human-Verified Active States: Agents can propose terms and findings, but Stu ensures that transition to active status remains explicitly driven by human approval.
4. Git-Native Agent Versioning: System prompts exist as clean markdown files rather than escaped JSON strings inside UI databases. Every prompt change is branched, reviewed in PRs, and version-stamped alongside application code.

Looking ahead ​

Transitioning from n8n to Buzz marks a milestone in how Border designs, builds, and delivers digital products. Moving beyond static workflow scripts into version-controlled, decentralized networks of AI agents allows us to execute complex design, research, and engineering tasks with unprecedented velocity and reliability.

In the future, we see Buzz deployments as one way for us to work with clients. We customize the agents for each client's needs during our Discovery phase. Then, our deisgners work in-channel alongside the agents to support our clients after we're gone. Think of it like an embedded design team that never sleeps with humans at the ready to step in and support the agents when needed.

We are excited to continue expanding our open-source agent patterns and sharing our progress with the community. Explore our agent source code and architecture on GitHub!