AGENTS.md Design Guide: Multi-Agent Context Isolation and Permission Delegation Patterns

Have you ever assigned "refactor this entire repo" to a single AI agent, only to watch the context window hit its limit or the agent suddenly start modifying completely unrelated files? I ran into that myself early on, cramming everything into a single agent and ending up in some frustrating situations. After adopting multi-agent orchestration, the quality and reliability of my work improved noticeably.

The essence of a multi-agent system is clearly defining "who knows what, and who can do what." The container for that definition is AGENTS.md. This article walks through designing AGENTS.md hierarchically to cleanly isolate context between orchestrators and sub-agents, and safely delegate role-based permissions — with code examples throughout.

Major AI coding tools like Claude Code, Cursor, GitHub Copilot, and Gemini CLI already support AGENTS.md, so mastering these patterns now means you can apply them immediately regardless of which toolchain you use.

Core Concepts

AGENTS.md — A README for Agents

AGENTS.md is a markdown file that conveys project context and behavioral rules to coding agents. If a README is documentation for human developers, think of AGENTS.md as documentation for AI agents. You write it in plain markdown with no special schema or YAML frontmatter, and the AGENTS.md closest to the file the agent is trying to edit takes precedence.

It may look like a simple rules file, but in a multi-agent system each layer's AGENTS.md acts like that agent's "constitution." The orchestrator's AGENTS.md holds the big picture of the entire system and the agent registry, while a sub-agent's AGENTS.md contains narrow, deep rules focused solely on its domain.

The Orchestrator-Worker Pattern

The most widely used multi-agent structure in practice. Think of it like a project manager assigning roles to team members and aggregating their results. A central orchestrator receives user requests, breaks them into subtasks, routes each to a specialized worker agent, and aggregates the results.

sql

User Request
    │
    ▼
┌─────────────────────────┐
│       Orchestrator       │  ← Task decomposition, routing, result aggregation
│  (maintains full context)│
└─────────────────────────┘
    │           │           │
    ▼           ▼           ▼
┌────────┐ ┌────────┐ ┌────────┐
│  Code  │ │  Test  │ │Security│  ← Each runs independently in its own context
│  Gen   │ │ Runner │ │Auditor │
│ Agent  │ │ Agent  │ │ Agent  │
└────────┘ └────────┘ └────────┘
    │           │           │
    └───────────┴───────────┘
          Returns summary only

The key point here is that when a sub-agent finishes its work, the entire exploration history is isolated within the sub-agent's context, and only the final summary is passed up to the orchestrator. This keeps the orchestrator's context window clean.

Context Isolation — Why It Matters

Every time a sub-agent is spawned, a fresh context window (e.g., 200K tokens for Claude) is allocated. If this isolation structure isn't designed properly, the orchestrator burns context on unnecessary intermediate exploration logs, and output quality degrades toward the end of the context — a phenomenon commonly called "Context Rot." Parallel sub-agents can also interfere with each other's state.

For these reasons, "context engineering" emerged as a more important topic in the industry than "prompt engineering" throughout 2025–2026. The core is designing which tokens to give the model and when. Rather than loading all context at agent initialization, "Progressive Disclosure" — providing only the information needed for the current step, incrementally — has become the standard solution. Specific implementations have actually reported significant reductions in token usage while maintaining quality.

Role-Based Permission Delegation Patterns

Agent permission design follows three core principles:

Principle	Description
Delegated Access	Agents inherit user tokens and maintain the user's permission level in real time
Unique Agent ID	Each agent is assigned a non-shared identifier so every action can be audit-traced
Context-Aware Permissions	Dynamic exchange instead of static inheritance, trimming child credentials to match conditions

Statically inheriting permissions follows the logic of "if the parent can do it, the child can too" — which is quite risky in practice. Just because the orchestrator has permission to delete from the DB doesn't mean that permission should flow down to the code generation sub-agent. That's why context-aware permission design is necessary.

Practical Application

Example 1: Designing a Hierarchical AGENTS.md Directory Structure

The most commonly used structure places global rules at the root and domain-specific rules in subdirectories.

python

/AGENTS.md                  # Global: tech stack, architecture principles, agent registry
/agents/
  code-reviewer.md          # Code review sub-agent definition
  test-runner.md            # Test execution sub-agent definition
  security-auditor.md       # Security audit sub-agent definition
/src/AGENTS.md              # Source code writing rules (references global rules + additions)
/docs/AGENTS.md             # Documentation rules

