AI agents, explained step by step

What is an AI agent?

An AI agent is a system in which a language model chooses its next action, calls a tool such as a search, a shell command or an API, reads the result and repeats until the goal is met or a stop condition is hit. A chatbot answers you; an agent acts in a loop and checks what happened [1] [2].

After this section you can tell an agent from a bare model, and say whether ChatGPT or Claude “is an agent”.

This page's wording condenses what the two vendors publish. OpenAI's guide defines them in one line: “Agents are systems that independently accomplish tasks on your behalf” [1]. Anthropic describes agents as “systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks” [2]. The Claude Agent SDK documentation adds a concrete version: “An agent is an application that completes a task by planning its own steps and calling tools that read files, run commands, or edit code” [18].

OpenAI's guide gives an agent three core components: a model, tools and instructions [1]. It also says what is not an agent: an application that integrates a language model without using it to control workflow execution, such as a simple chatbot, a single-turn LLM or a sentiment classifier [1].

Tools make the difference. Claude Code's documentation puts it in two sentences: “Without tools, Claude can only respond with text. With tools, Claude can act” [5].

Figure 1.1 maps the parts of an agent around the model: the harness that holds the context, the tool runner, the permission gate and the session log; the sandbox; the tools and MCP servers; the instruction files; and you. Each numbered part links to the section of this page that explains it, and the model turns out to be one block among several.

Is ChatGPT an AI agent? Is Claude?

Under these definitions the question is about the product, not the model. Anthropic draws the line itself: “Unlike a chatbot that answers questions and waits, Claude Code can read your files, run commands, make changes, and autonomously work through problems” [20].

On OpenAI's side, ChatGPT Work, launched on 9 July 2026, is described as “an agent in ChatGPT” built on Codex technology: you follow its progress and approve the important actions [21]. OpenAI's Help Center now states that “ChatGPT agent is no longer available” and points to ChatGPT Work [22].

Both vendors keep a chat app and ship separate agentic products: Claude Code, Claude Cowork and Claude Managed Agents on Anthropic's side; Codex, ChatGPT Work, workspace agents and dots on OpenAI's [5] [23] [11] [21] [24] [25]. So the short reply is that Claude is a model and Claude Code the harness that turns it into a coding agent [19], while ChatGPT is a chat app inside which OpenAI ships an agent, ChatGPT Work [21]. Product names and launch dates change faster than the mechanism, so the page keeps them in Appendix A.

Sources for §1: [1] [2] [18] [5] [19] [20] [21] [22] [23] [11] [24] [25], checked 4 October 2026. Back to contents.

How does an AI agent work? The loop, step by step

An AI agent works in a loop. The model gathers context, acts through a tool, checks the result and picks the next step, often dozens of times in a row. The run ends on an exit condition: a final answer, a structured output, an error or a maximum number of turns. You can interrupt and steer at any point [5] [1].

After this section you can trace one run, name its exit conditions and read the run as a trace.

Claude Code's documentation describes the loop in three phases: “gather context, take action, and verify results. These phases blend together” [5]. The same page explains how the next step is chosen: “Claude decides what each step requires based on what it learned from the previous step, chaining dozens of actions together and course-correcting along the way” [5].

For the task “fix the failing tests”, the documentation lists six steps: run the test suite, read the error output, search for the relevant source files, read those files, edit the files, and run the tests again to verify. “Each tool use gives Claude new information that informs the next step” [5].

Figure 2.1 runs Task T through the loop. Step through it: the model marks when it picks a tool call and again when the result comes back, an arc lights up when the agent gathers context, takes action or verifies results, a pull request waits at the approval gate, and the run stops on one of four exit conditions. The second view draws the same run as a trace.

In Task T the first check fails, yet the run goes on: a failing check is a result the model reads, as in the documentation's own example, which reads the error output before it searches the source files [5].

OpenAI's guide describes the same shape. Every orchestration needs a “run”, a loop that continues until an exit condition is reached; the guide names “tool calls, a certain structured output, errors, or reaching a maximum number of turns” [1]. In the Agents SDK, the only tool call that ends the run is a final-output tool: Runner.run() loops until such a tool is invoked or the model answers without calling a tool [1]. Task T ends the second way, on a final answer with no tool call.

Interrupting and steering. In Claude Code you can interrupt at any point: Esc stops the running tool call, and a message you type is queued and read as soon as the running tool calls finish, within the same turn [5]. OpenAI's Responses API also queues mid-turn steering: an update cancels neither running tools nor completed actions [30].

Reading the run as a trace. Claude Code writes each message, tool use and result to a plaintext JSONL transcript under ~/.claude/projects/ [5] [19]. The same run can also be exported as telemetry: Claude Code exports OpenTelemetry metrics and events, with spans in beta and off by default [31], and Codex has otel exporter settings, including a trace exporter [29].

A W3C traceparent header carries four fields: version, trace-id, parent-id and trace-flags (Table 2.1) [26]. MCP revision 2026-07-28 documents carrying traceparent, tracestate and baggage in a request's _meta, so a tool call made through an MCP server can join the same trace [15].

While an agent's behavior is still being debugged, OpenAI advises starting its evaluation from such traces and grading them with trace graders [32]. Existing evals on its Evals platform become read-only on 31 October, and the platform is scheduled to shut down on 30 November 2026; the deprecations page adds that “Graders documented for eval workflows are part of this transition” [16].

Sources for §2: [5] [1] [26] [15] [19] [27] [28] [29] [10] [30] [31] [32] [16], checked 4 October 2026. Back to contents.

AI agent vs chatbot, assistant, workflow and LLM

An LLM is the model itself. A chatbot or assistant uses it to answer you turn by turn. A workflow chains model calls along a path that a developer wrote in code. An agent lets the model choose its own path and tools, and keeps going until the task is done or a limit is reached [2] [1].

After this section you can place any AI product on the spectrum from a fixed path to a path the model chooses.

The four words name four degrees of control, and the useful question is always the same: who chooses the next step? Table 3.1 sets them side by side, from the model alone to the model choosing its own path.

Figure 3.1 sends one request to a chatbot and to an agent. The chatbot replies with a plausible guess and its turn ends; the agent runs the check, reads the result and answers with the line the error came from. What separates them is not the quality of the prose but control of the workflow and access to tools, the two traits OpenAI's guide uses to describe an agent [1].

Anthropic's post on building effective agents draws the line between workflows and agents. It calls both “agentic systems”, then separates them: workflows are “systems where LLMs and tools are orchestrated through predefined code paths”, while agents direct their own process and tool use [2]. The same post names five workflow patterns: prompt chaining, routing, parallelization, orchestrator-workers and evaluator-optimizer [2].

