Most “AI ops” demos skip the boring part: who is allowed to start work.

You can spin up desks, route asks, and ship patches all day. Without a human gate before execution, you do not have an operating system — you have unsupervised labor with a chat UI. Cockpit’s approve-before-start (backlog → todo promote) is that gate. The desks and agents are the machinery. The gate is the product.

This is not a hypothetical architecture slide. On 2026-09-04, our Sales Director desk asked for two engineering outcomes. Joe promoted both. Both closed the same day. The receipts are public pull requests — not vibes.

What “approve-before-start” actually means

In Cockpit, a task can sit in backlog without burning a runtime. Promotion to todo is an explicit human approval. Only then does desk pickup claim the work item, stamp a live session, and run.

That split matters for three reasons:

1. Cross-desk asks stay asks until a human says go. Sales can request product or platform work without silently consuming eng capacity.
2. Promotes are auditable. Each start has an approval trail and a completion record — who asked, who greenlit, what shipped.
3. Agents stay bounded. The interesting autonomy is after the gate: claim, execute, open a PR, request close. Not inventing work from a Slack vibe.

If you only remember one sentence: desks propose; humans start; agents finish inside the lease.

Same day, two promotes, two ships

1. Deal scorecard as first-class CRM data

Ask (Sales Director): LeverEdge / ARMBAR deal scoring was being forced into side channels. The CRM deal APIs did not expose a real scorecard or narrative fields — so agents were tempted to stash load-bearing scores in disposable agent state.

Promote: Joe approved the backlog→todo promote on 2026-09-04.

Ship: First-class deal fields for a six-pillar scorecard (with per-pillar justifications and total), plus deal summary, dated detail log, product offering, strategic questions, and next steps — readable and writable through MCP and the Cockpit UI. Closed the same day.

Receipt: cb-wiki-2 PR #823 (merged 2026-09-04). Internal task T0000374.

2. Campaign membership that remembers who owns it

Ask (Sales Director): Tagging accounts and deals into a campaign from MCP failed with a hard ownership error. The insert path never stamped owner_user_id from the authenticated MCP user, so the database correctly refused the row.

Promote: Joe approved the backlog→todo promote on 2026-09-04.

Ship: campaign_member_add now stamps ownership from the MCP auth user (with a safe fallback to the campaign owner when auth is null). Sales can tag members without hand-editing rows.

Receipt: cb-wiki-2 PR #827 (merged 2026-09-04). Internal task T0000382. Note: the task’s link graph recorded the promote approvals; the PR URL was confirmed from the merged repo history for this draft.

The pattern, not the tickets

Strip the product names and you still have the same loop:

Step	Who	What happens
Request	Desk / human	Write a concrete outcome into backlog
Gate	Human (Joe)	Promote backlog → todo
Execute	Bound agent runtime	Claim work item, stamp session, ship
Close	Agent + human	PR + close request; human ack when required

Optional supporting ships the same day underscore the same spine: briefs rematching calendar occurrences that enter the window (PR #829, T0000410), and the webhook path that wakes a desk when a promote lands (T0000373). Architecture detail belongs in the wiki; the marketable truth is simpler — promote is a real event, not a status emoji.

Why this is the product (and not “more agents”)

Buyers do not need another demo of an agent that can open a PR. They need an answer to: who decides this starts, and can I prove it?

Approve-before-start is how CloudBeast runs its own house:

• Sales Director can pull eng without a hallway interrupt — the ask is a task.
• Joe keeps start authority without becoming the person who implements every fix.
• Agent runtimes get a lease, a session URL, and a close path — not an infinite mandate.

That is the same design we sell into ops-heavy teams: formalize work, put a human on the start gate, let automation run inside the rails. Multi-agent only pays off when the gate is real.

Draft status

This post is a draft held for Joe’s publish decision (task T0000441). It uses only verified, completed work from 2026-09-04. No campaign identifiers or calendar event IDs appear in the public copy.

If you want the same operating pattern in your stack — desks, promotes, and agents that ship under a human start gate — book a discovery call at cloudbeast.io/schedule.