Administering the mesh and automations

Administering Business-Gym means configuring five separate surfaces: desktop operators, workflows and their schedules, the background automations that keep the mesh ticking, per-head settings, and the tenant-wide policy and kill switch. This page says what each one really does today.

Everything below sits under the same hard floor as the rest of the platform. Admin rights let you change how much the system prepares on its own; they do not let anything send externally or move money without a person — see autonomy and the hard floor.

What can I administer, and where does each control live?

Five screens carry the admin controls, and they are deliberately not merged into one console — each one owns a different kind of risk.

Screen	Where	What you control there
Operators	Admin → Operators	Register, rotate, revoke a desktop operator; view its activity; send it a directive
Workflows	Build → Workflows	The workflow list, the canvas editor, run now, dry test, pause, delete
Automations	Operate → Automations	Status of the mesh’s background jobs; pause/resume where that is actually possible
Head settings	Build → Your Heads → a head → settings	Name, mailbox, mandate, model, tick cadence, daily cost cap, granted tools
Settings	Admin → Settings	Spend caps, trust defaults, privacy posture, and the kill switch

All five are admin- or owner-only and all five are web-only — see the device limits at the end of this page.

How do I connect a desktop operator?

A desktop operator is a small app that runs on one of your own machines and drives tools you are already logged into, such as DATEV or LinkedIn, on instruction from Business-Gym.

Register it in Admin → Operators. Click + Register Operator, give it an email address, and Business-Gym returns a one-time token. That token is shown exactly once — Business-Gym stores only its hash, so it is never re-fetchable. Copy it into the desktop app before you dismiss the banner.

Each row then shows the operator’s health — online, offline, needs re-login or revoked — its capabilities, and when it was last seen. Two buttons manage its credentials:

• Rotate issues a fresh one-time token and invalidates the old one. This is what you use when a token is lost or you suspect it leaked.
• Revoke shuts the operator out entirely. A revoked operator can no longer claim work.

View activity opens a drill-down with the token audit trail — every register, rotate and revoke, who did it and when — and the operator’s recent directives with their status.

Caution

There is no way to recover a one-time token after the banner is dismissed. If it is gone, rotate; do not wait to find it somewhere.

What happens when I send a directive to an operator?

A directive is one instruction — a capability plus an action, such as datev list-documents — that you hand to a specific operator from the ▶ Run directive form on its row.

The form carries a “Requires approval” checkbox that is on by default. Leaving it on is the safe path, and it now behaves the way it reads: enqueuing the directive stages a card in the approval queue, and the operator cannot claim the work until a person approves it. This was a real gap until recently — the directive was created correctly unclaimable but nothing could ever approve it, so it sat forever. It now has a door.

Unticking the box means the operator claims the directive on its next poll and runs it. Only untick it for low-risk reads such as listing documents. Write actions stay fail-closed to approval by design.

The approval card shows the capability and action so the approver knows exactly what will run. It does not show the directive’s arguments. Work these cards the same way as everything else in the approval queue.

How do I run, schedule and pause a workflow?

Workflows are the reusable procedures that wake up your heads, and they live in Build → Workflows as a filterable list you can narrow by status, owning head or text.

Clicking a row opens a drawer showing the real stored trigger, the steps in the definition, and the last seven days of activity — last run, run count, cost and success rate. Where there is nothing to show, it shows a dash rather than an invented figure. From that drawer you can:

• Run now — only enabled once the workflow has a published version. A draft has nothing to run.
• Test run (dry) — a dry run that does not act.
• Pause — stops new runs immediately; in-flight items are parked, not lost, and you can record a reason that goes into the audit log.
• Open canvas editor — the visual builder for the workflow’s steps.
• Delete — stops the schedule and removes the workflow; run history is kept for audit.

You can also assign the owning head from the same drawer.