Figure 3.2 draws the five patterns as small multiples, then runs one graph twice: once with the code choosing every edge, so the path is the same on every run, and once with the model choosing, so the path changes with what each step returned.

Both vendors advise starting simple. Anthropic recommends “finding the simplest solution possible, and only increasing complexity when needed” [2]. OpenAI keeps agents for work where rules fall short: complex judgment, rule sets that have become hard to maintain, heavy reliance on unstructured data; “Otherwise, a deterministic solution may suffice” [1].

Anthropic's post dates from December 2024 and now opens with a note: “Much of the tooling landscape described in this post has changed since December 2024” [2]. The note is about tooling; this section takes only the post's definitions and patterns.

Agentic AI vs generative AI

On this page, generative describes what a model produces, and agentic describes a system that acts with tools. The OWASP Top 10 for LLM Applications 2026 draws the line at the same place: its list covers the model as a component, and once the model “becomes an actor, with tools it can call, memory it carries between sessions, and consequences it sets in motion downstream”, it sends readers to the Agentic Top 10 [33].

Much of the difference is vocabulary, and it is worth saying plainly: an agent runs on a generative model, the LLM that OpenAI's guide lists as its first core component [1]. What makes it agentic is what surrounds the model: the tools, the loop and the consequences [33].

In the AI Act as amended, “agentic” appears once. Annex XIV, the codes for designating notified bodies under Article 30, has code AIH 0401, “AI systems based on other emerging AI technologies not covered by other codes, including Agentic AI”, added by Regulation (EU) 2026/1744 [14]. Regulation (EU) 2024/1689 as adopted does not contain the word [34].

Sources for §3: [2] [1] [5] [33] [14] [34], checked 4 October 2026. Back to contents.

What is an agent harness?

An agent harness is the software around the model that turns it into an agent: the tools it can call, how its context is managed, what it may do without asking, where its commands run, and the record of the session. Anthropic's documentation puts it in one line: “Claude Code is the harness; Claude is the model inside it” [19] [5].

After this section you can say who runs the loop in each vendor's offering, and why a change to the harness can change the agent.

The definition comes from the Claude Code glossary, which goes on: “Claude Code is the harness; Claude is the model inside it” [19]. “How Claude Code works” describes the same layer from the inside: Claude Code provides the tools and manages the context the model sees, and “This surrounding layer is what the term agentic harness refers to” [5].

The glossary also lists what the harness supplies: “file access, shell execution, permission gating, memory loading, and the loop that chains actions together” [19]. None of these is the model, which “never executes anything on its own”: it emits a structured request, and code around it runs the operation [35].

Figure 4.1 builds the harness one layer at a time around a model that alone does nothing but text in and text out: the tool runner, then context management, then permissions and hooks, then the sandbox walls. Its last frame sets one line from each vendor side by side.

Two vendors, one design. Anthropic's Managed Agents post of 8 April 2026 splits a hosted agent in three: the “brain” (Claude and its harness), the “hands” (sandboxes and tools that perform actions) and the session, “the append-only log of everything that happened” [37]. Each part can fail or be replaced independently [37]. A failed container comes back to the model as a tool-call error; a failed harness is replaced by a new one, rebooted with wake(sessionId), which resumes from the log [37]. On credentials, the post says the structural fix was “to make sure the tokens are never reachable from the sandbox where Claude's generated code runs” [37].

OpenAI uses the same word. Its comparison of runtimes says of the Agents API that “OpenAI runs a managed Codex harness” [36]. Launched in public beta on 10 September 2026, the Agents API exposes the harness and infrastructure that power Codex: OpenAI hosts the harness, and you choose where the agent's compute runs, in an OpenAI-hosted sandbox, on your own infrastructure or with a partner [13]. It is built on the open-source Codex harness [13], and since 29 September 2026 it also supports computer use [38].

Earlier, on 15 April 2026, OpenAI had described its Agents SDK as a model-native harness: MCP, skills loaded by progressive disclosure, AGENTS.md, a shell tool, an apply-patch tool and configurable memory, plus native sandbox execution, launching first in Python [28]. The same post gives the reason to keep harness and sandbox apart: “Separating harness and compute helps keep credentials out of environments where model-generated code executes” [28]. Both designs keep credentials away from the code the model writes [37] [28].

Each vendor offers several ways to run the loop, from your own code driving every turn to a harness the vendor hosts. Table 4.1 reads them on the same columns.

Sources for §4: [19] [5] [35] [17] [36] [27] [3] [37] [13] [38] [28] [18] [39] [40] [6] [11] [12] [29] [10] [41] [42], checked 4 October 2026. Back to contents.

What happens in a tool call?

A tool call is how an agent acts, yet the model never runs anything itself: it proposes a tool name and arguments. The harness checks the call, asks permission if needed, runs it and adds the result to the context. The model reads that result to choose its next step, so whatever a tool returns, the model reads [35] [5].

After this section you can follow one call from proposal to result, and say why tool output is an attack surface.

Anthropic's platform documentation calls tool use “a contract between your application and the model”: the application declares which operations exist and the shape of their inputs and outputs, and the model decides when and how to call them [35]. The same page states the rule that matters most for safety: “The model never executes anything on its own. It emits a structured request, your code (or Anthropic's servers) runs the operation”, and the result flows back into the conversation [35].

Claude Code's documentation describes the same loop from the agent's side: “Each tool use returns information that feeds back into the loop, informing Claude's next decision” [5]. Its built-in tools fall into five categories: file operations, search, execution, web and code intelligence [5].

What surrounds a call. Between the proposal and the result sits software that can refuse, check and record. The Model Context Protocol, the shared standard for connecting tools, spells out what a careful client does around every call: it SHOULD show tool inputs to the user before calling the server, validate tool results before passing them to the model, time out calls and log tool usage for audit [43]. On the other side, servers MUST validate all tool inputs and sanitize tool outputs [43].

Tools cost context before they run. Anthropic reports that a typical multiserver setup “can consume ~55k tokens in definitions before Claude does any work”^†, and that tool search “typically reduces this by over 85 percent”^†, loading only the three to five tools a request needs [44]. The same page reports that Claude's accuracy in picking the right tool degrades beyond 30 to 50 available tools^† [44].

Harnesses therefore load definitions late. In Claude Code, MCP tool definitions are deferred by default and loaded on demand through tool search, so only tool names and server instructions use context until a tool is used [5]. OpenAI's Agents API, which runs the Codex harness as a service managed by OpenAI, offers tool search, which “loads relevant tool definitions as needed”, and programmatic tool calling, which lets agents filter or combine results in code and bring only the relevant results back into context [13]. Claude Code's guide also notes that command-line tools are “the most context-efficient way to interact with external services” [20].