How does inheritance work? AGENTS.md "inheritance" is not the framework automatically merging files. Instead, the agent walks up from the target file toward the root and directly reads each directory's AGENTS.md. Writing "inherits from /AGENTS.md" in /src/AGENTS.md clearly communicates the intent that the agent should reference both files.

Here is an example root AGENTS.md:

markdown

# Project: MyApp
 
## Tech Stack
- Runtime: Node.js 22, TypeScript 5.x
- Framework: NestJS (backend), Next.js 15 (frontend)
- DB: PostgreSQL 16, Redis 7
 
## Architecture Principles
- Business logic goes in the Service layer only
- Keep controllers thin
- All external input must be validated via DTOs
 
## Agent Registry
| Agent | Role | Entry Point |
|-------|------|-------------|
| code-reviewer | PR review and code quality checks | /agents/code-reviewer.md |
| test-runner | Test execution and coverage analysis | /agents/test-runner.md |
| security-auditor | Security vulnerability audit (read-only) | /agents/security-auditor.md |
 
## Global Prohibitions
- No direct queries to the production DB
- No modifying .env files
- No direct pushes to main/master branches

/src/AGENTS.md references the root rules and adds only rules specific to writing source code:

markdown

# Source Code Rules (inherits from /AGENTS.md)
 
## Code Style
- 2-space indentation
- async/await (not .then())
- TypeScript strict mode required
 
