Defining an AI Agent by Architecture, Not Marketing
The term "AI agent" is applied inconsistently across the industry, often to describe anything from a scripted chatbot to a fully autonomous multi-step system. A technically grounded definition requires looking at architecture rather than product labeling. According to Microsoft's documentation on agentic AI architecture, an agent combines an LLM with planning, memory, and tool or function-calling components to pursue multi-step goals with reduced human intervention compared to single-turn chatbot interactions. Google Cloud's agent architecture documentation draws a similar distinction, noting that agents are separated from simple prompt-response applications by their ability to decompose tasks, call external tools or APIs, and maintain state across multiple reasoning steps.
Anthropic's published guidance on building effective agents offers a further useful distinction between "workflows," which are predefined code paths that orchestrate LLM calls in a fixed sequence, and "agents," where the LLM dynamically directs its own process and tool usage. This distinction matters for governance because a workflow's control flow is fully determined in advance and auditable by design, while an agent's control flow is determined at runtime by the model itself. That shift, from human-authored logic to model-directed logic, is the core reason agents require governance controls that standard applications do not.
Why Tool Calling Changes the Risk Profile
The single architectural feature most directly tied to new governance exposure is tool or function calling. A standalone LLM produces text. An agent with tool access can use that text output to trigger a database query, send an email, modify a file, execute a financial transaction, or call another system. OWASP's guidance on agentic AI security identifies tool-calling and autonomous action execution as introducing threat categories not present in standard chatbot deployments, including excessive agency and unauthorized tool invocation.
This distinction is formalized in OWASP's Top 10 for LLM Applications, which names "Excessive Agency" as a specific risk category, describing scenarios where an agent is granted permissions, functionality, or autonomy beyond what its task actually requires. Memory persistence compounds this exposure. An agent that retains state across sessions or tasks has a larger surface area for data leakage, state-based errors, and unintended chaining of actions than a stateless chatbot interaction, since earlier context can influence later autonomous decisions in ways that are harder to trace.
Architectural Types of AI Agents and Their Governance Implications
Multi-Agent Systems Introduce Additional Coordination Risk
Multi-agent systems, where multiple LLM-driven agents coordinate or delegate subtasks to one another, are identified by both Anthropic and Google as introducing coordination and error-propagation risks beyond those of a single agent. When one agent's output becomes another agent's input, an error or hallucination introduced early in the chain can propagate and compound across subsequent steps without a human reviewing the intermediate state. This also creates an accountability problem: when a multi-agent system produces an erroneous or unauthorized action, determining which agent's decision, or which handoff between agents, caused the outcome requires logging that captures the full decision chain, not just the final result.
Core Governance Requirements for Agentic Systems
NIST's AI Risk Management Framework (AI RMF 1.0) establishes governance functions, Govern, Map, Measure, and Manage, that apply to AI systems generally, and emphasizes that systems with higher autonomy require correspondingly stronger monitoring, human oversight, and incident response mechanisms as part of the Manage function. Applied to agents specifically, this translates into a small set of concrete requirements.
First, identity and accountability need to be assigned to agent actions distinctly from the identity of the deploying application or end user, so that an action taken by an agent can be traced to that agent's specific permissions and context rather than attributed generically to "the system." Second, policy enforcement needs to occur at the tool-invocation layer, not solely at input or output content filtering, since the point of real-world consequence is the tool call itself. Third, NIST's Generative AI Profile identifies traceability and provenance of AI-generated actions as a governance gap specific to systems that execute actions autonomously rather than only generating text, meaning audit logs need to capture planning steps and tool calls, not just final output.