Google and OpenAI are teaching agents to obey files. That is the week's most important AI story because it moves the argument from cleverness to authority. Google says Managed Agents in the Gemini API can be defined in versionable markdown files such as AGENTS.md and SKILL.md; OpenAI says Codex reads AGENTS.md before doing work and lets enterprise administrators enforce requirements, defaults, approval policies and sandbox modes. [1] [2] [3] Thursday's paper argued that Google had made agent instructions into versioned files. Friday's evidence makes the point harder to dismiss. The convention is no longer one company's blog-post curiosity. It is becoming the operating grammar of agent work.

The old agent story was about capability: what can the model write, click, browse, test, summarize or repair? The new story is about jurisdiction. What file does it read first? Which instruction overrides another? Who can require approval before a shell command? Which domains may the sandbox reach? Which repository rule follows the agent into a worktree? Those questions sound like developer housekeeping only if one forgets that agents are supposed to act in systems where money, source code, secrets and liability live.

Google's Managed Agents post is explicit. With a single API call, a developer can spin up an Antigravity agent in an isolated, ephemeral Linux environment. The agent can reason, call tools, execute code, manage files and browse the web. Each interaction can create or receive an environment so files and state survive across follow-up calls. [1] The phrase that matters is not "agentic future." It is "environment." Google is selling not a chat window but a hosted place where work happens.

Inside that place, Google tells developers they can extend the agent with instructions and skills, defining everything in markdown files like AGENTS.md and SKILL.md instead of writing orchestration code. [1] A product manager could describe that as convenience. It is more than convenience. A file can be reviewed, diffed, signed off, searched in discovery, pinned in a release and blamed after a failure. A chat instruction disappears into product memory. A repository file becomes institutional memory.

OpenAI's Codex documentation now supplies the parallel architecture. Its AGENTS.md guide says Codex builds an instruction chain from global and project scopes, walking from the project root down to the current directory and merging files in order so closer guidance overrides earlier guidance. It reads AGENTS.override.md before AGENTS.md, respects fallback names, skips empty files and stops once the combined instruction size reaches the configured byte limit. [2] The document reads like a mundane manual until one sees what it is really doing: it is creating a legal order for software behavior.

That order has geography. A global file in a user's Codex home directory sets broad working agreements. A repository file sets project norms. A nested directory can override the wider rule for a specialized service. [2] This is how large organizations already govern people. The finance team has a playbook. The payments service has stricter rules. The database folder has commands one does not run casually. Codex is not inventing bureaucracy. It is absorbing bureaucracy into the agent's prompt stack.

OpenAI's enterprise governance document broadens the same logic. It says organizations need clear policy boundaries for developer agent usage across authentication, review, environments, internet access, data controls and auditability. [3] In the abstract, every technology vendor says governance. The concrete document is less airy. It puts the work in approvals, remote connections, sandboxing, managed configuration, user roles and review surfaces.

Managed configuration is the hard receipt. OpenAI says enterprise administrators can impose requirements that users cannot override and managed defaults that reapply when Codex launches. Requirements can constrain approval policy, approvals reviewer, automatic review policy, sandbox mode, web search mode, managed hooks and which MCP servers users can enable. If a local configuration conflicts with an enforced rule, Codex falls back to a compatible value and notifies the user. [4] This is not a faster bot. It is a policy appliance wrapped around a coding assistant.

The security-sensitive nouns are revealing. Approval policy determines when the agent must ask before acting. Sandbox mode determines how much of the filesystem or network it can touch. Web search mode determines whether live external information enters the run. Managed hooks let administrators insert policy checks into tool use. File deny-read rules let them prevent access to sensitive paths. [4] These controls are dull in the same way the lock on a medicine cabinet is dull. Their dullness is the point.

OpenAI also describes requirements precedence: cloud-managed requirements can outrank macOS managed preferences, which can outrank system files. Admins can assign policies to groups and cache cloud-managed requirements locally. [4] That is a hierarchy of power. The agent may be local enough to run in a developer's terminal, but the organization's rule can still arrive from the cloud and override the local wish. The coding assistant becomes a site where enterprise administration, model behavior and developer autonomy meet.

Jules sits between the two worlds. Google's Jules post sells an asynchronous coding agent in public beta, integrated with existing repositories, cloning code into a secure Google Cloud virtual machine, presenting plans and diffs, and offering GitHub integration, steerability and audio changelogs. [5] It is a friendlier document than the OpenAI governance pages. But its structure is similar. Code leaves the developer's immediate machine for a managed environment. The agent produces a plan before changes. Work returns as a diff. Control is expressed through workflow rather than conversation.

That is why the divergence matters. Mainstream technology coverage can still report these as product moves after Google I/O or as another round in the coding-agent contest. X, especially the developer portion of it, notices a lower layer: repository instructions, tool permissions, sandbox walls, browser approvals, file provenance, managed defaults. Neither frame is complete alone. Product competition explains why the documents exist. Governance explains why the documents matter.

There is a democratic version of this story and a corporate version. The democratic version says files make power visible. If an agent's instruction lives in a repository, a team can debate it in a pull request. A junior engineer can see why the agent keeps running tests before editing. A security reviewer can ask why network access was allowed. A future investigator can reconstruct what the agent was told. This is better than behavioral policy trapped inside a black-box prompt box.

The corporate version says the same files can become a standard-shaped moat. If enough teams write AGENTS.md in the way a vendor expects, the vendor gains leverage over the grammar of automated work. If managed defaults arrive from the vendor's cloud, the enterprise may get safety while the platform gets tenancy. If a hosted sandbox becomes the natural place for agent action, the provider owns the workplace. Convenience is rarely neutral after it becomes habit.

One should not overstate the novelty. Software teams have long used configuration files to govern tools: linters, formatters, CI scripts, deployment manifests, Dockerfiles, editor settings, access policies. The agent-file moment is important precisely because it puts agent behavior into that older lineage. The question is whether artificial intelligence remains a conversation with a model or becomes another governed part of the software supply chain.

The answer is moving quickly toward the supply chain. Google's post says managed agents can browse the web, execute code and manage files inside a sandbox. [1] OpenAI's AGENTS.md document says Codex discovers guidance before doing any work. [2] Its managed-configuration document says administrators can limit what approval policies, sandbox modes, web search modes and MCP servers are available. [4] Those facts belong together. The agent is no longer only a language model. It is a regulated actor in a technical environment.

The human consequences are not abstract. A developer asked to use a coding agent at work will soon ask who owns the instruction file, who approves a change to it, whether the agent may read production logs, whether a customer's data can enter its context, whether its web search can reach unapproved domains, and whether a mistake is the user's fault, the model's fault, the repository owner's fault or the administrator's fault. The governance files do not answer every question. They make the questions legible.

The paper has been skeptical of agent theater because theater ages badly. Demos fail; benchmark leads vanish; every assistant eventually writes a bad patch. Files age differently. A file can become boring, and boring is how infrastructure wins. The repo that once had a README later has a CI file, a security policy, a deployment manifest and now an agent instruction file. The presence of the file changes what a team assumes work is.

That is the shift. Google and OpenAI are not merely launching agents. They are placing agents under documents ordinary organizations know how to fight about. The result may be safer. It may be more auditable. It may also be more centralized than the open-file vocabulary suggests. But it is a real change in the surface where power appears. The future of agents may be decided less by the model that talks best than by the file that tells it when to stop.

-- ANNA WEBER, Berlin