Why tool output is an attack surface. A test log, a search hit and a fetched web page all come back the same way, as a result the model reads before it picks its next step [5]. The same protocol asks clients to validate tool results before they reach the model [43]. Part III, on control, starts from there.

Sources for §5: [35] [5] [43] [44] [13] [20], checked 4 October 2026. Back to contents.

Why does an agent forget? The context window

An agent only sees its context window, and every instruction, tool definition, file and command output takes room in it. As the window fills, quality drops and older details get summarized away. Context engineering decides what goes in: load tools and skills on demand, compact old turns, hand side work to subagents, keep stable text first [20] [45].

After this section you can explain why a long session degrades, what compaction loses, and why the order of a prompt changes the bill.

Claude Code's best-practice guide builds on a single constraint: “Claude's context window fills up fast, and performance degrades as it fills” [20]. Anthropic's engineering post on the subject names the effect: as the number of tokens in the window grows, the model's ability to recall information from it decreases, which the post calls “context rot”, and a model has a limited “attention budget” that every new token draws on [45].

In Claude Code the window holds the conversation history, file contents, command outputs, CLAUDE.md, auto memory, loaded skills and system instructions [5]. Two features keep part of that out. Skills load on demand: Claude sees their descriptions at session start and their full content only when a skill is used [5]. Subagents spend a window of their own: their tool calls stay out of yours, and a summary comes back when they finish [5].

Figure 6.1 follows Task T through that budget, from the fixed load of T.01 to a session long enough to compact, then a fresh start. Its toggle runs the search of T.05 inline or in a subagent.

When the window fills. Near the limit, Claude Code clears older tool outputs first, then summarizes the conversation; your requests and key code snippets are kept, but “detailed instructions from early in the conversation may be lost”, so persistent rules belong in CLAUDE.md [5]. A project-root CLAUDE.md and auto memory survive compaction and are reloaded from disk [19]. If one file or tool output is so large that the window refills after every summary, Claude Code “stops auto-compacting after a few attempts and shows an error instead of looping” [5].

The APIs offer the same trade. Anthropic's compaction, in beta, “replaces the older turns of a conversation with a summary” that Claude writes on the server [48]. OpenAI's Agents API compacts earlier context automatically as a session approaches its limit [13], and OpenAI's GPT-6 guide describes compaction as reducing context size while preserving the state needed to continue [30].

Across sessions. A summary loses detail, and a new session starts empty. Anthropic's post on harnesses for long-running agents puts it plainly: “each new session begins with no memory of what came before” [49]. Its harness therefore leaves a progress file, a feature list and git commits behind, for the next session to read first [49].

Order changes the bill. Prompt caching works on prefixes: Anthropic's documentation describes it as “resuming from specific prefixes in your prompts” [50]. On Anthropic's API the cache follows the order tools, system, messages, and a change at one level invalidates that level and every level after it [50]. OpenAI's guide gives the matching advice: “Put stable instructions and reference material before changing task details” [30]. The same guide reports that “cached input tokens cost up to 95% less than uncached input tokens, depending on the model”^† [30].

The protocol side follows the same logic: the MCP specification asks servers to return tools/list in a deterministic order, which lets clients cache the list and improves prompt cache hit rates when tools sit in the model's context [15] [43].

How big is the window? As checked on 4 October 2026, the current flagship models of both vendors accept about one million tokens: 1M tokens on the Claude 5.x models in Anthropic's models overview [51], and 1,050,000 tokens on OpenAI's four GPT-6 model pages [52]. The size moves the limit; it does not remove the constraint above.

Sources for §6: [20] [45] [5] [44] [46] [19] [47] [48] [13] [30] [49] [50] [15] [43] [51] [52], checked 4 October 2026. Back to contents.

CLAUDE.md, AGENTS.md, skills and subagents: what loads when?

AGENTS.md and CLAUDE.md are plain Markdown files of project rules that a coding agent reads when a session starts. Skills are folders of instructions that load only when a task needs them. Subagents do a side task in their own context and return a summary. None of them enforces anything: hooks, permission rules and the sandbox do [17] [53] [19].

After this section you can predict which instruction files an agent reads, and choose between a rule, a skill, a subagent and a hook.

Claude Code loads its CLAUDE.md files, Markdown files of project instructions, and its auto memory at the start of every conversation [17]. AGENTS.md is an open format of the same kind, which describes itself as “a README for agents” and is stewarded by the Agentic AI Foundation under the Linux Foundation [53].

Short files work better. Claude Code's memory page sets a target of under 200 lines per CLAUDE.md [17]. Its best-practice guide suggests asking of every line, “Would removing this cause Claude to make mistakes?”, and warns that bloated files cause Claude to ignore your actual instructions [20]. Auto memory holds the notes Claude writes itself from your corrections and preferences; the first 200 lines or 25 KB of MEMORY.md, whichever comes first, load in each session [17].

Which file wins. Each vendor documents its own rule. Since v2.1.277, published on 18 September 2026 [6], Claude Code reads AGENTS.md when there is no CLAUDE.md, .claude/CLAUDE.md or CLAUDE.local.md in the working directory or above it; with both kinds present it reads the CLAUDE.md files only by default, and a setting can load both [17]. It never reads AGENTS.local.md, AGENTS.override.md or anything under an .agents/ directory [17].

Codex builds an instruction chain when it starts: in its home directory it reads AGENTS.override.md if it exists, otherwise AGENTS.md, and keeps only the first non-empty file; then it walks from the project root, typically the Git root, down to the current directory, taking at most one file per directory [54]. The files are concatenated from the root down, so “files closer to your current directory override earlier guidance”, and Codex stops adding files at project_doc_max_bytes, 32 KiB by default [54].

The AGENTS.md site gives the general rule: “The closest AGENTS.md to the edited file wins; explicit user chat prompts override everything” [53]. OpenAI's GPT-6 guide adds what such a file should say: when particular documents and tests are relevant, and an explicit go-ahead for safe routine workflows, such as running local tests with disposable data and no production access [30].

What enforces a rule. None of these files can stop an action. Claude Code's memory page is explicit: to block an action regardless of what Claude decides, use a PreToolUse hook instead [17]. A hook is a user-defined handler that runs at a fixed point of the session's lifecycle, such as before a tool runs, after a file edit or at session start [19]. Claude Code's guide to building a setup over time gives the rule of thumb: a convention or command Claude gets wrong twice goes into CLAUDE.md; something that must happen every time without asking becomes a hook [55].

Skills: instructions loaded on demand

