In this blog post AGENTS.md The One File That Turns AI Coding Tools Into Team Players we will explore how a single, plain-text file can make AI coding tools more predictable, safer, and far more useful across real-world engineering teams.
AGENTS.md The One File That Turns AI Coding Tools Into Team Players is exactly what it sounds like: a dedicated, predictable place in your repository where you tell AI coding agents how your project works, how to validate changes, and what “good” looks like. Think of it as onboarding notes for an AI teammate—written once, used every time. The format is intentionally simple (it’s just Markdown), and it’s designed to work across a growing ecosystem of coding agents and tools. (agents.md)
Over the last year, AGENTS.md has moved from “nice idea” to “practical standard”. OpenAI’s Codex explicitly supports being guided by AGENTS.md files inside repos, and GitHub’s Copilot coding agent added support for AGENTS.md custom instructions, including nested files for different parts of a codebase.
What is AGENTS.md in plain terms
AGENTS.md is a convention: create a file called AGENTS.md in your repo (usually at the root), write instructions that help an AI agent work effectively, and commit it like any other documentation.
It complements human-focused docs like README.md. A README is for people skimming a project. AGENTS.md is for agents that need step-by-step operational details: which commands to run, which tests matter, what style rules you enforce, and what to avoid. (agents.md)
Why one file makes such a big difference
Most frustration with AI coding tools isn’t that they can’t write code. It’s that they don’t reliably behave like your team:
- They run the wrong commands (or none at all).
- They miss critical conventions (“we never use default exports here”).
- They change files they shouldn’t (like generated code or lockfiles).
- They produce PRs that fail CI and waste review time.
AGENTS.md addresses this by giving the agent a stable source of truth it can read before it starts making changes. Instead of you repeating the same instructions in every prompt, the repo carries its own “operating manual”.
The technology behind it
There isn’t a special parser, schema, or API required. The “technology” is a deliberately boring combination of:
- Markdown as a universal interface: easy to write, review, diff, and keep close to code.
- Tooling that looks for a predictable filename: AI coding agents can automatically search for
AGENTS.mdand treat it as instructions. - Directory scope rules: some agents define that an AGENTS.md applies to the directory tree it lives in, and nested AGENTS.md files can override or refine instructions for submodules or packages.
This is similar in spirit to how .editorconfig made code formatting more consistent across editors. The file itself is simple. The value comes from tools agreeing to respect it.
What agents actually do with it
When an agent starts a task, it typically gathers context: repository structure, key docs, and any “instruction files”. If it finds AGENTS.md, it can use it to:
- Choose the correct build/test commands.
- Follow code style and architectural boundaries.
- Apply repo-specific PR and commit expectations.
- Reduce risky guesswork (“don’t touch production Terraform without approval”).
OpenAI describes Codex as able to read/edit files and run commands like tests and linters, and notes that Codex can be guided by AGENTS.md to navigate and adhere to project practices.
What to put in an AGENTS.md that actually helps
A good AGENTS.md reads like what you’d tell a senior contractor on day one: “Here’s how we work. Here’s how to prove your change is correct.”
Recommended sections
- Project overview: a short, plain-English map of the repo.
- Setup commands: how to install dependencies and run the app.
- Test and validation: which commands must be run before proposing changes.
- Code style: formatting, naming, lint rules, patterns to follow or avoid.
- Safe change boundaries: files/dirs that are generated, vendor, or off-limits.
- PR and commit guidance: title format, what to include in descriptions, what evidence to attach.
- Security notes: secrets handling, logging rules, data access constraints.
The AGENTS.md project itself suggests focusing on practical details like build steps, tests, and conventions—things that may clutter a README but are critical for an agent to be effective.
A practical starter template you can copy
Here’s a template that works well for typical cloud-native repos (Node/Python/Java/.NET) and scales to enterprise expectations.
# AGENTS.md
## What this repo is
- This service: <one sentence>
- Key directories:
- /src: application code
- /infra: IaC (Terraform)
- /docs: architecture notes
## Setup
- Install deps: <command>
- Run locally: <command>
- Required env vars:
- EXAMPLE_API_URL (non-prod only)
## How to validate changes
- Always run (required):
- <lint command>
- <unit test command>
- If you touch the API layer, also run:
- <integration test command>
## Code style and patterns
- Follow existing conventions in the touched module.
- Prefer small, testable functions.
- Do not introduce new dependencies without explaining why.
## Guardrails
- Do not modify generated files in /dist or /build.
- Do not change Terraform in /infra without explicit request.
- Never add secrets to code, tests, docs, or logs.
## PR expectations
- PR description must include:
- What changed
- Why
- How you tested (paste command output summary)
- Keep PRs focused: one logical change per PR.
Nested AGENTS.md for monorepos and multi-team platforms
If you maintain a monorepo, a single root instruction file is rarely enough. The trick is to keep high-level rules at the root, and put package-specific instructions closer to the code.
This nested approach is explicitly supported by tools in the ecosystem: you can place AGENTS.md in subdirectories so instructions apply to specific parts of the repo. GitHub’s Copilot coding agent calls out nested files, and the AGENTS.md site also describes using nested files so the nearest one in the directory tree takes precedence.
How to structure it
- /AGENTS.md: org-wide standards, security rules, PR expectations.
- /services/payments/AGENTS.md: domain rules, local run commands, test focus.
- /frontend/AGENTS.md: linting, formatting, component patterns, storybook steps.
How to roll it out without annoying your team
- Start with pain: add only what repeatedly goes wrong (tests, lint, build, PR format).
- Keep it short: aim for one screen before you add edge cases.
- Make it verifiable: prefer commands and checklists over opinions.
- Review it like code: require PR review for changes to AGENTS.md.
- Iterate from failures: when an agent messes up, add one clarifying bullet.
Common mistakes and quick fixes
- Mistake: vague instructions
Fix: replace “run tests” with exact commands and when to use them. - Mistake: conflicting rules across files
Fix: add a “source of truth” note at the root and keep nested files scoped to local differences. - Mistake: turning it into a policy document
Fix: link to existing policies in your repo docs, but keep AGENTS.md operational. - Mistake: forgetting security boundaries
Fix: explicitly list directories that contain secrets, prod configs, customer data, or regulated logic.
Why tech leaders should care
If you’re leading engineering, AGENTS.md is a leverage point. It improves consistency across:
- Quality: fewer CI failures and less “works on my machine” drift.
- Security: clearer constraints on what automation should not touch.
- Velocity: faster handoffs when multiple people (and agents) touch the same repo.
- Governance: reviewable, auditable instructions that live with the code.
It also reduces vendor lock-in. Because AGENTS.md is just Markdown and is being adopted across multiple tools, you can switch agents without rewriting your “how we build software here” playbook.