The Hive Playbook — one agent platform, five kinds of work
A chat box with an LLM is a toy. What makes a self-hosted agent platform useful is the playbook: the specific combinations of engine, tools, and surface that turn it into a coding team, a research desk, a QA gate, and a business analyst. Here are the five workflows we actually run on Hive, tool by tool.
Most “AI for teams” pitches stop at the chat box. You get a text field, a model behind it, and a
promise. Two weeks later the novelty wears off and it’s a slightly-faster Google. The reason is
never the model — it’s that a chat box has no hands. It can talk about your pull request but not
review it, describe a test plan but not run it, outline a spec but not hand you the .docx.
We built Hive — a self-hosted agent platform on infrastructure we already pay for — and the thing that made it stick wasn’t a smarter model. It was the playbook: a small number of repeatable combinations that turn the same platform into five different specialists. This post is that playbook, concretely, tool by tool.
The two axes
Every workflow in Hive is two choices, and once you internalize them the rest is Lego.
Engine. A fast engine is a tool-loop: the model calls a tool, reads the result, calls another, and answers — bounded and cheap, perfect when you know the shape of the task. A smart engine is the Claude Agent SDK running autonomously: it plans its own path, takes many steps, and figures out the parts you didn’t specify. Fast for “do this”; smart for “figure this out.”
Surface. Chat is interactive. Origin is a kanban of autonomous runs — you assign a task to a card and walk away. Automation fires an agent on a schedule, a webhook, or a Telegram message.
Pick an engine, give it the right tools, choose a surface. That’s a workflow. Here are the five that earn their keep.
1. Coding
The coding surface has three gears, and the trick is not using the heaviest one for everything.
Low gear — in chat. A fast agent with run_code (sandboxed throwaway execution) and
run_tests (clones a repo, auto-detects npm test / pytest / go test / make test, runs it)
handles “write this script” or “are the tests still green?” without any PR ceremony.
Middle gear — dispatch a change. cursor_code hands a real task to a Cursor Cloud Agent that
clones the repo in its own cloud, edits, and opens a PR — a drive-by change while you keep talking.
High gear — autonomous engineering. Hive Origin with the smart harness is the Devin-style path: it clones the repo, writes a plan, implements it, runs the tests, self-reviews, and opens the PR, streaming every step to a run timeline. You assign; it engineers.
Then the loop closes: a reviewer agent runs pr_review — a rigorous review that breaks the PR
description into claims and verifies each one against the diff — and posts the verdict with
github_pr_review. Clean PR gets github_add_labels qa-pass; a shaky one gets specific
change-requests. The whole cycle lives inside the platform.
2. Research
Research is worthless if it evaporates into a chat nobody reads again, so the workflow has a tail.
A fast agent with web_search, fetch_url, and wikipedia does the gathering; a harness rule —
research first, cite sources, then answer — keeps it honest. For a question that needs a dozen
searches and cross-reading, the smart engine plans its own path instead of a fixed loop.
The tail is the point: the agent calls save_knowledge (a finding) or save_context (a meeting,
an email thread, a client doc) to write into a shared knowledge base backed by semantic retrieval.
Every other agent with search_knowledge then recalls it forever. Research stops being throwaway
and becomes institutional memory.
3. QC
Quality has two targets: the code, and — this is the one people forget — the agents.
For code, run_tests is the cheap gate. But the workflow that changed how much we trust a deploy
is browser_agent: it drives a real Chromium — navigate, click, type, fill forms, and log into
web apps. Credentials come from a vault (the model never sees the password) and a persistent
session keeps it logged in across steps, so “log in, create an order, confirm the total, screenshot
it” is one instruction against the actual deployed preview. A defect becomes a
github_create_issue with the failing screenshot attached; the fix gets a pr_review.
For the agents themselves, an eval harness pins behaviour with golden sets and checks, and runs on every agent save. Prompts drift the moment you edit a harness; evals are unit tests for your prompts. QC that ignores the agents is QC with a blind spot.
4. BA
The business-analyst workflow is where a chat box’s lack of hands hurts most — and where tools pay off most visibly, because the output is a file someone opens.
The agent gathers first: calendar (meetings + Meet links), recent_emails (catch up on a client
thread), search_knowledge (what we already know), then save_context to lock the synthesized
picture into the KB. Then it produces the actual deliverables: generate_docx turns markdown into
a Word BRD, generate_pptx turns an outline into a stakeholder deck, generate_xlsx turns a JSON
array into a backlog or a requirements matrix — each returning a download link. Finally
github_create_issue (or Linear, over MCP) turns each agreed requirement into a ticket.
Discovery to backlog, with the spec, the deck, and the tickets, in one conversation.
5. Ops
The quiet workhorse. A smart agent with bash and read-only credentials is an auditor — the
read-only AWS auditor harness is our template: run real commands, show real output, never attempt a
write it can’t do anyway. Lighter checks use a fast agent with http_request (which refuses
internal/private addresses by default). And any agent becomes unattended by wiring it to a
scheduled trigger, a webhook, or a Telegram message, pushing results back with telegram_send.
“Summarize overnight email at 8am and post to Telegram” is a five-minute automation.
The composition is the platform
None of these agents is impressive alone. The value is the fabric between them: a research agent feeds the knowledge base, a BA agent reads it and writes the BRD, an Origin run implements the spec, a QA agent browser-tests the preview, a reviewer approves the PR. Each step is a small, well-scoped agent doing one thing; Hive is what lets them hand off.
That’s the real lesson from building it. Don’t chase one omniscient assistant — that’s the chat-box trap in a bigger box. Build a toolbox of narrow specialists and a fabric that connects them. The model you rent. The playbook you build. And the playbook is where the leverage lives.
Want something like this built for your team?
Get a quote →