Schedules are real. A workflow with a cron trigger has a stored schedule with a timezone, and the heartbeat strip at the top of the list is fed by actual firings. A scheduled run still passes through the trust gate — a fire can be held because of the panic switch, because a step performs a sensitive action that is not gated, or because the workflow’s own gate requires a person.

Note

The starting trust gate for new workflows is set once in Settings → Trust defaults (Auto, Auto + audit, Draft, or Human only). That setting saves. There is no per-workflow trust-gate control in the drawer today.

What is on the Automations page, and what can I actually pause there?

Operate → Automations lists the background jobs that keep the mesh running — the head control-loop driver, the workflow scheduler, mailbox ingest, the CEO daily brief, SharePoint and CRM syncs — with a status and a last-activity time for each.

The important distinction is that only some rows can be paused from this page. Rows on the mesh control plane have a working Pause/Resume button. The worker’s scheduled jobs are read-only: they are armed by deploy-time configuration, so instead of a button that could not do anything, each row states how it is actually controlled.

Status is read from the scheduler’s own records rather than guessed, so a job that is dark on your deployment reads as paused, and a failed lookup reads as unknown rather than as running.

How do I stop everything at once?

There are two kill switches, and they stop different things.

Settings → Kill switch → Pause all automations bulk-pauses every active workflow for your tenant. It is admin-only, asks for confirmation twice, and records the reason you type in the audit log. In-flight items are parked and resume when you re-activate.

The panic switch on the Heads page drops every head’s effective mode to supervised, whatever each head’s own dial says. Non-admins do not see the control, but they do see a banner while panic is on, so nobody is working against a state they cannot see. It is covered in detail in the autonomy dial and the panic switch.

Neither switch erases your configuration. They change what is allowed right now, not what your settings say.

Which admin controls are not finished yet?

Several controls on these screens are present but not wired, and the interface labels them as stubs. They are listed here so you do not plan around them.

On a head’s settings page, the fields that genuinely save are display name, M365 mailbox, mandate, model, strategic tick cadence and the per-day cost cap. The per-run cap, per-month cap and the “on cap trip” behaviour are stubs, as is the persona selector, and the Pause Head button is disabled.

The Danger zone records intent, it does not execute. Deprovisioning a head and running a DSAR purge both require a human approval and are explicitly not carried out by the button — the action is recorded for audit and stops there.

There is no ops analytics dashboard. Nothing aggregates automation performance into a reporting surface. Per-row status on Automations and per-workflow seven-day rollups in the drawer are what exists.

Last-activity is blank for some automation rows. A dash means genuinely never run or not yet recorded, not zero activity.

Who can use these screens, and from what device?

These screens are for admins and owners only, and they work in a web browser. Non-admin members either do not see the controls at all or see them read-only, and the server re-checks the role on every write, so a hidden button is not the only thing protecting the action.

There is no native mobile app and no push notifications. Approving is the part that works well on a phone browser; administration is not. Registering an operator, editing a workflow on the canvas, or pausing every automation are all things to do at a desktop — see who can approve, and where for the full device picture, and integrations for what each connection is permitted to do once a workflow reaches it.

Can I see and edit the playbooks myself?

Partly. Workflows are yours to open, change and republish, if you are an admin. The inbound playbooks are not — there is no screen for those at all.

What you can edit. In Build → Workflows, starting a new workflow opens a page of ready-made starters you can filter by owning head. Picking one creates a draft and drops you straight into the canvas editor, which gives you a library of steps to drag in, a panel for configuring each step, a cost estimate, version history and a Publish button. A draft has nothing to run until you publish a version. Creating, editing, publishing and deleting workflows are all admin-only, and a few starter cards have no ready-made steps behind them, so they open an empty canvas instead.

The “Describe what you need” box does less than its wording suggests. It matches what you type against the existing starters and proposes the closest ones — picking one of those proposals does seed a real starter. Pressing Build instead does not write a workflow for you: it creates an empty draft named after your sentence.

