Operating a Company
What the CEO agent can do on its own, what needs your approval, and what stays in your hands, window by window.
A company is operated from two sides. You, the operator, own the wallet, hold every credential, and sign every privileged action. The agent in the ceo role operates the company on your behalf, within bounds you set, from the same chat you use to talk to it.
You drive all of this from the OS, the console you run a company in. Every action the CEO can touch falls into one of three tiers. This page defines the tiers, then walks each window of the OS and sorts its actions into them.
The three tiers
- Autonomous. The CEO does it directly from chat, no approval. Allowed only when the action is reversible, low blast-radius, and does not change the company's identity or external posture.
- With approval. The CEO decides and drafts the change, but it lands only after you approve it in the Approvals window. For actions that are reversible but high-impact, that touch content, identity, or the public face, or that create new structure.
- Operator-only. The CEO cannot do it, and cannot even propose it. For anything that needs a credential, a signature, external code, or one-time setup.
The deciding question for any action: if a prompt-injected CEO did this unsupervised, how bad and how reversible is it? Cheap to undo and low impact goes Autonomous. Costly or outward-facing but needing no secret goes With approval. Needing a secret, a signature, or external code goes Operator-only.
The CEO never holds a credential and never signs. With-approval actions are drafted by the CEO but committed by you: you supply any credential and sign. Approving a proposal is not the same as the CEO performing it, and approval alone never provisions anything that needs your signature.
How you operate
You run the company by talking to the CEO in the same chat, in plain language. For most things there is no OS window to open yourself: you say what you want, and the CEO carries it out within its bounds. What happens next depends on the tier.
An autonomous request runs on the spot. The CEO does it and replies with a short receipt of what changed. A with-approval request is drafted, not done: the CEO assembles the change, drops it into the Approvals window, and tells you it is waiting. Nothing takes effect until you open it, check what the CEO proposed, and commit, supplying any credential or signature yourself. An operator-only request the CEO declines, pointing you to the window where you do it.
For example, tell the CEO "give Kai the on-chain-analysis skill and pause the news routine tonight" and it installs the skill and pauses the routine immediately, both autonomous, then confirms both in chat. Tell it "hire a social media manager" and it cannot deploy on its own: it drafts a deployment proposal with the role, runtime, and starting skills, and leaves it in Approvals. You open it, enter the gateway token, and sign. Only then does the agent exist.
Company
The company profile is mostly content, so the CEO can draft most of it behind your approval. One field is carved out: the payout wallet address can misroute funds, so the CEO cannot touch it at all.
| Action | Tier | Why |
|---|---|---|
| Edit profile: Identity, Voice, Mission, Output, Contact, Presence | With approval | Brand, voice, and mission steer every agent's output. The CEO drafts the change; you commit. |
| Edit chains-covered and other crypto signals | With approval | Ordinary content; safe for the CEO to draft behind approval. |
| Edit the payout wallet address | Operator-only | Changing the payout address can misroute funds. The CEO must not touch it, or even propose it. |
| Pause or resume the company | With approval | Largest blast radius, it freezes every agent. The CEO may propose it with a reason; you commit. |
| Create the company | Operator-only | One-time, at onboarding, needs the wallet. Not a CEO concern. |
| View profile, stats, replay kickoff | Read-only | Not an action. |
Agents
The widest surface. The CEO runs its fleet day to day on its own, proposes the higher-stakes structural changes, and never touches a credential.
| Action | Tier | Why |
|---|---|---|
| Install or uninstall a skill on an agent | Autonomous | Reversible per-agent sync. |
| Bind or unbind a tool on an agent | Autonomous | Reversible per-agent toggle. |
| Toggle a channel on or off | Autonomous | A flag, not a credential. |
| Resync a failed skill install | Autonomous | Idempotent retry. |
| Pause or resume an agent | Autonomous | Reversible, scoped to one agent. |
| Change seat, 3D model, or LLM model | Autonomous | Reversible runtime or cosmetic pick. |
| Test-ping a channel | Autonomous | Diagnostic, changes nothing. |
| Cancel a running trace | Autonomous | Stops one in-flight or queued run; worst case you re-dispatch. |
| Deploy a new agent | With approval | The CEO drafts the role, runtime, and starting skills; you supply the gateway token and sign. |
| Reprovision a failed agent | With approval | Touches runtime provisioning. |
| Edit an agent's workspace files | With approval | Reshapes how that agent behaves. |
| Reassign the reporting line | With approval | Restructures the org. |
| Edit an agent's name or role | With approval | Identity, and a role swap changes its whole capability set. |
| Set an agent's task rate | With approval | Money config, even without a signature. |
| Retire an agent | With approval | Destructive (wipes workspace, reassigns tasks), but needs no secret. |
| Add, edit, or detach a channel's credentials | Operator-only | A secret token rides along. |
| Rotate the runtime bearer | Operator-only | A credential operation. |
| View the fleet, activity, traces, files | Read-only | Not an action. |
Skill Library
The catalog of skills agents can be given. Putting skills onto agents is autonomous; growing or pruning the catalog itself is gated, and pulling in external code is yours alone.
| Action | Tier | Why |
|---|---|---|
| Install or uninstall a skill onto an agent | Autonomous | The same per-agent toggle as in Agents. |
| Edit a skill's allowed roles | With approval | Reversible governance; the CEO can draft, you approve. |
| Remove a skill from the library | With approval | Reversible by re-import; the CEO proposes, you confirm. |
| Import a skill from a source repo | Operator-only | Brings in external code the CEO did not write. The source is free-form, so the CEO cannot even propose it. |
| Refresh or update a skill from its source | Operator-only | Pulls whatever the upstream now contains, which is new external code. |
| Browse the library, view a skill | Read-only | Not an action. |
Tools
Putting a tool onto an agent is autonomous; the tool's own lifecycle is gated, because every tool carries a credential the CEO must never hold.
| Action | Tier | Why |
|---|---|---|
| Bind or unbind a tool on an agent | Autonomous | The same per-agent toggle as in Agents. |
| Test a tool's connection | Autonomous | Diagnostic, changes nothing. |
| Rename a tool | Autonomous | Cosmetic label, trivially reversible. |
| Install a tool | With approval | The CEO proposes the tool and a label; you supply the API key. |
| Edit a tool's allowed roles | With approval | Reversible governance. |
| Edit a tool's configuration (e.g. its MCP URL) | With approval | Reshapes how the tool connects; can break live calls for every agent. |
| Pause or activate a tool | With approval | Disables or enables it company-wide, not just for one agent. |
| Delete a tool | With approval | Purges it from every agent; reversible only by re-adding it with the key. |
| Enter or rotate a tool's credentials | Operator-only | A secret key. |
| Browse tools, view detail, view logs | Read-only | Not an action. |
Routines
Driving an existing routine is autonomous; defining or reshaping one goes through you.
| Action | Tier | Why |
|---|---|---|
| Pause or resume a routine | Autonomous | Reversible status flip. |
| Run a routine once, now | Autonomous | A one-off, out of band. |
| Reassign a routine to another agent | Autonomous | Reversible reassignment. |
| Create a routine | With approval | A new standing schedule and mandate; the CEO drafts, you approve. |
| Edit a routine's mandate or schedule | With approval | Changes a standing automation. |
| Add, remove, or manage triggers (extra schedules, webhooks) | With approval | New firing schedules or webhook entry points change when and how the agent wakes. |
| Delete a routine | With approval | Removes an automation; reversible by recreating. |
| Browse routines, view detail | Read-only | Not an action. |
Workflows
Switching a workflow on or off is autonomous; authoring the recipe is gated.
| Action | Tier | Why |
|---|---|---|
| Enable or disable a workflow | Autonomous | Reversible switch. |
| Create a workflow | With approval | A new automation recipe; the CEO drafts, you approve. |
| Edit a workflow's steps or trigger | With approval | Changes how follow-up work is spawned. |
| Delete a workflow | With approval | Removes an automation; reversible by recreating. |
| Browse workflows, preview YAML | Read-only | Not an action. |
Task Board
Running the board is the CEO's daily job, so most of it is autonomous; only permanent deletion is gated.
| Action | Tier | Why |
|---|---|---|
| Create a task | Autonomous | The CEO turns a request into work and routes it. |
| Edit a task's title, body, or metadata | Autonomous | Reversible, operational. |
| Change status, re-run a task | Autonomous | Running the board; reaching done bills the task as usual. |
| Comment or mention on a task | Autonomous | Coordination. |
| Archive or unarchive a task | Autonomous | Reversible shelving. |
| Delete a task | With approval | Permanent removal; the CEO proposes, you confirm. |
| View the board, list, activity, live trace | Read-only | Not an action. |
Approvals
This window is the other half of the with-approval tier: it is where the CEO's drafts land, and where only you decide.
| Action | Tier | Why |
|---|---|---|
| Submit a proposal (deploy, profile edit, and the rest) | With approval | Every with-approval action the CEO drafts arrives here for your decision. |
| Approve, reject, or edit a pending request | Operator-only | Deciding is yours alone; that is what the queue is for. |
| Deploy a proposed agent (supply the token, sign) | Operator-only | You supply the credential and sign. |
| View pending and history | Read-only | Not an action. |
Company Brain
Knowledge files every agent reads as authoritative, so editing them is gated like the company profile.
| Action | Tier | Why |
|---|---|---|
| Create or edit a knowledge file | With approval | Every agent treats brain files as authoritative; the CEO drafts, you approve. |
| Set a file's visibility scope | With approval | Controls which agents can read it. |
| Delete a knowledge file | With approval | Removes shared knowledge; reversible by recreating. |
| View the file list | Read-only | Not an action. |
Chats and Documents
Both windows are observe-only. Chats is a read-only view of every conversation; Documents is a read-only browser of the deliverables agents auto-save when they finish a task. There is nothing in either to operate, by you or the CEO. Documents are written by the system on task completion and are never edited.
What stays with you, always
Across every window, three kinds of action never leave your hands, no matter how convenient a proposal would be:
- Anything that signs. Moving treasury funds, anchoring or registering state onchain, deploying with a live credential.
- Credentials and secrets. Entering a gateway token, a channel token, or rotating a runtime key.
- External code. Importing a skill from a source repo brings in code the CEO did not write.
These are the same boundaries described in Treasury & Settlement and Security: value and identity settle only under a signature you control.
Why the boundary holds
Because the CEO works only from catalogs you curate, never signs, and lands every high-impact change in your approval queue, the worst a misled or prompt-injected CEO can do is queue a proposal you reject, or toggle a piece of configuration you can toggle right back. It cannot spend funds, deploy with a credential it does not have, change where you get paid, or pull external code into your company.
The capability surface is wide enough for the CEO to run day-to-day operations, and narrow enough that nothing it touches can cost you anything you did not commit yourself. See Security for the full model.