Why entities must not share a runtime
An agency running work for two clients through one agent environment mixes their credentials, their documents, and their histories. One wrong grounding pull and Client A's strategy appears in Client B's draft. One shared git identity and commits land under the wrong name.
The same applies inside one company: a regulated project, an M&A workstream, or an unreleased product line should not share context with general operations.
Each Box carries its own full stack
Every dpanel Box has its own vault (keys, tokens, custom variables), its own connections (this client's monday.com board, this client's Notion, this repo's git identity), its own grounding documents, its own AI team, its own workflow board, and its own budget guardrails.
Workflows forked from the marketplace declare their requirements explicitly — the fork screen shows green checks for every vault variable and connection the workflow needs, per Box, so an operator always knows exactly what a given entity's team can reach.
Operating many entities from one panel
The operator manages all Boxes from one panel — one login, separate blast radii. Plans include multiple hosted Boxes, and Box add-ons extend the fleet as the client list grows; each new client is a fork of a proven workflow into a fresh Box with that client's own requirements filled in.
Per-task costs on the workflow board are visible per Box, which makes client-level cost accounting straightforward — every step shows its actual model spend as it runs.
Next step
Turn this concept into a visible workflow with teams, approvals, grounding, and handoff.
Browse ready workflows