Looking at this post’s structure through three elements makes it clearer:
- Action: what to do
- Condition: when, where, and under what conditions to do it
- Execution Policy: with what quality and constraints to do it
In the conventional execution structure, Action and Condition were communicated by the user, while Execution Policy was already handled by the Provider at the design stage. Users only needed to say “what and when” — the “how” (quality/constraints) was already baked into the product design.
But in newer forms of Agents — coding agents, document editors — Execution Policy now also has to be conveyed by the user at execution time.
The problem the Provider used to resolve at the design stage has come back in the form of the user’s instructions (prompts). As a result, user instructions are becoming increasingly broad and long.
Seen this way, a natural question follows:
How should the Agent complete the user’s incomplete and lengthy instructions before passing them to the AI?
How well this completion is done could become a key source of competitive advantage for Agents.
If this completion work is done ad hoc every time, it will lack consistency. So what seems to be needed, ultimately, is a shared representation between the user and the AI. At minimum, this representation needs to define what to look for, what procedure to use for interpretation, and how to resolve missing information.
What items should be included in this shared representation is likely to become an important design question going forward.
For a deeper discussion on this, the following post may be worth referencing.
Physical AI Safety: Ownership and Execution Boundaries
(In Physical AI, much of the Execution Policy is fixed at the design stage, whereas in software Agents, that boundary keeps shifting toward execution time. So even with the same three-element frame, the implementation seems to diverge depending on the domain.)