Reviews, grants, and capability requests

Yodu keeps three governance surfaces around the work itself. They answer who may act on work they do not own, who checks a piece of work before it counts as finished, and what happens when an employee needs something it does not have.

These used to sit inside a larger "Company OS" that also carried objectives, key results, metrics, targets, a cockpit and an operating calendar. Those were removed: across every workspace, not one key result ever received a measurement, no task was ever linked to an objective, and no AI employee ever wrote to any of them. What is documented below is what people and agents actually use.

Reviews

Work that reaches REVIEW is not finished. It waits for someone other than its author.

The review queue sits beside human approvals, on the Approvals page. Each entry shows the work, its type, who is assigned, how long it has been waiting against its SLA, and the evidence attached to it. A reviewer claims an entry, reads the evidence, and either accepts it or sends it back with a written rationale. The rationale is the review record, so it is required.

AI employees take part in the same queue rather than a parallel one. An employee that holds review authority can list what is waiting, claim an assigned review and record a decision. No employee can accept its own work, including work it once held and handed on.

Management grants and reporting lines

By default an AI employee acts on its own work. Anything wider is a deliberate record:

• A reporting line says one employee manages another, so the manager can act on the report's work.
• A management grant gives one employee a named action over a named scope, optionally with an expiry. Creating a task, assigning it, moving it, cancelling it, claiming a review and deciding a review are each separate actions.

Both are visible and revocable on the Team page, and every revocation records a reason for the audit trail. An employee is told what it holds; nothing is implied. If an action is refused, the answer is to grant it deliberately, not to widen the employee's autonomy.

Capability requests

An employee that cannot do something asks rather than improvises. It can search what it is able to do, then raise a request for a connected app, an API.market tool, a ClawHub skill, a custom MCP server, a company document, or help from a named coworker.

A request is not access. Work linked to one stays blocked until an owner resolves the request and the employee is told it is now available. Owners see the queue, with what was asked for, why, and what it was for, on the Tools page.

What still needs a human

Creating is not sending, drafting is not publishing, and delivered work is not an accepted outcome. Consequential sends, posts, spending, deletion, production changes and access changes go through Yodu's approval and tool-access paths, whatever an employee's grants say.

Start with first value

Founding onboarding does not require a large implementation. Start with one useful responsibility, and let your onboarding owner record the first accepted result. See Your first AI employee.