Narrate-Then-Act

Expanded Definition

Narrate-Then-Act describes a behaviour pattern in which an AI agent announces what it is about to do, then attempts the tool call or action that would actually carry out the task. In well-designed agent systems, narration is only explanatory output. In weaker harnesses, however, the narration itself may be mistaken for completion, especially when task evaluators or orchestration logic watch text logs rather than verifying that the downstream action succeeded. That creates a gap between stated intent and real execution.

The distinction matters because agentic workflows often chain planning, tool use, and status reporting across multiple steps. A model can sound decisive while still failing at the operational layer due to permission limits, malformed arguments, tool errors, or truncated execution. This is why NHI Management Group treats Narrate-Then-Act as a reliability and control-flow issue, not just a prompting style. It overlaps with broader agent governance concerns described in the NIST SP 800-53 Rev 5 Security and Privacy Controls, particularly where auditing, accountability, and execution integrity are required.

The most common misapplication is treating narrated intent as evidence of successful action, which occurs when logs, chat transcripts, or intermediate assistant messages are used as the completion signal without validating the actual tool result.

Examples and Use Cases

Implementing agent workflows rigorously often introduces extra verification steps, requiring organisations to weigh smoother user experience against stronger proof that the intended action actually occurred.

• An IT support agent says it has reset a user’s password, but the password service rejected the request because the account lacked the required privilege.
• A procurement assistant narrates that it has created a purchase order, while the ERP tool call failed due to a schema mismatch.
• An AI workflow states that it has uploaded a report to shared storage, yet the file transfer never completed because the tool session expired.
• A SOC assistant announces that it has opened an incident ticket, but the ticketing API returned a validation error and no case was created.
• A developer agent describes that it has committed code changes, but the repository action was blocked by branch protection or missing signing credentials.

For agent operators, the practical control is to separate narration from state change. The model’s text should be treated as a claim, while the tool response, event log, or transaction record should be treated as evidence. Guidance on tool and action governance in AI systems is still evolving, which is why practitioners often combine prompt design with execution checks and external validation. For agentic security context, the OWASP Top 10 for Large Language Model Applications is useful for understanding failure modes around tool misuse and output handling.

Why It Matters for Security Teams

Narrate-Then-Act becomes a security issue when operators assume that a spoken or written intent means the underlying action has been authorised, executed, or logged. That assumption can hide access failures, disrupt incident response, and create false confidence in automation. In identity-heavy environments, the risk is sharper because agents may be asking for secrets, invoking privileged tools, or acting on behalf of users and services. If the harness cannot prove that the action occurred, then the organisation may misread both control effectiveness and operational status.

This is also relevant to auditability and non-human identity governance. When an agent uses a service account, API token, or delegated credential, the control plane needs to record the actual invocation, not just the model’s narration. Security teams should therefore align execution checks with logging, approval, and post-action verification, using authoritative sources such as CISA secure AI guidance and ISO/IEC 27001 where governance and traceability matter. Organisations typically encounter the real cost of Narrate-Then-Act only after an incident review reveals that the agent sounded successful while the privileged operation never happened, at which point the control gap becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How should security teams prove DORA compliance for AI agents that act autonomously?
• How should organisations prove EU AI Act compliance across the AI lifecycle?
• How should security teams govern AI assistants that can act inside IAM systems?
• How should security teams govern MCP-enabled AI assistants that can act on tools and data?