The Operator picks up a task when it is created, or once the tasks it waits on are done. It scopes the goal, dispatches the deployed agents and asks you when a choice is a person's. A new project starts with a Developer and a Reviewer, unless the controller creates it with other agents.
Get startedRead the agents docs
Runs go through the official Claude and Codex SDKs, on the account of the task's owner.
The Operator is on every task. Each agent it dispatches takes a seat of its own: one of them delivers the work, and the rest support it.
One per project, and always called Operator. It reads the task and the repository, dispatches the agents and decides when the work is ready to deliver. A task holds one open decision packet at a time, and the operator opens one when a choice is a person's. It writes no code.
At most one agent on a task delivers. It owns the task's workspace, its branch and its pull request. A profile that holds the repository-write grant takes this seat when the task has no deliverer yet. Its reply is posted as a comment when the run completes.
Every other agent on the task supports the one that delivers, and a supporting agent that can give a verdict is a required reviewer. Viberr's library holds four more agents for work whose result is prose: a Writer that delivers the piece, an Editor that can give a verdict, and a Diagrammer and a Cover Designer that make its pictures as supporting agents.
pull_request:write, so PR status can't auto-sync after merge. Completion still requires explicit human acceptance.vib-142-attach-workspace into main.Policy enginePolicy violation: active PAT is missing pull_request:write. Auto-sync after merge will fail.ClaudeReview & validationQuality flag: snapshot task_projection.json changed — confirm the new compact shape is intended before review.OperatorTransition request: move VIB-142 from In Progress to Review. Branch healthy, evidence attached.OperatorRe-engaged Claude (Reviewer) as reviewer; re-anchored on task.md before review.CodexImplementationBranch work complete. Handing back to operator for the review boundary.Arda KayaTook task ownership — owner is the human reviewer and acceptance authority for this task.A person adds a library agent to a board. A project the controller creates with a list of agents starts with the Operator and exactly those.
An agent is a profile: its backend and model, its effort, the stages where it may be engaged, a persona, and the skills, knowledge bases and MCP servers it is granted. A profile is a template of your organisation. Deployed on a project, it carries that project's own capability policy: a mode for each capability. The modes are direct, human and off, and recommend for the operator alone. You edit the operator the same way, in an editor that has no Name or Role field.
The operator's autonomy is supervised or full, and it is a ceiling. Whatever it is set to, a grant to move stages crosses only the boundaries marked auto. At an approval boundary the operator files a recommendation for a person to apply, and a move marked human is refused. Moves back are another matter: the operator performs a rework move on a failing task directly, and two narrower moves back with it.
No setting gives a specialist a tool for these three. The operator cannot merge either. It accepts completion only under full autonomy with an explicit grant, and the merge still waits for a person.
On a board with a repository, the agent that delivers works in the task's own clone, which the operator shares. Each supporting run gets a fresh clone of that checkout, set at the reviewed revision, or at the review's subject when only base refreshes have followed it. Where no delivering checkout exists yet, it gets a clone of the default branch. A run's skills come from its profile's grants, and on Codex a skill past the prompt's budget is cut. Its knowledge bases arrive as an index, from which it reads the documents it needs. The browser capability is off by default in the catalog, and the Developer that ships with Viberr is granted it. An MCP server's stored credential never reaches the agent's process.
The console of a run shows a redacted line of its inputs, so that you can see what the agent was given. On Claude, withheld grants become a list of tools the run is denied. On Codex the repository-write grants are advisory, and what holds there is Viberr's own boundary: no agent holds a credential, and only the server pushes a branch or opens a pull request.
Every run on a task uses the Claude or Codex account of the task's owner. A task with no owner runs no agents.
A project can name one knowledge base as its settled rulings. Every run on the project reads it, whatever its profile is granted.
Comment on the task to steer the work. A comment that starts with @operator addresses the operator. While a decision packet is open, or once the task is closed, it starts no operator turn and is noted on the task.
On a running instance, open the board, press New task and describe the work. You become the task's owner, and the operator starts as soon as the task exists. To steer it afterwards, comment on the task. A comment from the demo's VIB-142:
@operator if the PAT scope is the only blocker, let's widen it rather than block the whole task.A comment that starts with @operator addresses the operator directly.