WHITEBOARD / WHITEBOARD FIELDCRAFT
Whiteboard fieldcraft
The board is what you’re delivering. Each of the four boards in this guide can be drawn in under five minutes, and each one ends with a single rule written at the bottom that the other person can take away.
Ask, draw, validate
- Ask three questions before you pick up a marker. What runs today, and where? Who or what needs access: humans, agents, CI? What has to stay secret?
- Draw from the left. Clients start on the left and exe.dev sits on the right, so arrows flow the way a request does.
- Say what you’re drawing as you draw it. Every box gets a one-line spoken sentence. The Say: lines on each board are written for that.
- Validate at every step. After each big arrow, ask “Is that right for you?” and correct the board on the spot.
- Write the rule at the bottom, for example “Secrets live on the network, not on the VM.”
Shared shapes and colors
| Shape | Means |
|---|---|
| Rounded rectangle | exe.dev edge / control plane (exe.dev, the lobby) |
| Square | A VM (write its name and size) |
| Dashed rectangle | A pool (write vCPU / GiB and region) |
| Cylinder | Disk or external data |
| Green arrow | Allowed path (HTTPS through the proxy, integration calls) |
| Red arrow | Blocked path (direct secret access, private network that does not exist) |
The four boards
- Request path. How a browser or SSH session reaches a VM with no public IP.
- Agent sandbox. A coding agent with credentials it can’t steal.
- Team pools. How a team shares capacity and what it costs.
- Enterprise hosts. Single-tenant, BYOC and the SLA.
Sources for the boards
Every claim on these boards links to an exe.dev docs page, listed under each board. When you’re not sure, stop drawing and open the page: https://exe.dev/docs.md.