ghostcorpnet

Home · Articles

If You Can't State Your Agent's 9 Bounds, You Don't Have a Plan

· · 3 min read

Last reviewed

Updated

On this page

A real plan has nine explicit limits — workload, data class, resources, time, location, egress, storage, cost, and expiry. If you cannot state these for your agent, you are not running an agent. You are hoping it will not break things. The nine bounds are the difference between a plan and a wish, and most agent deployments in the wild cannot name more than two.

The test is disarmingly simple: describe your agent's limits the way you would describe a contractor's work order. What may it do, what may it touch, how long may it run, where may it send things, and what is the maximum damage if everything goes wrong? If any of those answers is "I'm not sure," you have a wish.

A bounded agent, in one sentence

"My agent can only process public-domain text under 10k tokens, runs for 30 seconds max on my $5/month VM, and can't send anything outside my local network — then it self-deletes its memory and logs."

That sentence is a plan. It names the workload (processing public-domain text), the data class (public-domain, under 10k tokens), the resources (a $5/month VM), the time bound (30 seconds), the egress bound (local network only), the storage bound (memory self-deletes, logs retained). Cost and location are implied by the VM. Every bound is stated, which means every bound is checkable — and a checkable bound is one you can enforce.

Why each bound matters

Each bound closes a specific failure mode. Workload bounds what the agent may do — without it, task creep turns a summarizer into a code executor. Data class bounds what it may touch — without it, public-text processing drifts into private data. Resources and time bound compute — without them, a loop becomes a billing event. Location bounds where it runs — without it, data residency is a hope. Egress bounds where it may send things — without it, exfiltration is one clever prompt away. Storage bounds what persists — without it, the agent accumulates state you never authorized. Cost bounds the money — without it, you discover the bill later. Expiry bounds how long any of the permissions last — without it, every grant is a standing privilege.

No bounds, no control

The pattern in incident after incident is the same: the agent did something its operator never explicitly forbade, because the operator never explicitly bounded anything. Unbounded agents do not need to be malicious to cause damage; they only need to be persistent. A wish says "it should be fine." A plan says "it cannot exceed these nine limits, and here is how each one is enforced."

The takeaway

Write down your agent's nine bounds before you deploy: workload, data class, resources, time, location, egress, storage, cost, expiry. If you cannot state one, the agent should not run until you can. The free, MIT-licensed Governed Agent Mesh Playbook has a checklist for exactly this: https://ghostcorpnet.com/playbook.md — because a wish is not a plan, and your agents should be running on plans.

Put this into practice

The Governed Agent Mesh Playbook — Studio Edition ($29) gives you the full system: tiering, approvals, spend controls, and incident response, ready to run.

Get the Studio Edition — $29

Or browse the full catalog of 63 products →