The wire is the grant

Abstract

Automation tools make two tempting promises: anyone can wire systems together, and now a model can do some of the wiring for you. There is a less glamorous question underneath both. Who granted what to whom, and can a reviewer tell by looking?

I built an internal canvas where agency teams compose agentic workflows by dropping nodes onto a board and connecting them. The wire is the grant. An agent can use exactly the skills and tools wired into it, so its permissions are part of the graph rather than hidden in a settings panel. The same validation rejects cycles and illegal edges whether a person, the embedded assistant or an external agent over the Model Context Protocol makes the edit.

1. Introduction

Every organisation collects work that sits awkwardly between a person and a program. Someone assembles a weekly report from three systems, checks packaging copy against the brand rules or turns a transcript into a tracker. Traditional automation handles the predictable steps. Language models are useful in the messy bit in the middle.

This canvas is for that middle ground. It runs on durable backend agents and a multi-provider model gateway, with each flow stored as a directed acyclic graph (DAG). Text, image and file inputs can feed model nodes. Agent nodes run tool loops, scripts execute inside sandboxed micro-VMs, and connectors call external APIs. Output nodes render the result or write it into a document or spreadsheet. A flow can run on demand, on a schedule, from a webhook or through an external agent using the Model Context Protocol.

The nodes themselves will be familiar to anyone who has used a workflow tool. The interesting decisions sit at the boundaries: what the canvas refuses, when it refuses it and how it behaves when the platform underneath fails silently.

The two decisions worth keeping

1. An agent's grants are its incoming wires. A flow has no side channel for capabilities that are invisible on the board.
2. Every editor goes through the same validation boundary. Illegal edges, cycles and unknown models are refused before anyone can save a broken flow.

2. The node taxonomy

A flow uses a small vocabulary. Trigger nodes start it unattended, by webhook or cron. Input nodes carry a prompt fragment, brand rules, an image or a document. A model node makes one tool-free call to any model in the gateway catalogue, across seven modalities. An agent node runs a durable tool loop, with skill and MCP server nodes wired into its capabilities port. Scripts run inside sandboxed micro-VMs with no network access unless a domain is explicitly allowed. Connectors call APIs through managed authentication where available and refuse private addresses outright. Output nodes render the result or write it into a document or spreadsheet, creating, replacing or appending as configured.

I kept the taxonomy small. Every extra node makes future flows harder to read, particularly for the people this is built for, who may never open a code editor.

3. The wire is the grant

An agent's capabilities are exactly the skill and tool nodes wired into its capabilities port. One skill node grants one skill, so two skills require two wires. If several agents share a skill bundle, the board shows that too. There is no configuration panel where an agent can quietly hold permissions the graph does not reveal.

A reviewer can therefore read permissions and logic in the same place. New agent nodes begin with no capabilities, and each grant leaves a visible artefact. Because the grant belongs to the graph, the canvas, assistant and MCP clients all change permissions through the same validated operations. The flow's history is also the history of its grants.

The cost is verbosity for capability-heavy agents, and the system accepts it. A board with many wires is an accurate picture of a complicated delegation. Hiding the wires would simplify the picture without simplifying the delegation.

4. The validation boundary

If one editor can save an unrunnable graph, somebody eventually will. All three editors therefore use the same validation boundary. The system refuses illegal edges and unknown models outright. It also refuses cycles with a plain sentence, since a topological sort cannot give them an execution order.

The MCP interface makes this fairly concrete. External agents edit flows through patch operations, each checked against the flow's rules and applied on its own. The response lists what landed and what was refused, and callers must read that list before assuming success. An illegal request gets a refusal the agent can reason about without damaging the flow.

Changes save immediately, so the only undo is another edit. That is simply how shared mutable state works here. The layout engine follows the same rule in miniature: settling passes stop at the node count. A DAG converges within that bound, so anything still moving points to a cycle that validation should have caught upstream.

5. Related work

Mainstream automation platforms and self-hosted node graph tools established the canvas pattern used here. Agent framework graph libraries tend to be code-first and developer-operated; this canvas belongs to the people who own the workflow. Its capability model is a visual version of an old security idea: authority should be explicit and transferable, not ambient. Putting that model inside the editor means the programming model and the security model use the same picture. The durable agent substrate and multi-provider gateway are adopted components, consistent with the composition approach in the first piece in this series.

6. Limitations

This is an internal tool, so the evidence is adoption within one agency, not a benchmark. Its capability model controls what an agent can reach. It cannot make a badly prompted agent produce good work, and those guardrails belong in the harness layer.

Script sandboxing and private-address refusal limit the blast radius of the sharpest nodes. Connector nodes still call external APIs with real credentials, and this system trusts the managed connector layer rather than verifying it. Long-running coordination between several agents is outside the scope: one flow has one graph and one run.

7. Conclusion

The useful automations are often owned by people who will never write the code for them. Giving those people agents without any structure would recreate the sprawl that the previous piece's harness is meant to prevent. Both systems put their rules into software, keep grants visible and reject invalid states before a run begins. The graph holds the program and its permission record together, so a reviewer has one thing to read.

References

• Dennis, J. B. and Van Horn, E. C. "Programming Semantics for Multiprogrammed Computations" (1966), the origin of capability-based addressing that the grants-as-wires model restates visually.
• Miller, M. S. "Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control" (2006), on capabilities as explicit, transferable authority.
• The Model Context Protocol specification. modelcontextprotocol.io
• "Prose Is Advisory, Guardrails Are Mechanical", the first paper in this series, for the harness layer this canvas hands its governance questions to.

Appendix: the system at a glance