Declare the inputs before the run

Tags: agents, permissions, consent

An agent starts. Forty seconds later it stops: I need access to your calendar. The user now holds a half-finished task, a permission decision nobody mentioned, and no way to know whether granting it finishes the job or buys the next question.

Mid-run is the worst moment to ask

Three things are wrong with it, and they compound.

Sunk cost makes the consent unreal. The user has already committed attention and time. Agreeing costs a click; refusing costs the whole run. That is not a decision, it is a toll — and a product that collects its permissions this way will find that people grant everything and resent it.

They cannot weigh the request, because they cannot see the job. A scope makes sense relative to what it is for. Asked in isolation, mid-flight, "write access to your repository" is unanswerable: write what, where, how much of it.

Nothing says whether this is the last one. The user grants it, the agent runs nine more seconds, and asks again. By the third prompt they have learned that this thing negotiates in instalments, which is the point at which they stop starting runs at all.

Declare what you know, and name the class of what you don't

The honest objection to this pattern is that agents discover requirements dynamically, and sometimes they genuinely do. The answer is not to give up on declaring; it is to declare at the grain you actually know. "May read any file in this repository" is a real commitment that covers a thousand unpredictable specifics, and it is far more useful than nine accurate prompts.

The bottom branch is the one worth sitting with. If mid-run escalation is the normal path rather than the exception, the problem is not how you ask — it is that nobody has worked out what the agent needs, and the user is being made to do that work one interruption at a time.

The declaration is a scoping conversation

This is the part usually missed, and it is the argument that makes the pattern worth the screen it costs.

A user shown "I will need write access to your repository" before anything starts can say: no, read-only, and show me the diff. That is a better outcome for everybody — a narrower grant, an agent that still does useful work, and a person who chose the shape of the risk.

The same user, asked the same question thirty seconds in, has one sensible move, which is yes. The declaration is not a notice. It is the only moment at which the user has any leverage.

Grounded in

The Osage Nation member portal puts a Documents You'll Need panel ahead of its guided application wizard, listing what to gather before anybody begins — so people are not sent back to the start partway through an application they had already half-completed.

An agent's prerequisites are scopes, tools and data rather than birth certificates and proof of address. The structure is identical, and so is the cost of getting it wrong: the expensive failure is not the asking, it is the restart.

Anti-patterns

• The mid-run prompt as the normal path. Consent collected at the moment refusal is most expensive.
• Asking for broad scope because it might be needed. Request what this run needs. A permanent grant obtained under time pressure is the worst of both.
• A wall of permissions nobody reads. Declaring is not dumping. Three lines someone reads beats a manifest they scroll past.
• No indication of whether more is coming. "One more thing" twice is enough to end the relationship.
• Re-asking every run for a standing grant. This trains dismissal, which erodes the prompts that genuinely needed attention — see undo over confirm on what repeated dialogs do to the ones that matter.
• Declaring what it needs but not what it will change. Read and write are different consents and a single list flattens them.

The smallest version worth building

Before the run, three lines: what it will read, what it may change, and which tools it will use. Plus one control that narrows the middle line.

That is a panel and a checkbox, and it converts the most coerced interaction in an agent product into the one place the user actually gets a say.

Related patterns

• Work without being asked — an agent acting unprompted has no run to declare ahead of, which is why the standing grant has to be explicit instead.
• Undo over confirm — what to do about the actions inside the run once it has started.
• Answer within the boundary, and show its shape — the consequence of a narrower grant, and how to render it honestly.