Adding Grok Build to the Toolkit

Saturday morning, coffee, and a new tool to evaluate. This is how the good weekends start.

I've been integrating xAI's Grok Build into the development workflow for the past few weeks. It's the fourth AI coding agent in the toolkit, which means the obvious question: didn't I already have enough? The less obvious answer: no, because Grok Build does something the others don't.

What Grok Build Brings

The existing toolkit covers the spectrum well. Hermes orchestrates. Claude Code handles deep architectural reasoning. Codex CLI implements well-specified tasks fast. What was missing was rapid prototyping — the ability to spin up a rough version of something quickly, see if the idea has legs, and throw it away if it doesn't.

Grok Build is good at that. It's fast, it's direct, and it has a different enough perspective that it catches approaches the other tools don't reach for. I don't know if that's the training data, the RLHF, or something architectural about how xAI builds models. I just know that when I ask all four agents the same question, Grok's answer is often the most unconventional.

Sometimes unconventional is wrong. But sometimes it's the thing you wouldn't have thought of.

A Concrete Example

Last week I needed to prototype a health-check endpoint for the LoRA adapter system — something that reports which adapters are loaded, their memory footprint, and how long since last access. The full implementation will need proper metrics, integration with Prometheus, and a Grafana panel. But first I wanted to see if the basic shape worked.

I gave the same prompt to all four agents:

"Prototype a /health/adapters endpoint that returns:
- list of loaded LoRA adapters
- VRAM usage per adapter
- last-access timestamp
- adapter load/unload events (last 10)"

Results:

Claude Code produced a well-structured implementation with proper error handling, logging, and type hints. It would have been production-ready with minor review. Time: 4 minutes. Correct, thorough, slightly over-engineered for a prototype.

Codex CLI produced a compact, working endpoint. Minimal error handling but functionally complete. Time: 90 seconds. Fast, clean, would need hardening before production.

Grok Build produced something different. It included a /health/adapters endpoint, but it also added a /health/adapters/events SSE streaming endpoint for real-time load/unload events — something I hadn't asked for but immediately realized I wanted. Time: 2 minutes.

That's the value. Grok Build reached for an adjacent idea that the other agents didn't. Was it always right to do that? No — sometimes it adds scope I didn't want. But the SSE streaming endpoint is now in the production spec because Grok's prototype made the value obvious.

The Full Toolkit

Here's how the four agents divide the work as of mid-2026:

| Agent | Role | Strength | When I Use It | |-------|------|----------|---------------| | Hermes | Orchestration | Persistence, memory, scheduling | Everything — it routes the work | | Claude Code | Deep refactoring | Context understanding, system reasoning | Architectural changes, complex refactors | | Codex CLI | Focused implementation | Speed, precision | Well-specified tasks, isolated features | | Grok Build | Rapid prototyping | Speed + unconventional approaches | Prototypes, exploring ideas, second opinions |

Each has its lane. The key insight is that they're not competing — they're complementary. A task that's perfect for Codex CLI is a waste of Claude Code's reasoning capacity. A prototype that Grok Build spins up in two minutes shouldn't go through Claude Code's thorough analysis phase until I've decided the idea is worth pursuing.

The Multi-Agent Workflow, Updated

Idea arrives →
  Grok Build: prototype it quickly, see if it works
    ├── Idea is bad → throw it away, cost was low
    └── Idea is good →
        Claude Code: redesign for production, handle the architecture
          └── Codex CLI: implement the production version
              └── Hermes: review, test, deploy, monitor

The prototype-to-production pipeline now has a fast front end. Grok Build handles the "is this even worth building" phase. Claude Code and Codex CLI handle the "now build it properly" phase. Hermes handles everything around the edges — the orchestration, the testing, the deployment, the monitoring.

Does Four Agents Make Sense?

Honestly? Yes. The cost of running all four is trivial compared to the time they save. Grok Build caught the SSE idea. Claude Code caught a race condition in the adapter swap logic that none of the others flagged. Codex CLI ships code faster than I can type it. Hermes keeps all of it organized and persistent.

The question isn't whether four agents is too many. It's whether I'm using each one for what it's actually best at. That took calibration. Early on I was routing tasks wrong — sending prototypes to Claude Code (too slow) and architectural questions to Codex CLI (not enough context reasoning). The routing improved as I used them more.

I keep a mental note: which agent would I hand this to first? The answer has gotten reliable.

Where This Is Going

The toolkit isn't done evolving. New agents will appear. Existing ones will improve. The model quality across all of them is climbing fast enough that the gaps between them narrow with every release. But the multi-agent pattern — orchestration plus specialization — is stable. That's the architecture, not the particular tools.

For now: Hermes orchestrates, Claude Code refactors, Codex implements, Grok prototypes. Four lanes, one workflow, and a Saturday morning well spent.

Time for a second coffee.