career bridge
The boundary
Write the half of the spec nobody writes: what the agent must never do, specific enough that an engineer could implement the refusal.
You know which jobs are real and you can name your gaps. Now take the thing everyone skips. Most agent projects begin with a capability, what it could do, and never write down the other half, what it must never do. That other half is where this role actually lives.
What you do
Pick one real workflow and write the spec nobody writes. Choose something with consequences you understand: refunds, scheduling, expense approval, ticket triage, order changes. Not a toy. Write in plain language the task the agent owns end to end, the exact inputs it may read, the exact actions it may take, and the actions it must never take under any circumstance. Be specific enough that an engineer could implement the refusal. Do not do anything harmful is not a boundary. Never issue a refund above a stated amount without a named human approving it, is. Then write the boundary cases, the ones that will genuinely happen: the customer who asks twice, the request that is reasonable but outside scope, the instruction that arrives inside the data rather than from the user. Say what the agent does in each. Now take the whole thing to somebody who does that job today and ask them where you are wrong. You will be wrong in at least three places, and those three are the entire value of the exercise. Rewrite it. Date both versions so the change is visible to a reader later.
Done when
- One workflow is specified end to end: the task owned, the inputs readable, the actions permitted.
- A written never-do list exists, each line specific enough to become a check in code.
- At least six boundary cases are named, each with the agent's defined response.
- Someone who does that job today has reviewed it and disagreed with you somewhere.
- A second version exists and differs from the first in ways you can point at.
What you end up with
An agent scope document with a named never-do list, dated versions, and the review comments that changed it.
If you get stuck
The usual failure is writing a boundary so vague it cannot be checked, which feels responsible and protects nobody. If a line could not become an assertion in code, it is a sentiment. The other failure is writing the whole document alone, at which point it is fiction about a job you have not done. The review by someone who does it is not a formality here. It is the step where the document stops being your guess.