A skill is a folder with a SKILL.md file that holds a name, a description and instructions for a specific task, and may bundle scripts, references and other files [56]. Agents load skills by progressive disclosure, in three stages: at startup only each skill's name and description, the full SKILL.md when a task matches the description, and bundled files only as needed [56] [9]. Claude Code's documentation states the effect on context: “Claude sees skill descriptions at session start, but the full content only loads when a skill is used” [5].

Anthropic introduced Agent Skills on 16 October 2025 and published the format as an open standard on 18 December 2025 [9]. Codex added agent skills the next day, 19 December 2025, following the open agent skills specification [10], and agentskills.io lists adopters including Claude Code, ChatGPT and Codex, GitHub Copilot, Cursor and Gemini CLI [56].

Subagents: a side task in its own context

A subagent is a second agent loop for a delegated task. In Claude Code it runs in its own context window, with its own system prompt, tool access and permissions, and returns a summary; the built-in ones include Explore, Plan and general-purpose [19]. Claude Code's setup guide names the trigger: when a side task floods your conversation with output you will not reference again, route it through a subagent [55].

Codex defines custom agents as TOML files in ~/.codex/agents/ or .codex/agents/, each with a name, a description and developer_instructions [47]. Local Codex releases spawn subagents after a direct request or an applicable project or skill instruction, and the documentation suggests them for read-heavy tasks such as exploration, tests, triage and summarization, with more care for write-heavy work [47].

Delegation costs tokens on both sides. Claude Code's documentation warns: “Running several sessions or subagents at once multiplies token usage” [57]. OpenAI's Responses API offers a multi-agent mode, in beta, that gives each subagent its own context and defaults to three active subagents (max_concurrent_subagents); its documentation adds that subagents can increase token usage and may not help tasks that depend on a single ordered chain of reasoning or require frequent writes to shared mutable state [46].

Figure 7.1 steps through one session in a single context column: what is always loaded, what loads on demand, what runs apart, and what stands outside the column and enforces. Table 7.1 gives the same mechanisms row by row.

Sources for §7: [17] [53] [19] [20] [6] [54] [30] [55] [56] [9] [5] [10] [47] [57] [46] [58] [27], checked 4 October 2026. Back to contents.

What is MCP, and how is it different from an API?

MCP, the Model Context Protocol, is an open standard that lets an agent discover and call the tools and data that servers expose, the same way for every server. An API is one service's own interface; an MCP server usually wraps APIs so that any compliant agent can use them. The 2026-07-28 revision made the protocol stateless [59] [15].

After this section you can explain MCP in its current revision, and tell it apart from an API and from A2A.

MCP versions are dates: each version string marks the last date on which backwards-incompatible changes were made [61]. As checked on 4 October 2026, the versioning page names 2026-07-28 as the current version [61]. Table 8.1 lists the headline changes of each revision since March 2025.

What 2026-07-28 changed. The revision rewrote how a client talks to a server [15]:

• Protocol-level sessions and the Mcp-Session-Id header are removed, and so is the initialize and notifications/initialized handshake; every request carries its protocol version and client capabilities in _meta [15].
• Servers MUST implement server/discover, which advertises their supported versions, capabilities and identity; clients MAY call it before any other request [15].
• Multi Round-Trip Requests replace server-initiated requests: a server that needs more input returns resultType: "input_required" with inputRequests, and the client retries the original request with inputResponses [15].
• Every result carries a resultType, "complete" or "input_required" [15].
• SSE stream resumability is removed: a broken stream loses the in-flight request, which the client re-issues as a new request [15].
• Tasks move out of the core protocol into an official extension [15].

The Agentic AI Foundation's migration post, written a week before the release and so still speaking of proposals, states the aim: standard round-robin load balancing, with no sticky sessions and no shared session state [62]. Figure 8.1 runs the same tool call under both revisions.

What it retires. The same revision deprecates Roots, Sampling and Logging, with the advice to “log to stderr (stdio) or use OpenTelemetry instead of Logging”; it also deprecates the HTTP+SSE transport, two includeContext values, and Dynamic Client Registration in favor of Client ID Metadata Documents [15]. A deprecated feature stays in the specification for at least twelve months, or at least ninety days under the policy's expedited-removal exception, before it can be removed [61]; the migration post gives 28 July 2027 as the earliest removal date for this set [62].

Rules for whoever runs the agent. On tools, the specification says that “there SHOULD always be a human in the loop with the ability to deny tool invocations”, and that clients “MUST consider tool annotations to be untrusted unless they come from trusted servers” [43]. On authorization, the security best practices of the same revision say that servers MUST NOT treat possession of a state handle as authentication, and MUST NOT accept tokens that were not issued for them [66].

MCP vs API

An API is one service's own interface, with its own endpoints, authentication and conventions. MCP is one protocol: any compliant client lists a server's tools with tools/list and calls them with tools/call, whatever the server does behind them [43]. An MCP server is therefore usually an adapter in front of one or more APIs; the specification's own description of tools says they let models interact with external systems, “such as querying databases, calling APIs, or performing computations” [43]. The changelog of the current revision is the best single page to read next [15].

MCP vs A2A

A2A, the Agent2Agent protocol, answers a different question. Its specification, version 1.0.0, calls the two “complementary protocols”: MCP standardizes how agents connect to tools, APIs, data sources and other resources, while A2A standardizes how independent agents communicate and collaborate with each other as peers [67]. Its own example joins them: an A2A server agent may use MCP to reach the tools it needs to finish a task that an A2A client agent asked for [67].

Sources for §8: [59] [15] [60] [61] [62] [43] [26] [63] [64] [65] [66] [20] [55] [67] [68], checked 4 October 2026. Back to contents.

Are AI agents dangerous? Prompt injection and the lethal trifecta

An AI agent is dangerous in two documented ways: it can obey instructions hidden in a web page, an email or a file and use its access to leak data, and it can work around the controls it was given [69] [70]. The defenses are structural: never combine untrusted content, private data and outbound communication without a human gate [71].

After this section you can explain prompt injection, recognize the dangerous combination of capabilities, and name defenses that give guarantees rather than probabilities.

Start from Task T and change a single line of what the agent reads.

The hidden instruction arrives the way every tool result does. The harness runs the read and adds what it returns to the context as text, and the model reads that text to choose its next step: whatever a tool returns, the model reads [35] [5].

The attack has had a name since 12 September 2022, when Simon Willison described prompt injection attacks against GPT-3 [72]. Indirect injection, where the hostile text arrives inside data the application retrieves rather than from the user, was described in a paper of 23 February 2023 [73]. This page uses the definition of Claude Code's glossary, with the agent in place of Claude:

