Executive summary
Agentic AI is useful when a workflow cannot be reduced to one prompt and one response. The system may need to gather evidence, plan, call tools, respond to changing state, ask for review, and recover from partial failure. That flexibility also increases attack surface and operational uncertainty. A credible architecture makes the control loop, tool contracts, authority boundaries, memory, evaluation, observability, and stop behavior explicit. It avoids treating the model as the policy engine or granting broad credentials simply because the interface is conversational.
Decision relevance: Decide whether a workflow should use an agent, what authority it may hold, and what evidence is required before it can act.
What makes a system agentic
The word agent is frequently applied to any application that calls a language model. A more useful definition focuses on the control loop. An agentic system can choose among possible next actions based on its current goal, evidence, state, and feedback from the environment.
The degree of agency is not binary. A system may draft a plan but require human execution. It may select from a small allowlist of tools. It may repeat a retrieval step until a confidence condition is met. It may coordinate a long-running case while pausing at each consequential boundary. The architecture should describe the actual agency instead of using the label as a marketing shortcut.
NIST's AI Agent Standards Initiative is explicitly concerned with agent security, identity, interoperability, and measurement. Its existence reflects the fact that agents introduce system-level concerns beyond ordinary model evaluation. [S1]
The eight-state agentic control loop
A practical control loop can be reviewed through eight states. Implementations may merge or subdivide them, but the questions remain useful.
- Observe. Collect authorized state and identify what changed.
- Interpret. Form a bounded representation of the situation, including uncertainty and missing evidence.
- Plan. Propose one or more steps, dependencies, expected effects, and stop conditions.
- Authorize. Confirm that the actor, policy, environment, and tool scope permit the next step.
- Act. Invoke a bounded tool or produce a proposed artifact.
- Verify. Check the actual result, side effects, and evidence rather than assuming success from a tool response.
- Remember. Record state and provenance appropriate for the next step and future review.
- Stop. Complete, wait, refuse, escalate, roll back, or terminate when a limit is reached.
Tool use is the authority boundary
The model may propose a tool call, but the surrounding application decides whether that call is allowed. Treat tool definitions as contracts: input schema, permitted identity, data classification, environment, rate and value limits, idempotency, timeout, side effects, and verification requirements.
A common agentic failure is ambient authority. The agent inherits a broad credential and can discover or invoke capabilities unrelated to the current task. Another is semantic overreach: a natural-language tool description sounds narrow while the underlying API permits a much wider action.
The MCP specification separates clients, servers, resources, prompts, and tools, and describes explicit negotiation and capability boundaries. That can improve interoperability, but protocol compatibility does not establish business authorization. [S6] [S7] [S8]
- Use task-scoped credentials and explicit allowlists
- Separate read, propose, approve, and execute capabilities
- Require structured arguments and validate them outside the model
- Record the tool version, identity, request, response, and verified effect
- Design idempotency and reconciliation for retryable actions
- Keep a stop or revocation path independent of the agent runtime
Memory and state must preserve provenance
Agents often need more than a context window. They need workflow state that survives restarts, business state from authoritative systems, episodic evidence from the current run, and reusable knowledge that may apply across runs.
These categories should not be placed in one ungoverned vector store. A remembered statement needs a source, authority, observation time, effective time, scope, trust state, retention rule, and supersession relationship. Retrieved memory should not silently become policy. High-consequence instruction belongs in a separately governed policy and authority layer.
The related LongTermCapabilities article on memory, state, and provenance examines retry safety, human checkpoints, and operational evidence in more detail.
Evaluate the trajectory, not just the answer
Final-answer scoring can miss the most important failures. An agent may arrive at a plausible answer after reading unauthorized data, selecting an unsafe tool, retrying a side effect, ignoring a refusal, or accumulating excessive cost. Evaluation should inspect the trajectory and the environment response.
NIST's agentic evaluation work uses probes to study behaviors such as task completion and susceptibility to hijacking. OWASP's agentic guidance likewise emphasizes threats that arise from goals, memory, tools, identity, and multi-step action. [S2] [S3] [S4]
- Task completion and quality under representative cases
- Plan quality and consistency with the declared goal
- Authorization and cross-tenant boundary behavior
- Tool choice, argument safety, side effects, and verification
- Response to prompt injection, memory poisoning, and conflicting instructions
- Retry, timeout, partial failure, restart, and duplicate-effect behavior
- Cost, latency, token, reviewer-load, and escalation behavior
- Ability to refuse, stop, or preserve an unknown result
Security is a control-plane property
Agentic security cannot be reduced to filtering a prompt. The attack surface includes indirect instructions in retrieved content, poisoned memory, tool metadata, delegated identity, malicious outputs from another agent, and compromised external services.
OWASP's agentic application work identifies recurring risks such as goal hijacking, tool misuse, identity and privilege abuse, memory manipulation, cascading failures, and inadequate monitoring. The durable response is layered: minimize authority, isolate tools, validate structured data, retain provenance, monitor trajectories, and make high-consequence transitions reversible or reviewable. [S4] [S5]
Interoperability does not remove governance
Protocols can make components easier to connect. MCP is primarily useful for connecting an AI application to tools and context providers. A2A is intended for communication and collaboration between agents or agent systems. The A2A documentation describes these roles as complementary rather than interchangeable. [S9] [S10]
Interoperability can also magnify ambiguity. A receiving system still needs to know who sent the message, what task and authority it represents, which data may be disclosed, what completion means, how errors are represented, and which evidence must be retained. A protocol handshake is not a trust decision.
When an agent is the wrong architecture
Do not add an agent when deterministic logic can express the decision more clearly, when the system lacks representative test cases, when the required authority cannot be bounded, or when no one owns the consequences. An agent is also a poor fit when every step requires synchronous human approval and no orchestration value remains.
The simplest system that can meet the outcome is usually the easiest to test, secure, explain, recover, and change. Agentic architecture is justified when adaptive sequencing or environment interaction produces measurable value that outweighs the added control and evaluation cost.
Research boundary
This page describes engineering and governance patterns. It does not certify an agent, guarantee security, or declare that LongTermCapabilities offers every implementation described. Any production use requires use-case-specific evidence, security review, legal review where applicable, and named operational ownership.
Sources
Sources support the linked statements and terminology. They do not certify a system, establish buyer intent, or convert this research into a formal assurance.
- AI Agent Standards InitiativeNIST · Accessed 2026-08-01
Government initiative
- Building Evaluation Probes for Agentic AINIST · Accessed 2026-08-01
Government research program
- Strengthening AI Agent Hijacking EvaluationsNIST · Accessed 2026-08-01
Government technical blog
- OWASP Top 10 for Agentic Applications for 2026OWASP GenAI Security Project · Accessed 2026-08-01
Open security guidance
- Securing Agentic Applications Guide 1.0OWASP GenAI Security Project · Accessed 2026-08-01
Open security guidance
- Model Context Protocol specification, 2026-07-28Model Context Protocol · Accessed 2026-08-01
Technical specification
- Model Context Protocol architectureModel Context Protocol · Accessed 2026-08-01
Technical specification
- Model Context Protocol server toolsModel Context Protocol · Accessed 2026-08-01
Technical specification
- Agent2Agent Protocol specificationA2A Protocol · Accessed 2026-08-01
Technical specification
- A2A and MCPA2A Protocol · Accessed 2026-08-01
Technical guidance