Durable workflows
for AI agents

Nine stages: request → reviewed pull request Historical coding evidence below

1. Inbox — Hive creates a task folder for the request. Its files become inputs for later stages. idea.md

   Build a scriptable screenshot CLI. Read every note, not just the first page.

2. Brainstorm — Questions become requirements before implementation starts. brainstorm.md
3. Plan — The plan records scope, implementation steps, and checks for the next agent. plan.md
4. Execute — The builder receives the plan and works on the task branch. task.md
5. Open PR — The change and its context are linked in a draft pull request. pr.md
6. Review — In the recorded Screenote task, review caught notes disappearing after screenshot 100. reviews/
7. Artifacts — Save check results and supporting artifacts for the final handoff. artifact.md
8. Finalize — The PR, review history, and handoff notes stay together. summary.md
9. Done — The task is archived with its artifacts. Completion does not promise an automatic merge. summary.md

Result: Reviewed pull request.

Seven stages: evidence → draft → editorial revisions → article Installable Writing Honeycomb · v1.0.2

hive workflow install honeycomb/writing
Writing 1.0.2 source · Install and configure

1. Inbox — Specify the reader, angle, voice, freshness date, and sources the article must cover. brief.md

   For small teams: explain what a successful backup does—and does not—prove about recovery.

2. Repo research — Inspect relevant repository files. Keep path-and-line references, candidate claims, and gaps that need external verification. repo-research.md
3. Web research — Open the sources behind external claims. Record URLs, authors, dates, credibility limits, and unresolved questions. web-research.md
4. Research — Synthesize the two research files into an outline and a claim map: supported, qualified, disputed, or unsupported. research.md
5. Draft — Use brief.md and research.md to write a complete draft. Material factual claims must trace back to the source ledger. draft.md
6. Editorial — A grounding editor checks claim support. An adversarial editor checks the argument and usefulness. The council can revise and recheck for up to five rounds. editorial.md
7. Deliver — Write article.md and verification.md with claim support, revision deltas, editorial rounds, and the terminal reason. Delivery does not publish the article. article.md

Result: article.md with verification.md. This sample reaches editorial consensus. The real workflow can instead return a NOT PUBLISHABLE notice for unsupported claims or the five-round limit.

Eight stages: repository + web evidence → reviewed architecture Installable Architecture Honeycomb · v1.0.4

hive workflow install honeycomb/architecture
Architecture 1.0.4 source · Install and configure

1. Inbox — An idea is the outcome you want. Start in plain language; the workflow investigates what it will take. brief.md

   I want to run Hive in the cloud. Let people connect a repository, start a workflow, and come back to the result without leaving their laptop running.

2. Repo research — Inspect how Hive starts agents, stores task state, uses worktrees, and handles credentials. Record the code evidence and what still needs investigation. repo-research.txt
3. Web research — Check primary documentation for long-running workers, persistent storage, credential handling, and recovery. Save sources and limits for each option. web-research.txt
4. Research — Read both evidence collections. Synthesize only what changes the decision; do not silently turn gaps into facts. research.md
5. Draft — Describe components, data flow, failure paths, alternatives, rollout, rollback, and tests. Tie material decisions to the saved evidence. draft.md
6. Review — Two reviewers examine missing evidence, tradeoffs, interfaces, and operational risks. The council can revise and recheck within a two-round limit. review.md
7. Architecture — Write the final architecture with traceable evidence, a test plan, owner decisions, and resolved, deferred, or rejected reviewer findings. architecture.md
8. Done — Done is inert: no additional agent runs. The final design and its research and review trail remain together. architecture.md

Result: architecture.md with owner decisions and reviewer findings. The design includes isolated workers, saved task state, and a recovery test plan. Tenant isolation and operating costs still need validation before launch.