The Grid Briefing demo shows the blumi grid working end‐to‐end in real time: you give a topic, the fleet researches facets in parallel across machines, and the origin machine assembles them into one polished markdown briefing. (blumi is a local-first, provider-agnostic agentic coding companion; the grid is several machines sharing one secret that run as a single fleet.)

TL;DR: On the origin machine, paste the test prompt with your <TOPIC>. blumi splits the topic into 6 facets and fires 6 parallel delegate sub‐agents in one batch; the local cap is 4, so the extra 2 overflow to grid peers. Each peer returns text, the origin writes ./grid-briefing.md, and grid_status reports which facets ran locally vs. remotely plus grid‐wide token usage.

Key facts

• The demo needs a live grid: ≥1 peer online sharing the same grid.secret, and a provider configured on every node.
• The local concurrency cap is 4 parallel delegate sub‐agents; anything beyond that overflows to grid peers.
• No shared filesystem is assumed: each peer produces text only, and the origin machine writes the final file.
• Success = ./grid-briefing.md on the origin with all 6 facets, plus >1 node online and a non‐zero remote task/token count in grid_status.

It exercises the real mechanism: parallel delegate sub‐agents → the local cap of 4 → overflow to grid peers → results returned to the origin → assembled into a single artifact. No shared‐filesystem assumptions: each peer produces text, the origin writes the final file.

• A grid that's up (see Grid): ≥1 peer online with the same grid.secret. Verify: blugo → Control Center → Grid shows the peer online, or GET /api/grid/metrics.
• A provider configured on every node (each peer runs real turns).

Paste this into the chat (blugo, the web UI, or blumi tui) on the origin machine — the one your phone connects to. Replace <TOPIC>:

You are the orchestrator on a blumi grid. Produce a polished research briefing on
"<TOPIC>" by working in parallel across the grid.
1. Break the topic into 6 distinct facets (e.g. background, key players, current
 state, risks, opportunities, what's next).
2. For EACH facet, in a SINGLE batch, call the `delegate` tool (agent_type
 "general-purpose") with a focused prompt asking for a tight ~150-word,
 self-contained write-up of that facet (prose only, no tools). Issue all 6
 delegations together so they run concurrently — the local cap is 4, so the
 extras run on grid peers.
3. When the sub-agents return, assemble the write-ups into one clean markdown
 briefing: a title, a 3-bullet executive summary, then one section per facet.
 Write it to ./grid-briefing.md.
4. Call grid_status and tell me, in 2 lines, which facets ran locally vs. on a
 remote peer, plus grid-wide token usage.

Good topics: "the James Webb Space Telescope's biggest discoveries", "WebAssembly outside the browser", "how RAFT consensus works", your product's competitive landscape, etc.

• TUI: the right‐pane active agents list — overflowed sub‐agents show a ⟶ remote marker; /grid shows task distribution.
• blugo: Control Center → Grid — peers online, per‐node tasks + tokens, grid‐wide totals (tap ⟳ to refresh).
• In chat: just ask "grid status" anytime — the agent calls the grid_status tool and summarizes peers, health, tasks (local vs remote), and token usage.

• ./grid-briefing.md is written on the origin with all 6 facets assembled.
• grid_status / the Grid view shows >1 node online and a non‐zero remote task / token count — i.e. some facets were genuinely produced by a peer and assembled back on the origin.

• More fan‐out: ask for 10 facets to push more work onto peers.
• Autonomous: add the facets as board tasks (blumi task add ...) and run the loop in grid mode to round‐robin them across peers (note: the loop distributes execution; the briefing assembly above is the part that collects + composes results on the origin).

It splits a topic into 6 facets, researches them in parallel across the blumi grid, and assembles the results into a single markdown briefing (./grid-briefing.md) on the origin machine. It is a small end‐to‐end demo of blumi, a provider-agnostic agentic coding companion, running work across a fleet of machines.

You need a grid that's up — at least one peer online sharing the same grid.secret — and a provider configured on every node, because each peer runs real turns. Verify peers via blugo → Control Center → Grid or GET /api/grid/metrics.

The orchestrator issues all 6 delegate sub‐agents in a single batch so they run concurrently. The local concurrency cap is 4, so the 2 extra delegations overflow to grid peers; each peer returns text and the origin assembles the final file.

Check that ./grid-briefing.md was written on the origin with all 6 facets, and that grid_status (or the Grid view) shows >1 node online with a non‐zero remote task/token count — proof that some facets were produced by a peer and composed back on the origin.

In the TUI, the right‐pane active agents list marks overflowed sub‐agents with ⟶ remote, and /grid shows task distribution. In blugo, Control Center → Grid shows peers, per‐node tasks and tokens, and grid‐wide totals. In chat, just ask "grid status" and the agent calls the grid_status tool.