Commander
Commander is BattleGrid’s conversational control surface. You speak in plain language; it reads and writes the platform through the same capability catalogue external tools use over MCP.
It does not replace the Strategy Builder or the agent forms. When you need every dial laid out — metrics, conditions, signal rules, levels, exits, brain, risk — author there. Use Commander when you want to move faster in words, then refine in those surfaces.
The market is a battlefield. Commander is how you brief the grid without walking every panel first.
What it is for
| Intent | What Commander does |
|---|---|
| Strategies | Draft / tighten a playbook, then compile → review → apply |
| Agents | Commission, rebind, check risk rails, halt / resume |
| Deploy | Put agents on Radar or into Arena |
| Market & account | Regime, leaders, crowding, balance, slots, coverage |
| Trades | Qualification reads, open protections, debriefs, pending approvals |
Create still ≠ deploy. Commissioning an agent does not put it on duty; Radar / Arena / the trade terminal are separate decisions.
Where it runs
One engine, several mounts:
| Surface | Role |
|---|---|
| Commander (main) | Full conversations and the lander starters |
| Strategy host | Dock beside the Strategy Builder — bound to the strategy you are editing |
| Agent host | Lane beside an agent’s trade work — bound to that agent |
A host conversation stays latched to that resource for the session. Host context shapes what Commander may safely change (for example, agent-host conversations refuse strategy-mutating writes that would surprise the builder). Other channels (where enabled) drive the same run runtime — same tools, same guards — with different identity plumbing.
How a turn works
- You send an ask (or pick a starter).
- Commander activates skills as needed — each skill widens the active tool families for that conversation.
- It calls platform tools (reads first; writes only when the ask requires them).
- Answers land as shaped cards (plans, reviews, confirmations) plus prose — not raw tool JSON.
- Spending or standing-authority actions ask for explicit confirmation before they commit.
Core families (account, market, agent discovery, and related reads) are always available. Heavier families — strategy studio, Radar wager, live trade control, and so on — unlock when a skill that needs them activates. That gating keeps ordinary chats cheap without hiding power once you ask for it.
Skills (intent packs)
Skills are playbooks Commander loads mid-conversation. Starters and freeform asks cue them. Common packs include:
| Skill (examples) | Typical work |
|---|---|
| strategy-authoring / strategy-examples | Build, port, or tighten a playbook |
| agent-management | Commission, risk, bind |
| radar-deployment | On-duty policies, “why isn’t it firing?” |
| strategy-doctor | Why an agent is quiet / halted |
| market-analysis | Regime, leaders, crowding, levels |
| trade-analysis / trade-proposal | Positions, debriefs, find a setup |
You do not have to name a skill. Naming the outcome is enough; Commander activates what it needs.
Strategy changes: compile → apply
Strategy authoring through Commander follows a fixed contract (same as MCP):
- Compile a CREATE / UPDATE / RESTORE request into an approved plan + review context (column contracts, report preview, blast radius, revision diagnostics). Compilation does not mutate the live strategy; it parks a plan for apply.
- Review the plan — diffs, viability, bound-agent impact. Plan tokens expire after five minutes; recompile after expiry, catalog drift, revision drift, or a changed bound-agent fence.
- Apply only with the exact
planTokenand confirmation. The server re-derives dense scorecard / revision checks and rejects a mangled or stale token. There is no client-side rebuild of the plan body.
Focused one-rule edits and fork / archive / restore still use their own revision and confirm rules. Field guides: Strategies overview (identity, Briefing vs Policy, lifecycle) · Metrics · Conditions · Policy axes under Strategies.
Money and standing authority
Anything that moves funds, submits a wager, or grants standing autonomous authority (Radar policy upsert/delete, Arena deployment upsert/delete, halt/resume that changes whether capital can commit, close position, accept a pending entry, submit a grid) requires your confirmation in Commander — and, on MCP, the mcp:wager scope.
Reads, strategy configuration (non-financial), and agent setup that does not deploy capital stay on the read / configuration side. Details: MCP.
Limits that keep runs honest
Every run is bounded. When a bound hits, Commander stops visibly (a typed guard), never with a silent truncation:
| Guard (concept) | Meaning |
|---|---|
| Step cap | Too many tool steps in one run |
| Cost stop | Per-run spend ceiling |
| Op budget | Per-user daily tool-execution budget (resets 00:00 UTC) |
| Run / chunk timeout | Wall-clock or silence bound |
| Output limit | Output capped before a tool could run |
| Mutating tool interrupted | A write may have completed — do not blind-retry |
| User stopped | You pressed Stop — completed work still stands |
One active run per conversation. Credits must clear the floor before a stream opens.
Conversations
Transcripts persist. Soft-delete hides a conversation without erasing transcript or billing rows — the audit trail stays. Reloading a conversation replays original messages and tool results; prompt-side compaction does not rewrite stored history.
Commander vs the rest of the product
| Layer | Owns |
|---|---|
| Commander / MCP | Plain-language and programmatic control of the same catalogue |
| Strategies | The playbook (briefing + policy) |
| Agents | Brain, bind, risk, account slot |
| Radar / Arena / Terminal | Where that agent works |
Next: Prompt formula · MCP