The lethal trifecta. On 16 June 2025 Simon Willison named the combination that turns an injection into a leak: access to private data, exposure to untrusted content, and the ability to externally communicate [69]. The poisoned run has all three: an API key sits in the environment, the scraped line is untrusted, and the agent can send requests out. On guardrails that claim to catch most attacks, he is blunt: “95% is very much a failing grade” [69].

The Rule of Two. Meta's “Agents Rule of Two” (31 October 2025) turns the same idea into a design rule: within one session, an agent should satisfy no more than two of three properties [71].

• [A] It processes untrustworthy inputs.
• [B] It has access to sensitive systems or private data.
• [C] It can change state or communicate externally.

If a task needs all three, the agent should not run autonomously but under supervision, such as human-in-the-loop approval; Meta presents the rule as an addition to least privilege, not a replacement for it [71].

Figure 9.1 puts the three legs on switches. Play the attack with all three on and the key leaves; switch any leg off and the path breaks at that leg; or keep all three and put a human approval on the outbound call, which pauses the request where a person can see what it would send. The captions under the switches give one structure three names: the trifecta, the Rule of Two, and the sources and sinks of OpenAI's analysis [69] [71] [74].

What the vendors do. Both vendors treat outside content as untrusted in their own tools [4] [76]. In Claude Code, the auto-mode classifier sees the user's messages and the agent's tool calls with tool results stripped, so hostile content in a file or a web page cannot address it directly [4] [19]. Codex's security page says “Treat web results as untrusted” [76], and OpenAI's computer-use guide asks the same for what appears on screen [77].

OpenAI's post of 11 March 2026 adds that the most effective real-world injections increasingly resemble social engineering, and that defense cannot rely only on filtering inputs: systems should be designed to limit the impact even when some attacks succeed [74]. OpenAI reports that an example attack email from 2025 worked in 50% of its tests with a given prompt ^† [74]. It pairs this with source-sink analysis and with a mitigation it calls Safe Url [74].

The community lists. The OWASP GenAI Security Project published its Top 10 for Agentic Applications in December 2025 (Table 9.1) [75]. The document introduces the principle of “Least-Agency” and calls observability “non-negotiable” [75]. In the project's separate Top 10 for LLM applications, dated 3 August 2026, Excessive Agency “climbed to third” (LLM03:2026) [33].

Defenses by design. Researchers have proposed defenses that hold by construction rather than by detection [78] [79]. A 2025 paper describes six design patterns against injection: Action-Selector, Plan-Then-Execute, LLM Map-Reduce, Dual LLM, Code-Then-Execute and Context-Minimization [78]. CaMeL, from another 2025 paper, separates the control flow of a task from the untrusted data it handles; its authors report 77% of AgentDojo tasks solved with provable security, against 84% for an undefended system [79].

Sources for §9: [69] [70] [71] [35] [5] [72] [73] [19] [74] [75] [4] [76] [77] [33] [78] [79] [23] [80], checked 4 October 2026. Back to contents.

What may an agent do without asking? Sandboxes and permissions

Two layers decide what an agent may do without asking. A sandbox enforced by the operating system limits which files and network hosts its commands can reach [3] [76]. Permission settings decide which actions run, which ask a person and which are refused. Both Anthropic and OpenAI now let an AI reviewer approve routine actions, and both publish that reviewer's limits [4] [7].

After this section you can explain the two walls, read both permission models side by side, and read the error rates a vendor publishes for its AI reviewer, with their limits.

The poisoned run wants the API key and an outbound request to carry it. Two layers stand in the way before any person is asked: walls around the agent's commands, and settings that decide what runs on its own.

Two walls. Anthropic's sandboxing post explains why one wall is not enough: “Without network isolation, a compromised agent could exfiltrate sensitive files like SSH keys”, and “without filesystem isolation, a compromised agent could easily escape the sandbox and gain network access” [3]. Claude Code builds the walls on Linux bubblewrap and macOS Seatbelt, and Anthropic released the sandbox runtime as an open-source research preview [3]. In its internal usage, Anthropic found that “sandboxing safely reduces permission prompts by 84%” ^† [3].

The Claude Code sandbox covers shell commands only, and its allowed network domains “start empty”; Claude's file tools, local MCP servers and command hooks run outside it [58]. Codex names three sandbox modes: read-only, workspace-write (the default for version-controlled folders) and danger-full-access [76]. Its approval policies include on-request, the default, never, and a granular policy that keeps chosen prompt categories interactive and rejects the others; the older untrusted policy is retired [76]. The network is off by default, and the operating system enforces the boundary: Seatbelt through sandbox-exec on macOS, bwrap plus seccomp on Linux, a native sandbox or WSL2 on Windows [76].

Figure 10.1 draws the two walls around one shell. With both on, Task T's check runs inside the project, a write outside the project stops at the filesystem wall, a read of ~/.ssh/ passes it (by default that wall stops writes, not reads), and a request to an unknown host stops at the network wall, which is what keeps the key in. Switch one wall off and see what the other no longer covers.

Permission settings. Inside the walls, settings decide what runs without a person: six permission modes in Claude Code, four in Codex, built on its sandbox modes and approval policies (Table 10.1) [19] [81]. From v2.1.283, published on 25 September 2026, auto mode is the built-in starting mode for interactive terminal and VS Code sessions; on earlier versions it was the starting mode only on Pro, Max and Team plans [82] [6]. Auto mode needs a supported model, and an organization can turn it off [82].

Rules sit on top of the modes. The Agent SDK evaluates a tool call in a fixed order: hooks, deny rules, ask rules, the permission mode, allow rules, then the canUseTool callback; a matching deny rule blocks the tool “even in bypassPermissions mode” [27]. Rules are evaluated deny, then ask, then allow, and the first match wins [19]. Checkpoints do not cover everything: “Actions that affect remote systems (databases, APIs, deployments) can't be checkpointed” [5].

OpenAI documents the same gates in its own tools. In the Agents SDK, a tool marked needs_approval makes the run return interruptions with a resumable state; you approve or reject, then resume [83]. OpenAI's practical guide advises rating each tool low, medium or high risk, and triggering human intervention when failure thresholds are exceeded and before high-risk actions [1]. Codex's prompting guide asks for approval before the agent sends, publishes or changes information that others rely on [84]. The pull request of Task T, at step T.11, is such an action.

AI reviewers. Both vendors let a second model decide on approval requests in place of the user [4] [7]. Anthropic's auto mode classifier sees only the user's messages and the agent's tool calls, with Claude's own messages and tool outputs stripped, “making it reasoning-blind by design”; it runs in two stages [4]. For the deployed pipeline Anthropic reports 0.4% false positives on real traffic (n = 10,000), 17% false negatives on real overeager actions (n = 52) and 5.7% false negatives on synthetic exfiltration attempts (n = 1,000) ^† [4]. The post adds: “The 17% false-negative rate on real overeager actions is the honest number” ^† [4].