## File Structure Rules
- Service files: *.service.ts
- Controller files: *.controller.ts
- DTO files: dto/*.dto.ts
 
## Permitted Actions in This Directory
- Read/write files under src/
- Create new modules
 
## Prohibited Actions in This Directory
- Directly modifying test files (*.spec.ts)
- Modifying DB migration files

Item	Root AGENTS.md	Subdirectory AGENTS.md
Scope	Project-wide common rules	Domain-specific rules
Agent Registry	Included (full agent list)	Not included
Permission Definitions	Global allow/deny list	Domain-level detailed permissions
Recommended Length	Under 100 lines	Under 50 lines

Example 2: Writing Role-Based Permission-Separated AGENTS.md

For each sub-agent's AGENTS.md, it's important to clearly define what that agent can and cannot do. Honestly, at first I thought "can't I just write it in the prompt?" — but separating it into AGENTS.md means the agent loads that file before starting work and internalizes its own boundaries, resulting in far greater consistency.

One thing worth saying upfront: the allow/deny rules defined in AGENTS.md are declarative commitments. The agent reads this file and follows it through its own judgment — there is no runtime-level mechanism that forcibly blocks violations. For production environments, it's recommended to pair AGENTS.md rules with runtime-level permission restrictions such as sandboxing or tool filtering.

markdown

# Security Auditor Agent
 
## Role
Detects security vulnerabilities in the codebase and generates reports.
Analyzes based on the OWASP Top 10; provides remediation suggestions only and does not apply actual fixes.
 
## Permitted Actions
- Read all source files (read-only)
- Analyze dependency files (package.json, pom.xml, etc.)
- Create security report files (in reports/ directory only)
- Query external CVE databases (read)
 
## Absolute Prohibitions
- Modifying or deleting source files
- Accessing configuration files (.env, config/)
- Network connections (except CVE DB queries)
- Spawning other agents
 
## Output Format
Results must be returned in the following structure:
{
  "severity": "critical|high|medium|low",
  "location": "file-path:line-number",
  "description": "Vulnerability description",
  "cwe": "CWE-XXX",
  "recommendation": "Remediation direction (without directly modifying code)"
}

markdown

# Code Generation Agent
 
## Role
Generates source code for new features as directed by the orchestrator.
 
## Permitted Actions
- Read/write files under the src/ directory
- Create new files (inside src/ only)
- Modify type definition files (src/types/)
- Install pnpm packages (excluding devDependencies)
 
## Absolute Prohibitions
- Modifying files outside src/
- Changing DB schemas (no access to migrations/)
- Modifying environment variable files (.env*)
- Modifying test files (*.spec.ts, *.test.ts)
- Directly calling other agents
 
## Return Format on Completion
Return only a summary when the task is done:
- List of created/modified files
- Summary of key changes in 3 lines or fewer
- Next steps needed (if any)

Example 3: Hierarchical Orchestration Design (3-Tier)

A 3-tier structure that is more effective in practice than a simple 1:N setup. Instead of an orchestrator directly managing 6 sub-agents, feature lead agents coordinate their own specialists. The key is keeping the orchestrator's context much lighter.

bash

Orchestrator (context: full task plan only)
├── Feature Lead A: User Authentication
│   ├── Frontend Specialist (src/components/auth/)
│   └── API Specialist (src/modules/auth/)
└── Feature Lead B: Payment
    ├── DB Specialist (migrations/, src/repositories/)
    └── Test Specialist (test/payment/)

Orchestrator AGENTS.md:

markdown

# Orchestrator Agent
 
## Role
Analyzes user requests and delegates to feature lead agents.
Does not directly write code or modify files.
 
## Task Decomposition Principles
1. Break the request into independent functional units
2. Select the feature lead agent responsible for each function
3. Deliver instructions to the feature lead with a clear interface contract (input/output)
4. Integrate results and mediate conflicts
 
## Permitted Actions
- File reading (full scope, for exploration purposes)
- Spawning feature lead agents
- Writing integrated result reports
 
## Absolute Prohibitions
- Directly modifying/deleting files
- Directly calling external APIs
- DB access
- Storing sub-agent results in full in context (receive summaries only)
 
## Context Management Rules
- When spawning sub-agents, pass only necessary information (Progressive Disclosure)
- Do not include sub-agent exploration history in context
- Aggregate only the final summary from each feature lead

Feature lead agent AGENTS.md coordinates within a narrower scope than the orchestrator:

markdown

# Feature Lead Agent: Auth
 
## Role
Coordinates implementation of the user authentication feature.
Spawns frontend and API specialists and integrates their results.
 
## Scope
- src/components/auth/ (frontend)
- src/modules/auth/ (backend API)
 
## Permitted Actions
- Read files within scope
- Spawn frontend specialist and API specialist
- Validate interface contracts (check input/output type consistency)
 
## Absolute Prohibitions
- Modifying files outside scope
- Directly accessing DB schemas
- Interfering with other feature leads' areas

Pros and Cons Analysis

Advantages

Item	Detail
Clean Context	Sub-agent isolation prevents orchestrator context pollution; each agent focuses on a single responsibility
Parallel Execution	Independent subtasks run simultaneously, reducing total processing time
Clear Audit Trail	Each agent has a single role, making every step's output clear and verifiable
Least Privilege	Granting each agent only the permissions it needs reduces the security threat surface
Modular Reuse	Hierarchical AGENTS.md structure enables rule reference, override, and deduplication

Disadvantages and Caveats

Item	Detail	Mitigation
Rapid Token Cost Increase	Multi-agent consumes 4–15× more tokens than a single agent	Use Progressive Disclosure to load only necessary context
AGENTS.md Bloat	Performance degrades past 150–200 lines; LLM-generated AGENTS.md lowers success rate and increases cost	Keep files short and clear; write them by hand
Context Rot	Excessive context degrades output quality	Load context incrementally; exclude unnecessary intermediate results
Nesting Restrictions	Some environments prevent sub-agents from directly spawning other sub-agents	Design the orchestrator to centrally manage all spawning
Handoff Guardrail Gaps	OpenAI Agents SDK does not apply tool guardrails to handoff calls themselves	Add separate input/output validation logic before and after handoffs
Rule Conflicts	Conflicts between parent/child rules in hierarchical AGENTS.md lead to unpredictable behavior	Write explicit priority rules ("rules in this file take precedence over root")
Single Point of Failure	Orchestrator failure halts the entire system	Periodically persist orchestrator state externally; design a restart strategy

Most Common Mistakes in Practice

Writing AGENTS.md in excessive detail: Counter to the intuition that "more rules = better results," longer AGENTS.md files actually degrade performance. Research shows that LLM-generated AGENTS.md lowers task success rates and increases costs. Keep it to only the essential rules, written concisely, and it's recommended to write it by hand.
Overloading the orchestrator: When the orchestrator starts exploring files and writing code directly, its context fills up fast and it loses the capacity to delegate to sub-agents. It's recommended that the orchestrator focus solely on the "conductor" role and delegate actual work to sub-agents.
Deferring permission design: The "make it work first, then restrict permissions later" approach doesn't actually work well. Defining each agent's allow and deny lists from the start makes debugging much easier and prevents accidental file modifications or privilege abuse incidents.

Closing Thoughts

The essence of AGENTS.md is not accumulating many rules — it's designing responsibility boundaries so each agent clearly knows "what I should do and what I must not do."

Three steps you can start with right now:

Create the root file: Create /AGENTS.md at your existing project root and write only three things — tech stack, architecture principles, and global prohibitions — in under 50 lines. If you're using a tool like Claude Code or Cursor, the file is recognized the moment you create it.
Write role files: Pick one task you assign repeatedly (code review, test execution, etc.) and write /agents/[role-name].md. Just two sections — "Permitted Actions" and "Absolute Prohibitions" — is enough to get started.
Add context management rules: Add a rule to the orchestrator agent's AGENTS.md like "on completion, return only a summary without sub-agent exploration history," and you should notice a visible improvement in context efficiency.

Next article: Once you want to implement the inter-agent role boundaries discussed here at the protocol level, you inevitably reach a fork in the road of standard selection — the differences between MCP (Model Context Protocol) and A2A (Agent-to-Agent) protocol, and how to combine the two standards, will be covered next.

References

AGENTS.md Design Guide: Multi-Agent Context Isolation and Permission Delegation Patterns | DEV BAK - 기술블로그

AGENTS.md Design Guide: Multi-Agent Context Isolation and Permission Delegation Patterns

Core Concepts

AGENTS.md — A README for Agents

The Orchestrator-Worker Pattern

sql

User Request
    │
    ▼
┌─────────────────────────┐
│       Orchestrator       │  ← Task decomposition, routing, result aggregation
│  (maintains full context)│
└─────────────────────────┘
    │           │           │
    ▼           ▼           ▼
┌────────┐ ┌────────┐ ┌────────┐
│  Code  │ │  Test  │ │Security│  ← Each runs independently in its own context
│  Gen   │ │ Runner │ │Auditor │
│ Agent  │ │ Agent  │ │ Agent  │
└────────┘ └────────┘ └────────┘
    │           │           │
    └───────────┴───────────┘
          Returns summary only

Context Isolation — Why It Matters

Role-Based Permission Delegation Patterns

Agent permission design follows three core principles:

Principle	Description
Delegated Access	Agents inherit user tokens and maintain the user's permission level in real time
Unique Agent ID	Each agent is assigned a non-shared identifier so every action can be audit-traced
Context-Aware Permissions	Dynamic exchange instead of static inheritance, trimming child credentials to match conditions

Practical Application

Example 1: Designing a Hierarchical AGENTS.md Directory Structure

The most commonly used structure places global rules at the root and domain-specific rules in subdirectories.

python

/AGENTS.md                  # Global: tech stack, architecture principles, agent registry
/agents/
  code-reviewer.md          # Code review sub-agent definition
  test-runner.md            # Test execution sub-agent definition
  security-auditor.md       # Security audit sub-agent definition
/src/AGENTS.md              # Source code writing rules (references global rules + additions)
/docs/AGENTS.md             # Documentation rules

How does inheritance work? AGENTS.md "inheritance" is not the framework automatically merging files. Instead, the agent walks up from the target file toward the root and directly reads each directory's AGENTS.md. Writing "inherits from /AGENTS.md" in /src/AGENTS.md clearly communicates the intent that the agent should reference both files.

Here is an example root AGENTS.md:

markdown

# Project: MyApp
 
## Tech Stack
- Runtime: Node.js 22, TypeScript 5.x
- Framework: NestJS (backend), Next.js 15 (frontend)
- DB: PostgreSQL 16, Redis 7
 
## Architecture Principles
- Business logic goes in the Service layer only
- Keep controllers thin
- All external input must be validated via DTOs
 
## Agent Registry
| Agent | Role | Entry Point |
|-------|------|-------------|
| code-reviewer | PR review and code quality checks | /agents/code-reviewer.md |
| test-runner | Test execution and coverage analysis | /agents/test-runner.md |
| security-auditor | Security vulnerability audit (read-only) | /agents/security-auditor.md |
 
## Global Prohibitions
- No direct queries to the production DB
- No modifying .env files
- No direct pushes to main/master branches

/src/AGENTS.md references the root rules and adds only rules specific to writing source code:

markdown

# Source Code Rules (inherits from /AGENTS.md)
 
## Code Style
- 2-space indentation
- async/await (not .then())
- TypeScript strict mode required
 
## File Structure Rules
- Service files: *.service.ts
- Controller files: *.controller.ts
- DTO files: dto/*.dto.ts
 
## Permitted Actions in This Directory
- Read/write files under src/
- Create new modules
 
## Prohibited Actions in This Directory
- Directly modifying test files (*.spec.ts)
- Modifying DB migration files

Item	Root AGENTS.md	Subdirectory AGENTS.md
Scope	Project-wide common rules	Domain-specific rules
Agent Registry	Included (full agent list)	Not included
Permission Definitions	Global allow/deny list	Domain-level detailed permissions
Recommended Length	Under 100 lines	Under 50 lines

Example 2: Writing Role-Based Permission-Separated AGENTS.md

markdown

# Security Auditor Agent
 
## Role
Detects security vulnerabilities in the codebase and generates reports.
Analyzes based on the OWASP Top 10; provides remediation suggestions only and does not apply actual fixes.
 
## Permitted Actions
- Read all source files (read-only)
- Analyze dependency files (package.json, pom.xml, etc.)
- Create security report files (in reports/ directory only)
- Query external CVE databases (read)
 
## Absolute Prohibitions
- Modifying or deleting source files
- Accessing configuration files (.env, config/)
- Network connections (except CVE DB queries)
- Spawning other agents
 
## Output Format
Results must be returned in the following structure:
{
  "severity": "critical|high|medium|low",
  "location": "file-path:line-number",
  "description": "Vulnerability description",
  "cwe": "CWE-XXX",
  "recommendation": "Remediation direction (without directly modifying code)"
}

markdown

# Code Generation Agent
 
## Role
Generates source code for new features as directed by the orchestrator.
 
## Permitted Actions
- Read/write files under the src/ directory
- Create new files (inside src/ only)
- Modify type definition files (src/types/)
- Install pnpm packages (excluding devDependencies)
 
## Absolute Prohibitions
- Modifying files outside src/
- Changing DB schemas (no access to migrations/)
- Modifying environment variable files (.env*)
- Modifying test files (*.spec.ts, *.test.ts)
- Directly calling other agents
 
## Return Format on Completion
Return only a summary when the task is done:
- List of created/modified files
- Summary of key changes in 3 lines or fewer
- Next steps needed (if any)

Example 3: Hierarchical Orchestration Design (3-Tier)

bash

Orchestrator (context: full task plan only)
├── Feature Lead A: User Authentication
│   ├── Frontend Specialist (src/components/auth/)
│   └── API Specialist (src/modules/auth/)
└── Feature Lead B: Payment
    ├── DB Specialist (migrations/, src/repositories/)
    └── Test Specialist (test/payment/)

Orchestrator AGENTS.md:

markdown

# Orchestrator Agent
 
## Role
Analyzes user requests and delegates to feature lead agents.
Does not directly write code or modify files.
 
## Task Decomposition Principles
1. Break the request into independent functional units
2. Select the feature lead agent responsible for each function
3. Deliver instructions to the feature lead with a clear interface contract (input/output)
4. Integrate results and mediate conflicts
 
## Permitted Actions
- File reading (full scope, for exploration purposes)
- Spawning feature lead agents
- Writing integrated result reports
 
## Absolute Prohibitions
- Directly modifying/deleting files
- Directly calling external APIs
- DB access
- Storing sub-agent results in full in context (receive summaries only)
 
## Context Management Rules
- When spawning sub-agents, pass only necessary information (Progressive Disclosure)
- Do not include sub-agent exploration history in context
- Aggregate only the final summary from each feature lead

Feature lead agent AGENTS.md coordinates within a narrower scope than the orchestrator:

markdown

# Feature Lead Agent: Auth
 
## Role
Coordinates implementation of the user authentication feature.
Spawns frontend and API specialists and integrates their results.
 
## Scope
- src/components/auth/ (frontend)
- src/modules/auth/ (backend API)
 
## Permitted Actions
- Read files within scope
- Spawn frontend specialist and API specialist
- Validate interface contracts (check input/output type consistency)
 
## Absolute Prohibitions
- Modifying files outside scope
- Directly accessing DB schemas
- Interfering with other feature leads' areas

Pros and Cons Analysis

Advantages

Item	Detail
Clean Context	Sub-agent isolation prevents orchestrator context pollution; each agent focuses on a single responsibility
Parallel Execution	Independent subtasks run simultaneously, reducing total processing time
Clear Audit Trail	Each agent has a single role, making every step's output clear and verifiable
Least Privilege	Granting each agent only the permissions it needs reduces the security threat surface
Modular Reuse	Hierarchical AGENTS.md structure enables rule reference, override, and deduplication

Disadvantages and Caveats

Item	Detail	Mitigation
Rapid Token Cost Increase	Multi-agent consumes 4–15× more tokens than a single agent	Use Progressive Disclosure to load only necessary context
AGENTS.md Bloat	Performance degrades past 150–200 lines; LLM-generated AGENTS.md lowers success rate and increases cost	Keep files short and clear; write them by hand
Context Rot	Excessive context degrades output quality	Load context incrementally; exclude unnecessary intermediate results
Nesting Restrictions	Some environments prevent sub-agents from directly spawning other sub-agents	Design the orchestrator to centrally manage all spawning
Handoff Guardrail Gaps	OpenAI Agents SDK does not apply tool guardrails to handoff calls themselves	Add separate input/output validation logic before and after handoffs
Rule Conflicts	Conflicts between parent/child rules in hierarchical AGENTS.md lead to unpredictable behavior	Write explicit priority rules ("rules in this file take precedence over root")
Single Point of Failure	Orchestrator failure halts the entire system	Periodically persist orchestrator state externally; design a restart strategy

Most Common Mistakes in Practice

Writing AGENTS.md in excessive detail: Counter to the intuition that "more rules = better results," longer AGENTS.md files actually degrade performance. Research shows that LLM-generated AGENTS.md lowers task success rates and increases costs. Keep it to only the essential rules, written concisely, and it's recommended to write it by hand.
Overloading the orchestrator: When the orchestrator starts exploring files and writing code directly, its context fills up fast and it loses the capacity to delegate to sub-agents. It's recommended that the orchestrator focus solely on the "conductor" role and delegate actual work to sub-agents.
Deferring permission design: The "make it work first, then restrict permissions later" approach doesn't actually work well. Defining each agent's allow and deny lists from the start makes debugging much easier and prevents accidental file modifications or privilege abuse incidents.

Closing Thoughts

The essence of AGENTS.md is not accumulating many rules — it's designing responsibility boundaries so each agent clearly knows "what I should do and what I must not do."

Three steps you can start with right now:

Create the root file: Create /AGENTS.md at your existing project root and write only three things — tech stack, architecture principles, and global prohibitions — in under 50 lines. If you're using a tool like Claude Code or Cursor, the file is recognized the moment you create it.
Write role files: Pick one task you assign repeatedly (code review, test execution, etc.) and write /agents/[role-name].md. Just two sections — "Permitted Actions" and "Absolute Prohibitions" — is enough to get started.
Add context management rules: Add a rule to the orchestrator agent's AGENTS.md like "on completion, return only a summary without sub-agent exploration history," and you should notice a visible improvement in context efficiency.

Next article: Once you want to implement the inter-agent role boundaries discussed here at the protocol level, you inevitably reach a fork in the road of standard selection — the differences between MCP (Model Context Protocol) and A2A (Agent-to-Agent) protocol, and how to combine the two standards, will be covered next.

Core Concepts

AGENTS.md — A README for Agents

The Orchestrator-Worker Pattern

Context Isolation — Why It Matters

Role-Based Permission Delegation Patterns

Practical Application

Example 1: Designing a Hierarchical AGENTS.md Directory Structure

Example 2: Writing Role-Based Permission-Separated AGENTS.md

Example 3: Hierarchical Orchestration Design (3-Tier)

Pros and Cons Analysis

Advantages

Disadvantages and Caveats

Most Common Mistakes in Practice

Closing Thoughts

References

Core Concepts

AGENTS.md — A README for Agents

The Orchestrator-Worker Pattern

Context Isolation — Why It Matters

Role-Based Permission Delegation Patterns

Practical Application

Example 1: Designing a Hierarchical AGENTS.md Directory Structure

Example 2: Writing Role-Based Permission-Separated AGENTS.md

Example 3: Hierarchical Orchestration Design (3-Tier)

Pros and Cons Analysis

Advantages

Disadvantages and Caveats

Most Common Mistakes in Practice

Closing Thoughts

References

Recommended Posts

Andrej Karpathy's Vibe Coding Journey — Correcting LLM Agent Behavior with CLAUDE.md

Complete Analysis of MCP Prompt Injection — From Tool Poisoning Attacks to Real-World Defense

5 Trust Chain Design Patterns for MCP Multi-Agent Pipeline Security: Blocking Prompt Injection Propagation

Controlling Claude Code & Coding Agent Behavior with AGENTS.md: A Practical Guide to Three-Tier Context Engineering — Always / Ask First / Never

Automating AGENTS.md Sync: How to Prevent Context Rot with PR Templates and Pre-commit Hooks

AGENTS.md vs CLAUDE.md — A Single Source of Truth Strategy to Prevent Drift, and a Practical Guide to Symlink Synchronization