Governance & Control

What the enable switch actually gates, how the co-worker's scope is bounded, the guardrails that stop a runaway tool loop, and where to audit what it did.

A co-worker acts on its own initiative, in channels, sometimes with nobody watching. That is the point of it, and it is also the reason this page exists. Read it before you enable one.

The enable switch

The switch in the Co-Worker Studio header is the master control. It is not a cosmetic "published" badge, it is the gate that decides which of two runtimes serves the account.

While enabled	While disabled
The persona applies: name, title, personality, job description	The account answers as the default assistant
Managed skills are included	Base skills only
The recent-activity digest is assembled	No digest is built
Conversation history is searchable	The history tool is withheld and blocked
The organization knowledge base is searchable	The knowledge tool is withheld and blocked
Saved facts are recalled and searchable	Saved facts are still recalled and searchable

Three properties make this usable as a real control:

It takes effect on the next message. There is no cache to wait out and no redeploy.
It is decided by a fresh read, every run. The current state is loaded at the start of each turn rather than inherited from a cached profile.
It fails closed on uncertainty. If that read cannot complete, the turn fails with a visible error instead of guessing an identity. A blip produces a resend, never a run under the wrong persona.

Withholding a tool from the declared list is not enough on its own, because a model can still emit a call it saw in earlier context. The history and knowledge tools are therefore also blocked at execution while the co-worker is disabled: the call is refused with an explanation rather than executed.

What actually bounds its reach

Four things, in descending order of strength.

The account's connections. A co-worker inherits the connected apps, MCP servers, and credentials of the account that owns it, and cannot exceed them. This is the real boundary.
Equipped skills. Skills carry a tool allowlist. Unequipping a skill removes a route the co-worker was reaching for. See Skills.
Sensitive-tool approvals. Tools that act rather than observe always prompt in ask mode, and a grant is remembered for the current session only.
The job description. It steers judgment. It does not enforce anything. See Identity.

One co-worker per role, not one co-worker for everything. An account authorized against the CRM, the ledger, the task board, and the HR policy base produces a co-worker that can reach all four. "Was the co-worker allowed to do this?" has no useful answer when the answer is always yes. Scope the account first, then the co-worker follows.

Identity in unattended runs

A workflow reaches the co-worker through a personal API key on the Flux Agent node, and the run executes as that key's owner. There is no shared service identity.

Treat the key as the identity it is. Anything the workflow does, that person did, under their persona and their credentials.

Loop guardrails

The most likely failure mode of an autonomous tool loop is not a dangerous action, it is a spiral: the same search rephrased twenty times, or the same content re-fetched through four different tools while every call reports success.

A published co-worker runs its tool loop under a controller that watches for exactly this. It escalates in three stages: warn, then block the specific call, then halt the turn gracefully with what it has.

It watches for	Example
Repeated identical failures	The same call with the same arguments failing over and over
One tool failing repeatedly	Different arguments, same tool, no success
No progress	Calls that return nothing useful
Empty streaks	Searches that keep coming back empty, with a reset when the topic genuinely changes
Unproductive search budget	A cap counting only fruitless calls, so long legitimate research is unaffected
Search saturation	Repeatedly re-searching one topic even when every result is rich
Low novelty	Consecutive reads that add nothing new to what has already been gathered
Block storms	Enough blocked calls in one turn to end it gracefully rather than continue

Two design choices are worth knowing:

Counters reset per turn. A guarded turn does not leave a penalty behind for the next one.
A blocked call never runs and never counts as a failure. Blocking is not punished as an error, so a co-worker that gets steered away from a spiral does not then escalate for failing.

Guardrails act between calls. A single call that hangs and never returns is bounded separately by a dispatch deadline set well above the slowest legitimate tool. When it fires, the turn is told the call timed out and its effect is unknown, which is the honest description: the work may still be running on the other side. A real result that arrives late is preferred over the synthetic timeout. Waiting on a human is deliberately not watched.

The learning loop

What a co-worker knows tomorrow is written by a background review, not by an unsupervised scribble during the run.

For an enabled co-worker, the review replays a conversation including the tool path each turn took, and may save or update memories and skills through a narrow, whitelisted tool surface. It cannot do anything else. The intent is that a task solved by wandering through path A to B to C leaves the path behind as a reusable skill, so the next similar request skips the wandering.

It never runs for interrupted turns or scheduled routine runs, and it cannot recurse into itself.

Review what accumulates. Open the Context and Skills tabs periodically and read the recent entries the way you would review a colleague's runbook. Memories reflect what was true when written, and a self-saved skill encodes the assumptions of the day it was saved.

Auditing what it did

Question	Where to look
What has it been doing lately?	Recent activity on the Overview tab
What exactly did it call, and in what order?	The History store on the Context tab
What happened in a specific run?	The Episodic store on the Context tab
What did a channel run do end to end?	The workflow run's execution trace
Is a channel workflow healthy over time?	Monitoring and observability

The distinction matters when someone asks whether something happened. History answers it. A summary does not.

Data handling

The knowledge base is read-only to the co-worker. Documents are authored and managed in the Knowledge Base. A co-worker retrieves from them and cannot write to them.
Credentials are used, never read. The co-worker can invoke a stored credential without the secret being exposed to the model.
Memory is account-scoped. It belongs to the account, not to the persona, so renaming or re-scoping a co-worker does not clear what it learned.

For platform-level controls that sit above all of this, see Security and Governance.