How a 22-Person Team Keeps 75 AI Agents Governable

How BitSafe Runs on Notion, Part 5 of 5

One agent can live in somebody's memory. Seventy-five cannot.

As of 26 August 2026, BitSafe has 75 active Notion agents supporting a team of 22 standard workspace members. At that scale, model quality is only part of the operating problem. The company also needs to know what each agent does, who owns it, what it can change, and how its behavior evolves.

We treat agent governance as an operating system. The system combines a registry, narrow scopes, recorded instruction changes, permission boundaries, and alerts designed around human action.

The main lesson is that governance lowers the cost of adding agents when it makes ownership and change visible.

Every active agent belongs in one registry.

The registry records the agent's purpose, owner, status, triggers, connections, permission scope, and instruction source. It also links to the history of proposed and applied changes.

This solves a basic visibility problem. Without a registry, agents accumulate as local experiments. A useful automation may continue running after its original owner changes roles. Two agents may begin responding to the same event. A scheduled task can become part of company operations without anyone reviewing whether its mandate is still current.

The registry gives us one place to inspect the fleet. If an agent is retired, its status changes. If ownership moves, the record moves with it. If two mandates overlap, the conflict is visible before runtime behavior becomes confusing.

A directory alone does not create governance. It makes governance possible because the company can see the whole surface area.

We design agents around narrow outcomes.

A classifier should classify a known property. A drafting agent should produce a defined type of draft in an approved destination. A watcher should monitor a clear event and notify the person who can act on it.

This scope makes testing practical. It also limits the effect of a bad interpretation. When an agent has one job and a constrained set of tools, the team can understand what changed without reconstructing a broad chain of intent.

General-purpose interaction still has a place. Employees may ask a conversational assistant to retrieve context or help shape work. Operational agents that run repeatedly need tighter boundaries because their behavior becomes part of the company's infrastructure.

Narrow scope also clarifies ownership. The owner is accountable for whether the instructions still match the job. The owner does not have to inspect every run, but they must be identifiable when a question or exception appears.

Agent instructions are operational policy. We do not want them changing invisibly.

Our change process has three stages.

The agent does not rewrite its own mandate because a conversation suggested a better rule. User corrections can become valuable learning, though durable behavior changes still need a visible record.

This creates an audit trail that people can understand. We can trace what changed and why without relying on a code diff or an administrator's memory.

The separation matters most when an instruction could broaden audience, access, or side effects. A small wording change can alter operational behavior. Treating instructions as governed configuration keeps that risk visible.

An agent should have the minimum access needed for its job.

Workspace access is scoped by source and action. A drafting agent may need to read brand guidance and edit a destination document. It does not need permission to publish. A classifier may update one database property without changing the schema. A monitoring agent can remain read-only.

Human approval stays in the path for destructive operations and other high-risk actions. Reversibility shapes the boundary. A routine internal write inside a constrained schema is easier to correct than a deletion, a broad update, or an external action.

Automated customer-channel campaigns have their own review path: the marketing workflow requires human approval before distribution. Agents can draft the message and assemble context. They do not decide alone that a group of customers should receive it.

These controls work best when enforced by the surrounding system rather than phrased as polite instructions. A model should not be able to talk its way around a permission boundary.

A fleet can be technically observable and still overwhelm its operators.

If every successful run creates a notification, the team learns to ignore the channel. If failures remain buried in logs, the registry becomes a catalogue rather than an operating tool.

We design alerts around decisions. A routine success can remain quiet. A blocked workflow should tell the owner what needs attention. A proposed instruction change should reach the approver. A high-risk action should stop at a clear confirmation point.

The message should carry enough context to act without opening several systems. It should also avoid broadcasting sensitive details to an audience that does not need them.

Notification discipline is a form of permissioning. It controls who learns what, when, and for what purpose.

Logs are useful when they support a decision.

At the fleet level, we need to know whether expected work ran, whether a task failed, which agent acted, and what changed. For instruction governance, we need the proposal and approval history. For an individual output, we need enough traceability to inspect the source and destination.

We do not assume perfect recall or universal self-healing. Agents start from bounded context and can fail. Scheduled work can miss an expected run. An external source can be unavailable. Observability should surface those conditions to the right owner without pretending the system can resolve every exception on its own.

NanoClaw adds execution monitoring for work that runs outside Notion. Notion remains the collaborative record for ownership, approvals, and durable operating context. The two systems complement each other because governance needs both runtime evidence and a human-readable source of truth.

The hardest fleet problems often appear between agents.

Two agents may both believe they own a response. A drafting agent may hand work to a design workflow before approval. A monitoring agent may notify a broad group when one owner would be enough.

We handle these cases through explicit boundaries in the registry and instructions. One workflow owns each handoff. Destinations are named. Approval responsibility belongs to a person. When two systems touch the same record, the state model determines which one acts next.

This is less glamorous than adding another model. It prevents duplicated work and conflicting messages, which matters more at scale.

A governance system is working when the next agent enters a known pattern.

It gets an owner and one purpose. Its triggers and permissions are reviewed. Its instruction source is recorded. High-risk actions stop for approval. Its notifications have an audience, and its failures have somewhere to go. Future instruction changes use the same recorded process.

That structure does not eliminate judgment. It tells the company where judgment belongs.

For a small team, this is what makes a large fleet manageable. We do not depend on one person remembering every automation. The workspace preserves the map, the ownership, and the history.

Governance is the infrastructure that lets agent capability grow without making accountability disappear.

Subscribe to the BitSafe newsletter for more from the Canton ecosystem and occasional field notes on how BitSafe operates.