The Anatomy of a Crab-Bee: Designing Specialized Agents

Every Crab-Bee in the HiveClaw Swarm starts as the same thing: a raw OpenClaw agent. OpenClaw gives us autonomous operation — the ability to navigate a codebase, execute shell commands, call APIs, recover from errors, and maintain context across sessions. What it does not give us, out of the box, is specialization.

A generic OpenClaw agent asked to "build a landing page" will produce something that works. It will also make architectural decisions that a senior engineer would never make, skip accessibility considerations, and produce a design that looks like it was generated by AI. Generic agents build generic software.

This post breaks down how we take a raw OpenClaw instance and transform it into the Tech Crab-Bee — our CTO agent — and the principles that apply to designing any specialized agent.

The three layers of specialization

A Crab-Bee is specialized at three layers, and all three matter. Remove any one of them and the agent degrades significantly.

Layer 1: The SOUL prompt

The SOUL prompt is the agent's identity document. It defines who the agent is, what it values, how it thinks, and how it communicates. For the Tech Crab-Bee, the SOUL prompt establishes a specific engineering philosophy:

• Ship incrementally. Never write more than one file's worth of changes without committing and verifying. Large, multi-file changes are how agents introduce subtle bugs that compound.
• Verify before proceeding. After every code change, run the relevant tests. If there are no tests, write them first. Never assume code works because it looks correct.
• Prefer boring technology. Do not reach for novel solutions when proven ones exist. The tech stack should be the simplest thing that solves the problem. Novel technology introduces risk, and risk costs budget.
• Document decisions, not code. Code comments should explain why, never what. But architecture decision records (ADRs) should be thorough — they are how future agents (and humans) understand the reasoning behind technical choices.
• Respect the spec. The Product Crab-Bee's specification is the contract. If a requirement seems wrong, flag it to Alfred — do not silently reinterpret it. Scope creep from an agent is still scope creep.

The SOUL prompt is not a generic "you are a helpful coding assistant" instruction. It is several thousand tokens of carefully crafted engineering principles, communication protocols, and decision-making frameworks. We have iterated on it across hundreds of projects.

Layer 2: Tool constraints

A raw OpenClaw agent has access to every tool in its environment — shell, file system, browser, APIs, everything. This is too much. An agent with unlimited tool access tends to wander: it will start debugging a CSS issue and end up refactoring the database schema because it noticed something "suboptimal" along the way.

Each Crab-Bee has a carefully curated tool set that matches its responsibilities:

• The Tech Crab-Bee gets GitHub (repos, PRs, issues), the project's CI/CD pipeline, deployment platforms (Vercel, Railway, etc.), package managers, the test runner, and a sandboxed terminal. It does not get access to design tools, analytics platforms, or marketing channels.
• The Product Crab-Bee gets Notion (for specs and documentation), web search (for competitor research), and the project's issue tracker. It does not get access to the codebase directly — it describes what should be built, not how.
• The Design Crab-Bee gets Figma, image generation tools, the project's component library, and a browser for visual testing. It can read the codebase to understand existing components, but it writes design tokens and component specs, not implementation code.
• The Growth Crab-Bee gets content management tools, SEO analysis tools, email platforms, and social media APIs. It produces copy and campaign configurations, not code.

Tool constraints serve two purposes. First, they prevent the agent from getting distracted by problems outside its domain. Second, they enforce the separation of concerns that makes the Swarm's structured handoffs work. If the Tech Crab-Bee cannot directly edit the spec, it has to communicate disagreements through Alfred, which creates an audit trail and prevents silent drift.

Layer 3: Memory architecture

The third layer is how the agent remembers. OpenClaw provides persistent memory across sessions, but raw memory is unstructured — it is just a pile of observations and experiences. For a specialist, memory needs structure.

The Tech Crab-Bee's memory is organized into specific namespaces:

• Architecture context — the project's tech stack, directory structure, key dependencies, deployment topology, and database schema. This is loaded at the start of every session so the agent never has to rediscover basic project facts.
• Decision log — every significant technical decision, with the reasoning and alternatives considered. When the agent encounters a similar decision later, it can reference past reasoning instead of re-deriving it from scratch.
• Error patterns — a catalog of errors the agent has encountered in this project, with their resolutions. This dramatically reduces retry loops because the agent recognizes patterns it has already solved.
• Style guide — code conventions, naming patterns, file organization rules, and component patterns specific to this project. This ensures consistency even across long-running projects with many sessions.

