CDN Architecture Planning AGENTS.md Template

Overview

Direct answer: This AGENTS.md template defines a repeatable operating manual for CDN architecture planning using AI coding agents, enabling both single-agent workflows and multi-agent orchestration with explicit handoffs and governance.

This CDN Architecture Planning AGENTS.md Template governs an orchestration pattern where a Planner designs topology and caching strategy, an Implementer translates plans into provider configs, a Researcher gathers telemetry data, a Domain Specialist ensures regional and regulatory compliance, and a Reviewer validates performance and security. The Supervisor orchestrates the flow, enforces tool governance, and maintains the single source of truth. The template is designed for both a single agent operating with clear boundaries and a multi-agent system coordinating across design, validation, deployment, and post-deployment monitoring.

When to Use This AGENTS.md Template

• When planning CDN topology (edge locations, cache levels, origin fetch rules) and performance targets.
• When coordinating multiple AI agents across design, validation, and deployment workflows.
• When enforcing tool governance, secrets handling, and RBAC boundaries.
• When you need explicit handoffs and escalation rules with traceable memory for the CDN project.
• When integrating with CI/CD pipelines and telemetry for observability.

Copyable AGENTS.md Template

Below is a copyable AGENTS.md template for CDN architecture planning. Copy entire code block into your project to initialize the agent operating context.

# AGENTS.md

Project role
- CDN Architecture Planner and Orchestrator
- Responsible for designing CDN topology, caching strategy, origin policy, and deployment roadmap.

Agent roster and responsibilities
- Planner: define CDN topology (edge locations, cache levels, origin fetch rules)
  - Outputs: CDN topology document, edge config map, cache rules
- Implementer: translates topology into CDN provider configs, edge rules, and deployment steps
  - Outputs: provider config files, deployment scripts
- Reviewer: validates performance targets, security, and compliance
  - Outputs: review notes, risk assessment
- Researcher: collects data about traffic patterns, TTLs, cache hit rates, legal constraints
  - Outputs: data briefs, measurement plan
- Domain Specialist: ensures regional compliance, regulatory constraints, and purge policies
  - Outputs: regional policy doc

Supervisor or orchestrator behavior
- The Supervisor coordinates all agents, enforces roles, and triggers handoffs when outputs are ready.
- Maintains a single source of truth and memory store for project context.

Handoff rules between agents
- Planner ➜ Implementer: hand off topology and config map; include rationale.
- Implementer ➜ Reviewer: hand off deployment readiness with validation results.
- Researcher ➜ Planner: hand off data briefs for topology adjustments.
- Domain Specialist ➜ Planner: raise regional constraints and purge policy changes.

Context, memory, and source-of-truth rules
- All decisions reference a central knowledge base: CDN docs, architecture diagrams, policy documents.
- Memory keys: TODATE_TOP, EDGE_LOCATIONS, TTL_POLICY, ORIGIN_POLICY, SECURITY_STANDARDS.

Tool access and permission rules
- Agents access cloud/CDN provider APIs via orchestrator with fine-grained scopes.
- Secrets stored in a vault; agents never store credentials in local memory.

Architecture rules
- Use a multi-tier cache (edge cache, regional cache, origin fetch)
- Origin shield to protect origin
- Consistent TTL policy and cache invalidation semantics

File structure rules
- Place all CDN configs under cdn-architecture/
- Docs: docs/
- Configs: configs/
- Scripts: scripts/
- Data: data/

Data, API, or integration rules when relevant
- Data collection via telemetry API; ensure data retention policies
- Use standard API formats (JSON) for all inter-agent communication

Validation rules
- All configs validated against a schema
- Load tests meet defined thresholds

Security rules
- Enforce TLS 1.2+, HSTS
- No secrets in code; all secrets via vault
- Access controlled by RBAC
- Integrity checks for edge and origin responses

Testing rules
- Unit: config validation tests
- Integration: end-to-end CDN deployment test in staging
- Performance: cache-hit rate target, p95 latency bound

Deployment rules
- Deploy to staging CDN first; promote after successful tests
- Canary or phased rollout for edge locations

Human review and escalation rules
- If risk threshold exceeded, escalate to human reviewer
- All changes require sign-off before production deployment