In Codex, setting approvals_reviewer = "auto_review" routes eligible approval requests to a reviewer agent [76]. Auto-review reviews only actions that already need approval, so actions inside the sandbox are not reviewed, and it widens neither the sandbox nor network access [7]. Where Anthropic's classifier has tool results stripped, Codex's reviewer sees “a compact transcript plus the exact approval request”, typically with tool calls and tool outputs but without hidden assistant reasoning [7]. It is designed to block sending private data, secrets or credentials to untrusted destinations, probing for credentials, broad or persistent security weakening, and destructive actions with a significant risk of irreversible damage; the policy itself is open source [7]. In the current open-source implementation, a circuit breaker interrupts the turn after “3 consecutive denials or 10 denials within a rolling window of the last 50 reviews in the same turn”, and /approve allows one retry of a denied action, which still goes through Auto-review [7].

Figure 10.2 puts the published figures in one place: approvals as dots, the sandbox's reduction in prompts as a bar, the classifier's misses on its small sample, and Codex's circuit breaker as a counter [4] [3] [7].

Containment. Anthropic describes its containment product by product: claude.ai runs code in a gVisor container, Claude Code is a “human-in-the-loop sandbox” (approval prompts plus an operating-system sandbox, Seatbelt or bubblewrap), and Cowork runs the code it executes in a local virtual machine [23]. The same post states “the weakest layer is the one you built yourself” [23].

In a controlled internal red-team exercise in February 2026, a researcher phished an employee into launching Claude Code with a malicious prompt [23]. “Across 25 retries of that prompt, Claude completed the exfiltration 24 times” ^† [23]. The post calls this a direct injection, since the instructions arrived through the user, and concludes that the only defense that holds in that case is the environment: egress controls and filesystem boundaries [23].

OpenAI's misalignment monitoring is asynchronous. On a trigger the API returns HTTP 403 with invalid_request_error and misalignment_policy_violation; the guidance is to stop dispatching actions and not to retry automatically [85]. The page warns: “Because monitoring is asynchronous, an action may already have completed before monitoring identifies a concern” [85].

Sources for §10: [3] [76] [4] [7] [19] [58] [81] [82] [6] [27] [5] [83] [1] [84] [23] [85], checked 4 October 2026. Back to contents.

How do you evaluate an AI agent? Verification, pass@k and pass^k

An agent did the job when a check it cannot argue with passes: a test, a build [20]. To measure reliability, run each task several times: pass@k is the chance that at least one of k tries succeeds, pass^k the chance that all succeed [86]. At 75% per try, the computed chance that three tries all succeed is about 42% [86].

After this section you can define an eval, tell pass@k from pass^k, and read a benchmark score with suspicion.

Task T closes on evidence: the check fails at T.04, passes at T.10, and only then does the agent ask to open the pull request. Claude Code's best practices make this the first rule: “Give Claude a check it can run: tests, a build, a screenshot to compare” [20]. Without one, “looks done” is the only signal, and “you become the verification loop” [20].

The best-practices page lists gates of increasing strength [20]:

1. ask for the check in the prompt;
2. set it as a /goal condition, which a separate evaluator re-checks after every turn;
3. add a Stop hook that runs the check as a script and blocks the turn from ending until it passes;
4. hand the result to a verification subagent, a fresh model that tries to refute it.

OpenAI's model guide of 2 October 2026 for the GPT-6 family gives the same instruction in its own words: define what “done” means (implement, run, inspect the result, fix failures) and list the decisions that need you [30].

The vocabulary of evals. Anthropic's post on agent evals fixes the terms [86]:

• a task is “a single test with defined inputs and success criteria”;
• a trial is one attempt at a task;
• a grader is the logic that scores some aspect of the agent's performance;
• a transcript is “the complete record of a trial”;
• the outcome is “the final state in the environment” at the end of the trial.

In Task T the transcript is the twelve steps. The final answer may say that the check passes; the outcome is a repository in which it does.

Two measures of reliability. One trial proves little, because a model's output varies from run to run [86]. Two measures summarize several trials of the same task: pass@k, “the likelihood that an agent gets at least one correct solution in k attempts”, and pass^k, “the probability that all k trials succeed” [86]. If the trials are independent and each succeeds with probability p, the two measures follow equations (1) and (2).

With p = 0.75 and k = 3, equation (2) gives 0.75 × 0.75 × 0.75 = 0.421875, about 42%, computed as in Anthropic's worked example [86]. Equation (1) gives 1 − 0.25 × 0.25 × 0.25 = 0.984375 for the same values, about 98% (computed). The post puts it plainly: by k = 10 the two measures “tell opposite stories” [86].

Figure 11.1 draws both curves. Step through its presets, then move the sliders: worked once and works every time come apart within a few trials. Table 11.1 gives the same values without the drawing.

Building an eval. Anthropic separates two kinds: capability evals “should start at a low pass rate”, while regression evals, which check that the agent still handles the tasks it used to, should pass nearly every time [86]. Its advice for a first set is 20 to 50 simple tasks drawn from real failures [86]. The pass^k measure itself was introduced by tau-bench, a benchmark of tool-agent-user interaction published on 17 June 2024 [87].

While an agent's behavior is still being debugged, OpenAI advises starting from traces, scored by trace graders [32]. A dated caveat applies: OpenAI's deprecations page says existing evals become read-only on 31 October 2026, schedules the Evals dashboard and API to shut down on 30 November 2026, and includes the graders documented for eval workflows in that transition [16]. The trace-grading pages carry no such notice [32].

Keep the grader apart from the worker. Anthropic reports that agents asked to evaluate work they produced “tend to respond by confidently praising the work” [88]. Its harness for long-running application work splits the job between a planner, a generator and an evaluator [88]. In Task T the check plays the evaluator: it fails whatever the agent believes about its own edit.

Public benchmarks age too: Case 3, after this section, follows one that stopped measuring what it was built for.

Sources for §11: [20] [86] [19] [30] [87] [32] [16] [88], checked 4 October 2026. Back to contents.

Best practices both vendors agree on

The best practices that Anthropic and OpenAI both document form a short list: give the agent a check it can run, explore and plan before editing, keep instruction files short and load detail on demand, state what it may do alone, manage the context window, use a separate reviewer, and treat web and tool content as untrusted [20] [30].

After this section you can apply the practices that both vendors document, with the source for each side.

