On 2 August 2026 the high-risk obligations in the EU AI Act became fully applicable: Articles 8 through 27, plus registration in the EU database. Legal teams spent the previous cycle assembling a description of "the AI system" so it could be filed as an object with a boundary, a purpose, logs, and a cybersecurity story.
This fortnight, production agent stacks are being asked to match that object. Architecture questionnaires ask what was registered, what the system does, how a human oversees it, and how you will know if the running copy has left the file.
Most post-deadline writing is about notified bodies, GPAI codes of practice, and which annex template to attach. That is checklist theater. It misses the architectural break. The Act's unit of regulation is a stable system. Production agents assemble third-party skills at invoke time. If the catalog of what actually ran is a README and a package name, Annex IV is a snapshot of a machine that no longer exists.
The registered system is not the skill graph
The technical file assumes a bounded system: intended purpose, architecture, components, data governance, human oversight, and the records that support post-market monitoring. The EU database then treats that description as the system in the field.
A production agent stack is not that description. The orchestrator you registered in June is still running. The skill graph around it is not the graph you drew. An engineer added an MCP server last Tuesday because a workflow needed calendar access. A portable skill from a public catalog landed in a repo because it filled a form faster than the in-house tool. A model router started calling a second provider after a latency spike. None of those events went through the release process that produced the technical file.
Two objects, not one:
- The registered system is the object in the file: purpose, architecture, oversight, logging design, cybersecurity measures.
- The runtime skill graph is every capability the agent can select at invoke time, including ones installed after the file was closed.
They diverge the first time someone adds a skill after registration.
Portable Skills Need Portable Trust was about installation friction: a capability that travels can enter an environment outside the original build. The Act now makes the same composition pattern a documentation problem. You cannot annex a moving graph by reprinting last quarter's component list. Legal will ask whether the registered system is still the system. Engineering will answer with a box around the orchestrator. Both will be describing different machines.
Annex IV photographed a boundary the stack does not keep
Annex IV wants a description of the AI system, how it was developed, how it is monitored, and how it is secured. It assumes you can point at the thing and explain how it stays inside its intended purpose.
A composed agent fails that assumption in ordinary operations. Purpose is declared at the orchestrator; skills imported later bring their own APIs and side effects. Architecture diagrams freeze at the model, the prompt store, and the tool adapter, and skip the third-party servers that adapter will call next week. Run logs show that a skill executed, not the capability claim, permission set, and liveness state in force at that invoke. Human oversight is designed around the registered workflow. A newly installed skill can open a path no reviewer has seen.
GPAI codes of practice and notified-body reviews still operate on a system you can describe once. If your production topology is an orchestrator plus an open catalog of installable skills, you do not have that unit. You have a composition engine. Photographing the engine in July does not describe what it assembled in August.
The board-level stake is simple: the EU database entry has to match the system that acted. A registration PDF is not that match.
Put live records next to every installable skill
The non-obvious move is not a thicker Annex IV. Stop treating identity, capability claims, permissions, and liveness as documentation you generate once for the file. Treat them as live operational records, the same way you would treat an SBOM: produced, stored, queried, and compared against what actually ran.
Require a live record beside every installable skill before that skill can be selected:
- Identity. Publisher, identifier, and version. Not a display name in a README. A handle you can resolve again at invoke time.
- Capability claims. Machine-readable, tight enough that a later invoke can be checked against the claim. "Helps with email" is not a claim. "sends mail via provider X; no mailbox delete" is.
- Permissions. Tokens, files, networks, and tools it may touch, and what the sandbox actually granted. If requested and effective differ, keep the effective set.
- Liveness. Whether the publisher, the endpoint, and the claimed version are still the ones you bound. Unreachable, redirected, or republished is a different component.
Pin those four records in the catalog the agent reads. Refuse the invoke if any record is missing, stale, or mismatched. Write the same four fields into the run log. That log is what you compare to the registered system.
You would not ship a container and then shrug at node_modules. Do not ship an agent and then shrug at the skills directory. Generate the records as runtime state, not as a compliance export the night before a filing. The catalog and the log have to be true at invoke.
Split the questionnaire this week
Stop answering "the system" as if it were a single binary. Split the answer:
- The registered system: orchestrator, models, intended purpose, human oversight path, logging design.
- The runtime skill graph: every installable skill, each with identity, capability, permission, and liveness records, plus the rule that invoke is denied without them.
- The drift process: when a skill is added, updated, or goes stale, the graph and the log change, and the registered description is marked out of date until someone accepts the new composition.
Freeze undocumented installs. A README in a skills folder is not a control. If the agent can call it, the four records exist, or the call does not happen. If you cannot query what ran last Tuesday, you cannot claim the registered system was still in force last Tuesday.
BluePages already stores AgentFacts, permission surfaces, sandbox boundaries, and liveness next to catalog entries, so the description you file can be checked against the skills the runtime actually selected. Use that, or keep the same records in your own registry; no skill in the graph without a live record.
August 2 filed a bounded system. Runtime composed past the frame. Photograph the graph on every invoke, or stop telling the file it is still looking at the same machine. If you are drafting the architecture response this week, start with those four records, not another annex template.