PLAN → ACTION → EVIDENCE. For risky changes: PLAN → DRY-RUN → ACTION → EVIDENCE.
Why AI work needs an execution protocol
Traditional AI literacy focused on asking useful questions, understanding limitations, and evaluating answers. Agentic systems add a new problem: the model can now read files, call APIs, use a browser, run commands, and modify external state. The question is no longer only “Is the answer correct?” It is also “What exactly will the system do, what is it allowed to touch, and how do we know the action actually succeeded?”
Plan–Action–Evidence separates those concerns into three observable stages. It is intentionally small enough to use for a single file edit and general enough to describe a multi-step agent workflow.
PLAN: define intent, boundaries, and success
PLAN specifies the desired state before execution. A useful plan answers four questions: what should change, what context and tools may be used, what must not change, and what signal will count as success. For an agent, permissions are part of the plan, not an afterthought.
“Find duplicate application installs. Do not uninstall anything. Show the installation path, version, and evidence that two entries refer to the same product.”
ACTION: move from advice to real work
ACTION is the permitted operation itself: reading a file, comparing revisions, running a test, editing code, navigating a browser, creating a document, or changing a record in a business system. A description of an action is not an action. If the operation is destructive or difficult to reverse, insert a dry-run or preview before execution.
EVIDENCE: verify the state, not the message
EVIDENCE is an observable signal that confirms what happened. Useful evidence includes a diff, a created artifact, a passing test, a system log, an API response, a second read of the target state, a screenshot, or a before/after metric. The strongest evidence does not depend on trusting the same model that performed the action.
“Done” is not evidence. A model's completion message is a report, not proof of completion.
A practical evidence ladder
- Claim: the agent says it completed the task.
- Trace: the tool reports an operation or emits a log.
- State check: the target system is read again and the expected change is visible.
- Independent verification: a test, diff, external query, or second mechanism confirms the result.
- Machine-verifiable receipt: a signed execution record or audit artifact can be validated later.
Where dry-run fits
Dry-run is not a fourth universal stage. It is a safety mode inside the transition from PLAN to ACTION. The agent executes the decision logic but suppresses external mutation, producing a preview of intended changes. This makes the extended pattern easy to remember without overloading every task: PLAN → [DRY-RUN] → ACTION → EVIDENCE.
Example: an agent with a filesystem boundary
Suppose an AI agent may work only inside a dedicated workspace. PLAN defines the allowed directory and the expected denial outside it. ACTION attempts one permitted read and one prohibited read. EVIDENCE is binary and reproducible: the allowed path succeeds while the private path is denied. That result is more useful than a policy statement because it tests the actual boundary.
Why PAE matters for agentic AI literacy
Agentic AI literacy is not just knowing what an agent is. It is the ability to design the work around execution: define intent, constrain permissions, decide when dry-run or approval is required, and demand evidence after the action. PAE provides a compact language for that operational skill.
Use cases
The same protocol works for code changes, research, document workflows, browser automation, data processing, IT operations, and business applications. PLAN preserves human intent. ACTION turns model capability into real work. EVIDENCE reconnects the workflow to observable reality.
Related concepts
Continue with Agentic AI Literacy for the broader human skill set, AI Agent Dry Run for safe previews, and AI Agent Evidence for completion verification and evidence trails.