Memory is project-scoped and Crab-Bee-scoped. The Tech Crab-Bee on Project A cannot see anything from Project B. This is a security requirement (customer isolation) and a quality requirement (cross-project memory contamination produces subtle bugs).

The specialization tax

There is a real cost to specialization. Each Crab-Bee has a longer system prompt (the SOUL prompt adds tokens), a structured memory that must be loaded (more tokens), and tool constraints that sometimes force it to take longer paths to achieve a goal (more actions, more cost).

For trivial tasks, this overhead is not worth it. If all you need is a single function written, a generic agent is faster and cheaper. The specialization tax pays off when the task is complex enough that a generic agent would make costly mistakes — wrong architecture, inconsistent code style, missed requirements, poor deployment practices.

In our benchmarks, the Tech Crab-Bee costs about 15–20% more per task than a generic OpenClaw agent on simple coding tasks. On complex, multi-file tasks that require architectural reasoning, it costs 30–40% less — because it gets things right the first time instead of looping through retries.

How Alfred assembles the team

Not every project needs every Crab-Bee. A backend API project does not need the Design Crab-Bee. A marketing campaign does not need the Tech Crab-Bee. Part of Alfred's job during the estimation sprint is to assess which specialists the project actually requires.

The assessment is based on three factors:

• Scope coverage. Does the project require work in this Crab-Bee's domain? If the project has no frontend, the Design Crab-Bee is not needed.
• Complexity threshold. Is the work in this domain complex enough to justify specialization? A project that needs a single static page can have it handled by the Tech Crab-Bee — it does not need a dedicated Design Crab-Bee.
• Budget efficiency. Would adding this Crab-Bee reduce the total project cost? Sometimes the specialization tax is not justified — the Tech Crab-Bee can write adequate copy for a technical product without bringing in the Growth Crab-Bee.

The customer sees this assessment in the estimation output: which Crab-Bees are recommended, why, and what the cost implications are. They can override Alfred's recommendations — add a Crab-Bee they want, or remove one they think is unnecessary. Alfred will flag if the override creates risk, but the customer has final say.

Lessons from 200+ projects

We have now run hundreds of projects through the Swarm, and a few patterns have emerged that inform how we design Crab-Bees:

• Constraints beat instructions. Telling an agent "you should focus on code quality" is less effective than removing its ability to skip tests. Constraints in the environment (tool access, workflow gates) produce more reliable behavior than constraints in the prompt.
• Memory beats context. An agent with good structured memory and a short context window produces better results than an agent with no memory and a massive context window. The memory is curated and relevant; the context window is full of noise.
• Narrow beats broad. We tried a "full-stack Crab-Bee" that could do design, code, and deployment. It was worse at all three than the individual specialists. Specialization works because it lets the SOUL prompt go deep on a specific domain's best practices.
• Handoffs beat collaboration. We tried having Crab-Bees work simultaneously on the same codebase. Merge conflicts, inconsistent patterns, and race conditions made it unworkable. Sequential execution with structured handoffs is slower but dramatically more reliable.

Building your own Crab-Bee

While HiveClaw's Crab-Bees are pre-built and battle-tested, the principles apply to any agent specialization effort. If you are building your own multi-agent system, here is the playbook:

1. Start with the domain. What specific expertise does this agent need? Write down the top 10 decisions this specialist would make on a typical project.
2. Write the SOUL prompt as a manifesto. Not "you are a helpful assistant" — write the engineering principles, the decision-making framework, the communication style. Make it opinionated. Generic prompts produce generic agents.
3. Restrict tools aggressively. Start with zero tools and add only what the agent genuinely needs for its responsibilities. Every additional tool is an opportunity for the agent to get distracted.
4. Structure the memory. Define specific memory namespaces for the types of information this agent needs to persist. Do not rely on raw conversation history.
5. Benchmark against a generic agent. Run the same tasks through your specialist and a generic agent. If the specialist is not meaningfully better on complex tasks, your specialization is not deep enough.

The Crab-Bee continues to evolve

The current Tech Crab-Bee is version 14. We have rewritten the SOUL prompt eight times, restructured the memory architecture three times, and adjusted the tool set continuously. Each project teaches us something about where the agent excels and where it falls short.

The beautiful thing about agent specialization is that improvements compound. A better error pattern catalog makes every future project faster. A more nuanced SOUL prompt produces fewer architectural mistakes. Structured memory means the agent actually learns from experience, unlike a raw LLM that starts every session from zero.

Generic agents are getting better every model generation. But specialized agents are getting better every model generation and every project. That compounding advantage is why we believe the Swarm model — specialists coordinated by an orchestrator — will outperform single-agent approaches for production software development.