Each vendor publishes its own advice. Anthropic keeps a best-practices page in the Claude Code documentation [20]; OpenAI published a model guide for the GPT-6 family on 2 October 2026 [30] and keeps a prompting page in its Codex documentation [84]. Table 12.1 pairs them, one practice per row, with the source for each side.

On the first row the two pages agree in different words. Anthropic's page describes what a check gives the loop: “Claude does the work, runs the check, reads the result, and iterates until the check passes” [20]. OpenAI's guide asks for a definition of done that includes running the work and inspecting the result [30].

How sessions go wrong. Anthropic also names five failure patterns, each with its fix (Table 12.2) [20]. OpenAI documents one of them in its own terms, over-specification [30] [92]. It documents mid-run steering as a feature [84], which is not the same advice as Anthropic's restart after two failed corrections [20].

Sources for §12: [20] [30] [84] [17] [5] [47] [88] [32] [16] [91] [76] [77] [50] [86] [92] [53] [54], checked 4 October 2026. Back to contents.

Claude Code and Codex: how do they compare?

Claude Code (Anthropic) and Codex (OpenAI) are coding agents built on one idea: a harness that reads your repository, runs commands in an operating-system sandbox, edits files and checks its work, from a terminal, an editor, a desktop app or the cloud [5] [76]. Both can read AGENTS.md and hand routine approvals to an AI reviewer [17] [54] [4] [7]. Names and defaults differ.

After this section you can compare Claude Code and Codex on documented facts, and say what carries over from one to the other.

Both vendors describe their coding agent as a layer around a model. Claude Code's documentation calls Claude Code “the layer around the model that provides the tools and manages the context the model sees” [5]. On the OpenAI side, the Agents API, in public beta since 10 September 2026, exposes the harness and infrastructure that power Codex [13].

Table 13.1 sets the two side by side on what each vendor documents: Claude Code first, by alphabetical order, the same rows for both, and no row that ranks them. Product names and defaults change quickly; Case 4, after this section, collects the retirements that both vendors have dated.

Where they differ is mostly in the shape of control. Both put a sandbox and an approval layer around commands. Claude Code expresses the approval layer as one permission mode, with deny rules that hold in every mode, and keeps its sandbox as a separate layer [19] [27]; Codex pairs an approval policy, when to ask, with a sandbox mode, what commands can reach [76]. The two AI reviewers also read different inputs, and each vendor states what its choice costs. Anthropic strips tool outputs so that injected content cannot reach its classifier, and accepts that when the user never named an identifier, the classifier cannot tell whether the agent found it or made it up [4]. Codex's reviewer sees “a compact transcript plus the exact approval request”, which typically includes tool outputs; it can, rarely, run read-only checks to gather missing context, and hidden reasoning is not included [7].

What is the difference between Claude and Claude Code?

Claude is the model; Claude Code is the harness around it, as Claude Code's glossary puts it in one line: “Claude Code is the harness; Claude is the model inside it” [19]. The harness supplies “file access, shell execution, permission gating, memory loading, and the loop that chains actions together” [19]. Table 4.1 places Claude Code among the other ways each vendor runs a model as an agent.

Can you use both?

Yes, and much of a setup carries over. Claude Code reads AGENTS.md when a repository has no CLAUDE.md, from v2.1.277 [17]. Since 11 August 2026, the ChatGPT desktop app imports instructions, settings, skills, plugins, projects and recent work from Claude Code, Claude Cowork and Cursor, and the Codex CLI imports setup and recent chats from Claude Code and Cursor with /import [10].

Skills share one open format [56]. Both tools connect to MCP servers: Claude Code through its MCP configuration [5], Codex through mcp_servers.<id> entries in its configuration file [29].

Sources for §13: [5] [76] [17] [54] [4] [7] [13] [38] [56] [10] [19] [47] [3] [27] [82] [81] [20] [29] [93] [94] [31] [18] [11] [36] [95] [96] [42] [86] [89] [1], checked 4 October 2026. Back to contents.

What does an AI agent cost?

An AI agent costs tokens, and it uses many: every turn of the loop sends context again, tool outputs pile up and parallel agents multiply usage. Prompt caching, loading tools on demand and compaction bring the bill down. The useful unit is the cost of one successful task, not the cost of one call [98] [30].

After this section you can reason about the cost of an agent without a price list, in cost per successful task.

Where the tokens go. Anthropic reports that in its data, agents “typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats”^† [98]. In the same post, on its BrowseComp evaluation, Anthropic found that “token usage by itself explains 80% of the variance” in performance^† [98].

Parallel work multiplies the bill on both sides. Claude Code's documentation warns: “Running several sessions or subagents at once multiplies token usage” [57]. Codex's documentation says that subagent workflows “consume more tokens than comparable single-agent runs” [47].

What brings it down. Three mechanisms appear in both vendors' documentation. Prompt caching reuses the start of a prompt that repeats: Anthropic's cache covers the prompt prefix, in the order tools, system, then messages [50], and OpenAI's guide says to “Put stable instructions and reference material before changing task details” [30]. Loading tools on demand keeps their definitions out of the context: Anthropic reports that a typical multiserver setup can spend about 55k tokens on tool definitions before any work, and that tool search typically cuts this by over 85%^† [44]. OpenAI's Agents API also offers tool search [13]. Compaction replaces older turns with a summary, in beta on Anthropic's API [48] and automatic in OpenAI's Agents API [13] [41].

Both vendors bill cached input at a fraction of the normal input price, at rates that depend on the model [51] [30]. Prices change, so this page prints none; the rates are on the pages cited, each listed under References with the day it was read.

Effort. Effort trades depth for cost. Claude Code's glossary says: “Higher effort means more thinking tokens and deeper reasoning; lower effort is faster and cheaper” [19]. OpenAI's guide advises starting at the default effort, trying the highest levels only when high is not enough, and keeping them only if the gain justifies the time and cost [30].

The unit. OpenAI's guide asks for task success, latency and cost per successful task to be measured before an agent is deployed [30]. Written out, cost per successful task is equation (3):

Failed attempts stay in the numerator: they spend tokens and finish nothing. If every attempt costs the same and succeeds with the same probability p, the expected cost per successful task is the cost of one attempt divided by p (computed). Tokens are not the only cost: Case 5, after this section, adds availability.

Sources for §14: [98] [30] [57] [47] [50] [44] [13] [48] [41] [51] [19], checked 4 October 2026. Back to contents.

Who sets the standards for AI agents?

Several shared standards for AI agents now sit in the Agentic AI Foundation, a Linux Foundation fund formed on 9 December 2025 with MCP from Anthropic, goose from Block and AGENTS.md from OpenAI. A2A, for messages between agents, joined on 17 August 2026. Agent Skills is a separate open format that both vendors' tools adopted [8] [100] [56].