What you cannot edit. The playbooks that decide “when this kind of item arrives, do these things” are not something you set up. There is no list and no editor for them, and the Industry packs entry under Resources is a placeholder, not a library. Playbook matching itself is largely not built yet, so there is little sitting behind the missing screen today — see how your team learns.

The nearest thing you steer yourself is the Teaching rules you write with the Teach the AI box on a triage row. They are listed on the Channels page, where an admin can switch one off or delete it.

How do I control what Business-Gym spends?

Set a daily cap in euros in Admin → Settings under Spend, and, for a single head, a per-day cap on its own settings page. Those two are the controls that actually bite. The monthly cap in the same Spend card saves and is shown back to you, but nothing enforces it today.

Both fields in the Spend card save — the change is admin-only and is written to the audit log. The daily one is the one that acts. Before a scheduled workflow run fires on its own, Business-Gym adds that run’s estimated cost to what your company has already spent that day; if the total would go over the cap, the run is skipped and recorded, not shortened. What is left of the day’s budget then becomes that run’s own ceiling, at most, so a single run stops when it reaches it. The day is counted from midnight UTC, not your local midnight.

Two limits on that. A run you start yourself does not pass this check — the company daily cap governs what the system does unattended. And it is scheduled workflow runs it governs; a head’s own turns are held to the head’s cap instead.

A single head can carry its own per-day cap, in the Cost caps section of its settings page. A head that has spent it is skipped for its scheduled turns until the next day, with the reason recorded, and inside a turn that does run, the expensive strategic step is skipped once the cap is reached. The Per run, Per month and On cap trip controls beside it are labelled as stubs and do nothing. Two things to know about the working field: the Per day box opens empty rather than showing the cap you already saved — leaving it blank changes nothing, but you cannot read your current cap from it — and the head’s own Cost tab always reads “no daily cap set” whatever you have saved.

Nothing alerts you before a cap is reached. The gauge carries a line promising a Concierge alert thirty minutes before a cap trip; that alert does not exist today. What you do get are two passive signals, both on Overview: the Monthly budget gauge changes colour as the month’s projected spend nears and then passes its cap, and an entry appears in the exceptions list once the projection goes over.

Read that gauge for what it is — an indicator, not a third limit. Its cap is your per-head daily caps added together across the days of the month, not the monthly figure in Settings. The budget shown on the Cost & usage page is different again: it is fixed at the deployment level and is not a control you set.

Which AI models run my team, and can I choose?

Your team runs on Claude models from Anthropic — Opus, Sonnet and Haiku — and there is a per-head model setting an admin can change, though today it decides much less than it looks like it does. The control is the Model dropdown on that head’s Configure tab, and it names the exact version of each. Every head starts on the most capable of the three.

The dropdown lists only models that are genuinely wired, and today that means Claude and nothing else. No other AI provider is selectable in the app.

Your plan does not shrink the menu. Trial and paying customers are offered the same three models — model choice is not something you unlock by paying more.

What the setting does not decide yet

Chatting with a head does not read the dropdown at all. It uses that head’s built-in default, which is the most capable model for every head today.

Almost every step inside an automation is routed one step at a time, and that routing takes precedence over the head’s saved model. Customer-facing drafting goes to the strongest model, structured classification to the middle one, and mechanical work — summarising, extracting, translating — to the fastest. That is a deliberate cost choice and worth knowing about: mechanical steps run on a cheaper model on purpose. There is no screen for overriding that routing step by step.

One kind of step is the exception and still follows the dropdown. We are not going to pretend that is a feature — it is an inconsistency we know about and are fixing, and it is the reason this page will not tell you the dropdown controls your automations.

So the honest summary is that you can record a per-head model, but for almost every piece of work the model is decided by the routing above. If a specific head needs to be pinned to one model, ask us rather than relying on the dropdown alone.

What the model provider does with the text your team sends it is a data-processing question rather than a settings one, and this page is not the place to read an answer into. Ask us directly and we will answer it properly.