AI Agent Plan Bound Template: Set All 13 Bounds Before Any Agent Runs

When a team sketches an AI-mediated workflow, the difference between a draft and a deployable plan is the statement of bounds. Without a concrete, machine-readable set of constraints, an agent can roam free, consume resources, and — in the worst cases — snap the budget out of control. One developer documented a runaway agent loop burning over $700 in 72 hours with no budget controls: a workload that had a prompt, a model, and no stated limits at all.

For venture studios and AI-native founders juggling many small teams, the temptation is to throw together ad-hoc scripts, bullet-point tables, or informal comments. A bound-driven blueprint is a single source of truth: every unit of work is self-contained, immutable once it starts, and subject to real-time cost tracking. That blueprint is an AI agent plan bound template.

What a plan bound is (and is not)¶

A plan bound is the single unit that governance operates on. Think of it as a contract that describes the exact shape of a piece of work. If a unit of work cannot be expressed in this form — if any required bound is missing — it is not a plan, and it does not run.

A plan bound is: a machine-parseable record with 13 required top-level fields; immutable once execution starts; scoped to one execution window and one cost ceiling; validated completely at the moment of creation, with the validation itself recorded.

A plan bound is not: a loose set of comments in a notebook; an editable template that changes in place mid-run; a reference to a broader “workflow” with no clear limits; or a model configuration that leaves no traceable evidence behind.

The 13 bounds, one by one¶

1. plan_id — pattern plan_[a-z0-9-]{8,64}, unique per plan, never reused.
2. owner_identity — format owner:[name]. Must exist in the identity registry.
3. agent_identity — format agent:[OWNER]/[NAME]. Must exist in the identity registry.
4. workload — a human-readable description of the work, in one statement.
5. data_class — one of public, internal, confidential, restricted. Record the highest class the workload touches.
6. resources — model_allowlist (at least one model) and max_parallel_calls (an integer of 1 or more).
7. time_window — start and end; the end must be after the start.
8. location — where the compute may run, e.g. us-east-1.
9. egress — an allowed_domains list and a max_mb transfer cap.
10. storage — a scope the agent may write to and a max_mb cap.
11. cost_ceiling — an amount greater than zero and a 3-letter ISO currency code.
12. expiry — a timestamp at or after the time window’s end, and in the future at issuance.
13. grant_refs — a non-empty list; every referenced grant must exist, be unexpired, and be issued to the plan’s agent_identity. A grant held by a different agent does not count.

The AI agent plan bound template¶

Copy this into your repo or wiki, replace every bracket, and validate at creation. A plan with an unfilled bracket is a draft, not a plan.

{
  "plan_id": "plan_[UNIQUE-ID]",
  "owner_identity": "owner:[OWNER]",
  "agent_identity": "agent:[OWNER]/[NAME]",
  "workload": "[ONE-STATEMENT DESCRIPTION OF THE WORK]",
  "data_class": "[public | internal | confidential | restricted]",
  "resources": {
    "model_allowlist": ["[MODEL]"],
    "max_parallel_calls": [N]
  },
  "time_window": { "start": "[ISO-8601 UTC]", "end": "[ISO-8601 UTC]" },
  "location": "[WHERE COMPUTE MAY RUN]",
  "egress": { "allowed_domains": ["[DOMAIN]"], "max_mb": [N] },
  "storage": { "scope": "[WHERE ARTIFACTS MAY BE WRITTEN]", "max_mb": [N] },
  "cost_ceiling": { "amount": [AMOUNT], "currency": "[USD]" },
  "expiry": "[ISO-8601 UTC]",
  "grant_refs": ["[GRANT-ID]"]
}

Validate plans at the boundary — at creation, against the schema — and reject what does not validate. That rejection is itself an audit row: a refused plan is evidence that the gate works, not an error to hide.

Worked example: a nightly pricing scrape, bounded¶

Here is the template filled in for one small, real-shaped job (illustrative values from the playbook):

