Why every ClaudeTag setup is the same four-part contract you should be writing for every agent.
You already delegate to a fleet of Claude agents daily. ClaudeTag's whole design is one idea made explicit, and it's the idea worth stealing: delegation is a contract with four clauses.
When an admin sets up a ClaudeTag channel, they fill in exactly four things.Field guide §6 Read them as a template for any agent you brief:
| Clause | In ClaudeTag | In your subagent prompt |
|---|---|---|
| Objective | The @Claude task you tag in | The one-line goal at the top of the prompt |
| Tools | Access bundle: credentials, repo grants, plugins | The tool allowlist you give the agent |
| Instructions | Access bundle's instructions field (per channel) | The system prompt / standing rules |
| Budget | Monthly spend cap (over-cap = declined, not partial) | Effort/model tier + "don't escalate without cause" |
The insight: an Access bundle's instructions field is just a per-channel system prompt, and its credential grants are the same least-privilege scoping your routing policy already demands ("never delegate risk-control to coder directly"). ClaudeTag didn't invent the contract — it gave it a UI.
Recall, don't peek — retrieval is what makes it stick.
Which clause most directly maps to a subagent's system prompt?
The Access bundle's instructions are the per-channel standing rules Claude follows — the system prompt. Tools/repos map to the allowlist; the spend cap maps to budget. (Field guide §6)
A ClaudeTag task exceeds its channel spend cap. What happens?
Over-cap work is declined entirely, not partially executed — a clean failure, not a half-finished one. That's the safe default for risk-adjacent automation. (Field guide §6)
You can now state the delegation contract from memory: objective, tools, instructions, budget. That's a checklist you can run against any agent prompt you write today.