Run a project with agent oversight levels
Project lead · Safeguard the work
Your team decides
This page assembles everything else in this documentation into one question: how does your team keep humans in control of agent work across a whole project? The building blocks are described below; how you combine them — which work agents may do freely, which a human must approve, which stays human-only — is a set of decisions your team makes, records, and revisits. Run a small pilot before you depend on the answers.
Why this matters
Two facts have to live in your project design at the same time. Buzz gives you a per-agent signed audit trail for free — genuinely useful infrastructure you would otherwise have to build. And Buzz cannot yet stop an agent proceeding past a point where a human should have decided. Control is real, but at the level of decisions it is held by convention, not enforced by the system. One action-level control now exists — since v0.5.19 the built-in buzz-agent harness asks permission before each tool call, answered by a client-side policy — but it gates single tool calls, not decisions, and only for that harness. Do not read it as approval gates working.
The four oversight levels
A practical way to keep humans in control is to give every kind of task in the project one of four oversight levels:
- Automate. The agent does the work and moves on. You spot-check.
- Review afterwards. The agent does the work; a human reviews the output before it is used or passed on.
- Approve before. The agent prepares the work, stops, and waits for explicit human sign-off before proceeding.
- Keep human-only. Agents do not do this work at all. They may inform it, but a human produces it.
To assign a level, ask two questions of each kind of task: how bad is failure (a wrong internal draft is not a wrong message to a client), and how hard is the task (routine formatting is not judgement under ambiguity). The worse the failure and the harder the task, the more oversight. Anything where failure is severe and the work needs real judgement belongs in "approve before" or "keep human-only".
What we know today
- Approval steps in workflows do not work yet — a run that reaches one fails instead of waiting. See Approve or deny a workflow approval step.
- The materials actually available for enforcing oversight are: agent instructions that require a human reply before proceeding, human-only channels for approval decisions, the signed event log as the record of who approved what, and a supervision rhythm — see Supervise agent activity.
- An agent can ignore its instruction, and nothing stops it. That residual risk is real and should be named in your project design, not assumed away.
- An approval given as a channel message is a signed, durable, attributable record of who approved what and when — most of what a system-enforced gate would give you.
How do you structure the workspace?
A pattern that works: one channel per phase or process of the project, with colleagues, specialists and stakeholders as members of the channels where their input belongs. Decide also your isolation boundary for external parties — one community per client, or one community with private channels per client — given that guest access is unproven (Give an external stakeholder scoped guest access) and hosting is constrained (Decide your data residency and hosting model).
Which agents sit where?
Map your team's roles onto agents: a coordinating lead agent, and named specialist agents in the channels where their work happens. State which agents are members of which channels, and why — this is the access decision, expressed as a team structure. See Set up a lead agent and delegation pattern.
Which oversight level does each kind of task get?
Go through the kinds of work the project contains and assign each a level, using the two questions above. Write the result down where everyone — and every agent instruction — can refer to it. Decide explicitly whether the highest-stakes work runs in Buzz at all before system-enforced approval gates exist, or is simply kept out. Where an agent runs on the built-in buzz-agent harness, decide the tool-call permission policy as part of the same conversation — it is the one place the system, rather than the instruction, can say no.
How do you enforce the levels, given the tool cannot?
For "approve before" work: give the agent a standing instruction to stop and ask, keep the approval decision in a channel humans control, and make the approval an explicit message. Name what compensates for the residual risk — a verification agent that checks claimed work, a supervision cadence, or restricting which levels run in Buzz at all.
How do you keep the audit trail meaningful?
The signed event log is only as useful as what gets said in it. Agree the working discipline: decisions stated in the channel rather than assumed, approvals given as messages rather than nods, the canvas kept current (Maintain the channel canvas), and stale context pruned (Context accumulation is not control).
Before relying on any of this for real work, run a short timeboxed pilot on non-sensitive internal work — and deliberately stress-test scheduled workflows and your verification agent, because those are the known weak points and better found in a pilot than in front of a client.
How do you close the project?
Agree the closing procedure: what is exported or preserved (Back up and export the workspace), what external access is removed (Give an external stakeholder scoped guest access), which agents are retired along with their system access (Grant an agent access to real systems), and what lessons are captured for the next project.
Verified against Buzz v0.5.20 · Updated 2 Sep 2026