• plan_id: plan_9f2c-7a1b-research-01 — unique to this plan; if any bound changes, this ID is retired and a new one is issued.
• owner_identity: owner:maya — the human accountable for the run.
• agent_identity: agent:maya/researcher — the specific actor doing the work, recorded in the identity registry.
• workload: “Nightly competitor pricing scrape and summary” — one statement, no hidden second job.
• data_class: internal — the highest class this workload touches.
• resources: model_allowlist ["claude-haiku-4-5", "gpt-4o-mini"], max_parallel_calls 4 — the agent cannot reach for a bigger model or fan out wider than this.
• time_window: 2026-10-01T02:00:00Z to 2026-10-01T04:00:00Z — two hours, then the window closes.
• location: us-east-1 — where the compute may run.
• egress: allowed_domains ["competitor-a.com", "competitor-b.com"], max_mb 50 — the agent can read those two sites and nothing else, and cannot pull more than 50 MB doing it.
• storage: scope s3://acme-agent-artifacts/research/, max_mb 500 — artifacts land in one named place, capped.
• cost_ceiling: 25.00 USD — counted in real time against this plan, never against a shared account pool.
• expiry: 2026-10-02T02:00:00Z — at or after the window’s end; after this, the plan is dead even if it never ran.
• grant_refs: ["grant_2026-09-30_webread", "grant_2026-09-30_s3write"] — the two grants this plan relies on, both issued to this agent identity and unexpired.

Notice what the filled template buys you: before the run starts, a reviewer can answer — in one reading — who owns it, who acts, what it may touch, where it may go, how much it may move, and the most it may cost. Plans are immutable once execution starts, so none of those answers can quietly change mid-run.

The validation rules that do the real work¶

A template only governs if the checks behind it are enforced. These are the rules that matter:

• All 13 fields are required. A plan missing any bound is rejected — if you can’t state the bounds, you don’t have a plan.
• Cost ceiling sanity: the amount must be greater than zero and the currency a 3-letter ISO 4217 code. Spend is counted against the ceiling in real time; the owner is alerted at the thresholds your policy sets (for example 50% and 80%).
• Fail closed at the ceiling: when the ceiling is reached, the action is blocked and recorded as blocked — never retried automatically. Raising a ceiling is a hard-gated action: it requires human approval and a recorded reason.
• Time sanity: the window’s end must be after its start, and the expiry must be at or after the window’s end and in the future at issuance.
• Grant reality: every grant in grant_refs must exist, be unexpired, and be issued to the plan’s agent_identity — checked at validation, not assumed.
• Identity reality: owner_identity and agent_identity must match the identity policy’s formats and exist in the identity registry.
• Immutability: a changed bound means a new plan_id — never an edit in place.

What breaks without bounds¶

Gartner forecasts that 40% of enterprise applications will incorporate task-specific AI agents by the end of 2026, up from less than 5% in 2025. As the number of running agents climbs, missing bounds stop being untidiness and start being incidents:

• Runaway cost. Without a per-plan ceiling that fails closed, a loop runs until a human notices the bill — the documented $700-in-72-hours case is what “noticing” looks like.
• Unowned work. Without owner and agent identities, an anomalous run belongs to “the system,” and nobody is accountable for stopping or fixing it.
• Silent scope creep. Without egress and storage bounds, an agent written to read two sites can end up reading twenty, and writing artifacts nobody can find or delete.
• One plan drains everyone. A ceiling set per account instead of per plan lets a single bad workload consume the whole team’s budget headroom.

Before you call it a plan¶

• All 13 top-level fields are present, and every bracket in the template has been replaced with a real value.
• plan_id matches the pattern, is unique, and has never been used by another plan.
• Both identities exist in the identity registry, and the agent identity is the one the grants were issued to.
• data_class records the highest class the workload touches — not the class you wish it touched.
• The time window’s end is after its start, and the expiry is at or after the window’s end and still in the future.
• The cost ceiling is per plan, greater than zero, and reaching it blocks the action with a recorded reason — no automatic retry.
• Every grant in grant_refs exists and is unexpired today, not on the day the template was drafted.
• A test plan with one bound deleted is rejected at validation, and the rejection writes an audit row.

If any line fails, you do not have a plan yet — you have an intention. The Governed Agent Mesh Playbook — Studio Edition gives you the full system behind this template: the complete PlanBound and audit-row JSON schemas, the six policy templates it plugs into, the risk-tier worksheet, and the 14-day rollout that installs identity, grants, spend limits, and approval gates in order. Get the Studio Edition at https://ghostcorpnet.gumroad.com/l/hdigmr.