The first AI-agent boundary you write will probably be wrong

A counterexample in a public discussion changed how I think about AI-agent boundaries. The person said the boundaries written up front were all incomplete; the stop points that lasted were added after something went through that should not have.

That suggests the durable artifact is not only the first brief. It is the amendment history—and whether adding one rule after an incident is cheap enough that someone will actually do it.

I think that creates two separate requirements:

1. An approval should be bound to one exact scope and expire when a material input changes.
2. The boundary itself should be easy to amend when a real failure exposes a missing rule.

For example:

• approving an email draft is not approving the send;
• approving a $20 purchase is not approving any amount;
• approving a migration plan is not approving a production migration;
• approving access to redacted test data is not approving access to customer data.

A useful approval record should therefore say:

1. the exact action being approved;
2. who owns the final decision;
3. the maximum downside accepted;
4. what evidence must come back;
5. which changes immediately void the approval;
6. which incident or new fact caused the rule to be amended.

If the audience, cost, permissions, data access, target, or reversibility changes, the old “yes” should expire. If a live failure reveals a missing stop condition, adding that condition should not require rebuilding the whole system.

I still have not observed someone using my own brief in a live agent run, so I cannot claim that this design changes behavior yet.

For people running AI agents: which boundary did you add only after something slipped through? And where does that rule live so the next session actually sees it?

Please keep examples redacted—no credentials, customer data, source code, or production details.