After this section you can place AGENTS.md, Agent Skills, MCP and A2A in one stack and say who stewards each.

On 9 December 2025 the Linux Foundation announced the Agentic AI Foundation (AAIF) with three founding projects: the Model Context Protocol (MCP) from Anthropic, goose from Block and AGENTS.md from OpenAI [8]. The announcement names eight platinum members: AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft and OpenAI [8].

Anthropic describes the AAIF as a directed fund of the Linux Foundation and says that MCP's governance stays with its maintainers [101]. OpenAI, announcing its part on the same day, says it released AGENTS.md in August 2025 [102].

A2A, the protocol for exchanges between agents, joined the AAIF on 17 August 2026; the foundation's post calls version 1.0 “the first stable specification”, shipped in March 2026 [100]. The specification site labels 1.0.0 its “Latest Released Version” [67], while the project's GitHub releases show 1.0.0 released on 12 March 2026 and 1.0.1 published on 28 May 2026 [103].

The AAIF projects page lists six projects: MCP, goose, AGENTS.md, agentgateway, A2A and Agent Router [104]. Table 15.1 stacks the shared formats by what they carry, from the instructions a repository gives an agent down to the traffic layer, with the steward and the version each source gives.

Agent Skills sits outside the foundation. Its site says the format was “originally developed by Anthropic, released as an open standard” [56]; Anthropic's open-standard note is dated 18 December 2025 [9], and the AAIF projects page does not list it [104]. The same site lists adopters including Claude Code, ChatGPT and Codex, GitHub Copilot, Cursor and Gemini CLI [56].

Public bodies work on a track of their own: on 17 February 2026 the US National Institute of Standards and Technology (NIST) announced the AI Agent Standards Initiative of its Center for AI Standards and Innovation (CAISI) [105].

Sources for §15: [8] [100] [56] [101] [102] [67] [103] [104] [9] [15] [105] [59] [53], checked 4 October 2026. Back to contents.

What does the EU AI Act say about agents?

The EU AI Act has no category called agent: it regulates AI systems by risk. Duties for general-purpose AI models have applied since 2 August 2025, transparency duties under Article 50 since 2 August 2026. The Digital Omnibus, in force since 27 July 2026, moved high-risk obligations to 2 December 2027 or 2 August 2028, by type of system [34] [14].

After this section you can say which AI Act dates apply after the Omnibus and where Luxembourg's implementing bill stands.

As adopted. Regulation (EU) 2024/1689, the AI Act, entered into force on 1 August 2024 [34]. Its prohibitions and its AI literacy duty have applied since 2 February 2025, and Chapter V, on general-purpose AI models, since 2 August 2025; its general date of application was 2 August 2026 [34].

No agent category. The act has no category called agent, and its definition of an AI system already covers systems designed to operate with “varying levels of autonomy” (Article 3(1)) [34]. An agent therefore falls under the same risk-based rules as any other AI system [34].

Article 50. Article 50(1) requires that people be told when they are interacting with an AI system, unless that is obvious, which concerns any agent that talks to customers [34]. Article 50(2) requires machine-readable marking of synthetic content [34].

The Digital Omnibus. Regulation (EU) 2026/1744, the Digital Omnibus on AI, was adopted on 8 July 2026, published in the Official Journal on 24 July 2026 and entered into force on the third day after publication, 27 July 2026 [14]. Under the act as adopted, the high-risk obligations were due on 2 August 2026 for the uses listed in Annex III and on 2 August 2027 for Annex I products [34]; the Omnibus moves them to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems [14]. It also changes four things that matter to anyone who builds or deploys agents:

• Marking. Generative systems placed on the market before 2 August 2026 get a four-month transition for the marking duty of Article 50(2), to 2 December 2026 [14].
• New prohibitions. Point (ba) of Article 5(1), first subparagraph, bans AI systems that generate or manipulate realistic intimate images, videos or audio of an identifiable person without explicit consent; point (bb) covers child sexual abuse material within the meaning of Article 2(c) and (e) of Directive 2011/93/EU. With the new paragraphs 1a and 1b of Article 5, they apply from 2 December 2026 (amended Article 113, point (a)) [14].
• AI literacy. Article 4 is rewritten: providers and deployers “shall take measures to support the development of AI literacy of their staff”, and of other persons who operate or use AI systems on their behalf [14].
• Supervision. The replaced Article 75(1) makes the AI Office “exclusively competent” for AI systems based on a general-purpose AI model when the model and the system come from the same provider or undertaking, with four listed exceptions (Annex I products, Annex III point 2, systems under Article 74(6), Annex III point 8 as regards justice), and for AI systems that constitute or are integrated into a very large online platform or search engine under Regulation (EU) 2022/2065 [14]. Read literally, the first case covers an agent product that a model provider builds on its own model, unless an exception applies [14].

Guidance and codes. Under the Commission's guidelines, a downstream modifier becomes a provider of a general-purpose AI model only if the modification uses more than one third of the original training compute [106]. In practice, building an agent on a vendor's API normally does not make you one [106].

The Code of Practice on Transparency of AI-generated Content, final since 10 June 2026, gives 2 August 2026 as the date from which the Article 50 obligations apply [107]. The Commission reported on 31 July 2026 that about 190 organizations had signed by the end of July, with Anthropic and OpenAI both listed under Section 1 [108]. Anthropic states that it marks text from its models released after 2 August 2026 with a watermark [109].

The Commission's AI Act page, updated on 3 August 2026, keeps the consolidated timeline [110]. Figure 16.1 sets the dates of the act as adopted and as amended on one timeline, and Table 16.1 lists the same milestones.

Who would supervise in Luxembourg?

Draft bill 8476, in committee. Everything under this heading describes a bill, not a law in force. Bill 8476 was filed on 23 December 2024 by Elisabeth Margue; the Chamber's page gives its status as “En commission”, with Félix Eischen as rapporteur [111].

The Conseil d'État adopted its opinion on 10 July 2026, with formal objections, for example on the competence of the CSSF under Article 74(6) of the AI Act and on legal certainty [112].

Article 7 of the draft would make the CNPD the default market surveillance authority, with carve-outs for other authorities; Article 13 would make it the single point of contact; Article 12 would let any competent authority set up a regulatory sandbox [113]. Table 16.2 sets out who would do what.

For readers in France, the CNIL published with the Conseil de l'IA et du Numérique (CIANum) an exploratory note, “IA agentique et données personnelles”, on 20 July 2026 [115]. Only its news page was read for this revision, so the note itself is not quoted here.

Sources for §16: [34] [14] [106] [107] [108] [109] [110] [111] [112] [113] [114] [115], checked 4 October 2026. Back to contents.