Anatomy of an AI agent: the parts and where each one lives

Take the illustrative order-change agent in the diagram. A service representative pastes a customer email into Teams. The runtime opens a session under the agent’s identity, acting on behalf of that representative, so every downstream call carries her permissions and no more. The model reads its instructions (find the order, propose the change, never touch price), the email, and the definitions of the tools it may call.

It asks for the order-lookup tool with the order number it extracted. Before the call runs, two checks happen outside the model: a guardrail on the tool call (is this tool allowed for this agent, with these arguments?) and the identity check at the system of record (may this representative read this order?). The runtime runs the call, appends the result, and the model proposes a change. The order-change tool is marked as needing approval, so the run pauses with the exact arguments shown to the representative. She approves, the runtime executes the change through a deterministic flow, and the trace records the model calls, the tool calls, the approval and the tokens used.

Memory decides what the next request looks like. Session memory keeps the conversation within the task. Cross-session memory, if the design allows it, would let the agent recall that this customer always ships to the same warehouse. Most first agents should run without it, because what the agent remembers is data that needs retention rules and access control, and because the MINJA paper (March 2025, revised February 2026) showed an agent’s memory can be poisoned through ordinary queries alone, with no write access.

Skills solve a context problem: an agent that knows many procedures would otherwise carry all of them in its prompt on every call. With skills it loads only each skill’s name and description at startup, reads the full SKILL.md when a task matches, and runs any bundled scripts as it goes; the format calls this progressive disclosure. Anthropic released the format as an open standard, and on 22 Oct 2026 the Agentic AI Foundation, under the Linux Foundation, took it in as a project alongside MCP and A2A. The platforms followed: Microsoft Foundry Toolboxes carry skills (preview), Google’s Skill Registry entered preview on 19 May 2026, AWS Agent Registry stores skills as a record type, and the AgentCore managed harness is configured with a model, tools, skills and instructions.

AGENTS.md started with OpenAI and became a founding project of the Agentic AI Foundation on 9 Dec 2025, together with MCP and goose. The file sits at the root of a repository, with nested files in subprojects taking precedence, and holds setup commands, code style, testing and pull-request instructions, and security notes. The project site lists Codex, GitHub Copilot’s coding agent, Cursor, Gemini CLI, goose and others as readers, and says more than 60,000 open-source projects carry one. OpenAI’s current model guide notes that GPT-6 Astra is more sensitive to instructions in skills and AGENTS.md files than earlier models, which is the practical reason to version both as code and rerun the evaluation set when they change.

For an IT leader the two matter for one reason: they are instructions that change the agent’s behaviour without a release of the agent itself. Treat them as configuration under change control, with an owner and a review, the same as a prompt.

Identity: each agent gets its own identity object, from an identity blueprint in Microsoft Entra, a workload identity in the AgentCore Identity directory, or a SPIFFE-based principal on Google Cloud. Per tool you decide whether it acts for a user (the token is exchanged for one scoped to the downstream system, so the agent can never exceed the user’s rights) or as itself. Microsoft’s docs say reusing user accounts for agents breaks Conditional Access, ID Protection and governance.

Human approval: a tool marked as needing approval pauses the run with the tool name and arguments. Microsoft Agent Framework uses approval_mode set to always_require, the Foundry MCP tool defaults require_approval to always, the OpenAI Agents SDK uses needs_approval, LangGraph uses interrupt, and Google ADK uses require_confirmation (experimental). Approval responses must be bound to the pending request, or a replayed message can approve a privileged call.

Guardrails: checks on input from every untrusted channel, including tool results, and a deterministic policy on tool calls. AgentCore Policy (GA 3 Mar 2026) evaluates Cedar rules on every tool request through the Gateway; Foundry agent guardrails add tool-call and tool-response intervention points (preview); Google Agent Gateway is the policy point every tool call passes through, with Model Armor inline.

Observability: OpenTelemetry spans for each agent invocation, model call and tool call (the GenAI conventions are still in Development status), with token counts and latency recorded by default and prompts, arguments and results captured only by opt-in. The registry record ties the traces to an owner, a risk tier and an approval state, so an incident starts from the record. The guardrails, identity, observability and registry topics each have their own pages.