Failure handling and rollback rules
- Rollback to previous known-good configuration on failure
- Preserve logs and metrics for post-incident review

Things Agents must not do
- Do not bypass security and access controls
- Do not mutate production traffic without validation
- Do not perform unsanctioned code changes

Recommended Agent Operating Model

The operating model defines clear roles, decision boundaries, and escalation paths for CDN architecture planning. The Planner designs topology with guardrails; the Implementer translates plans into deployable configurations; the Researcher pulls data to validate decisions; the Domain Specialist confirms regional constraints; the Reviewer approves readiness before deployment. The Supervisor enforces governance, resolves conflicts, and triggers escalations when risk is detected. Memory and source-of-truth are maintained in a central repository to prevent drift.

Recommended Project Structure

Workflow-specific directory tree for CDN architecture planning:

cdn-architecture/
├── docs/
├── configs/
│   ├── edge/
│   └── origin/
├── policies/
├── data/
├── tests/
├── pipelines/
└── orchestrator/

Core Operating Principles

• Single source of truth for CDN design decisions and memory.
• Deterministic handoffs with traceable outputs.
• Strict context isolation per agent and no cross-contamination of memory.
• Security by default: strict RBAC, secrets vault, and encrypted channels.
• Observability, auditability, and reproducibility of CDN changes.
• Human-in-the-loop for high-risk decisions or policy changes.

Agent Handoff and Collaboration Rules

• Planner to Implementer: provide topology, edge rules, and origin policy with rationale.
• Implementer to Reviewer: provide deployment readiness and validation results.
• Researcher to Planner: share data briefs to adjust topology or TTLs.
• Domain Specialist to Planner: share regional constraints and purge policies.
• All agents must reference the memory store and cite sources of truth in outputs.

Tool Governance and Permission Rules

• Only orchestrator may invoke provider APIs and deploy to edge locations.
• Secrets must live in a vault; no plaintext credentials in memory or code.
• All changes require approval gates before production deployment.
• Access scopes are limited to the minimum required for the task.
• Audit logs must capture agent actions and decisions.

Code Construction Rules

• Configs must be versioned and validated against a schema before deployment.
• Treat CDN rules as declarative; avoid imperative nudges in production.
• All scripts include idempotent behavior and clear rollback steps.

Security and Production Rules

• TLS 1.2+ and TLS best practices for edge and origin communications.
• HSTS and certificate pinning where supported.
• Origin shield and critical path protections to prevent cache poisoning.
• Secrets access strictly via orchestrator and vault; never in code or logs.
• Production changes require human sign-off for firewall, cache, and origin policies.

Testing Checklist

• Unit tests for config schemas and policy validations.
• Integration tests for edge and origin interactions with the CDN provider.
• Performance tests: target cache-hit rate, p95/latency thresholds.
• Failover tests and rollback verification.
• Security tests: secret access, TLS/HTTPS, and policy compliance.

Common Mistakes to Avoid

• Skipping memory/tenancy isolation between agents leading to context drift.
• Bypassing approval gates or security restrictions for speed.
• Unclear handoffs causing duplicate work or missed outputs.
• Treating AGENTS.md as a passive note rather than an operating manual.

Related implementation resources: AI Use Case for Xero Reports and Business Performance Insights and AI Use Case for Visa Consultants Using Government Portals To Check Application Documents for Missing Requirements.

FAQ

What is the purpose of this CDN AGENTS.md Template?

Defines a repeatable operating model for CDN architecture planning using AI coding agents, enabling both single-agent work and multi-agent orchestration with governance and clear handoffs.

Which roles are required in the CDN agent roster?

Planner, Implementer, Reviewer, Researcher, and Domain Specialist coordinating through the Supervisor.

How are tool access and secrets managed?

Secrets are stored in a vault; agents access APIs via the orchestrator with scoped permissions; no credentials stored in memory or logs.

What happens on failure or rollback?

Deterministic rollback steps, re-synchronization with the source of truth, and escalation to human review if needed.

Where should I store the AGENTS.md template and artifacts?

In the CDN architecture project repository with versioned AGENTS.md and related configs.