DNS-based Load Balancing AGENTS.md Template

Overview

Direct answer: This AGENTS.md Template defines a DNS based load balancing workflow for AI coding agents. It governs multi-agent orchestration across DNS health checks, traffic routing decisions, and handoffs between a DNSOps orchestrator and domain specific agents. It provides both single agent operating context and multi agent coordination patterns for safe DNS updates and rollbacks.

The AGENTS.md template acts as a living operating manual that can be pasted into a project as the authoritative context for the DNS based load balancing agent workflow.

When to Use This AGENTS.md Template

• When designing an AI coding agent workflow that routes traffic via DNS based load balancing across regions or zones
• When you need clear handoffs between planner, implementer, tester, reviewer, and researcher agents
• When you require tool governance, secrets handling, and access control around DNS records and health checks
• When you want a repeatable template to bootstrap new DNS based load balancing projects

Copyable AGENTS.md Template

# AGENTS.md
Project role: DNSOps Lead
Agent roster and responsibilities:
- Planner: designs DNS routing strategy, defines TTL and health-check cadence
- Implementer: applies DNS changes in provider with canary and rollback support
- HealthChecker: validates health checks and propagates results to router
- TrafficRouter: computes routing decisions based on health and policies
- HandoffAgent: manages transitions between agents and ensures state continuity
- Reviewer: approves changes before production rollout
- Tester: runs synthetic tests and monitors after changes
- Researcher: collects data on DNS performance and policy impact

Supervisor or orchestrator behavior:
- The DNSOps orchestrator reads the plan from Planner, delegates to Implementer and HealthChecker, and enforces DNS governance policies.
- All changes are versioned and logged with a central source of truth.

Handoff rules between agents:
- Planner -> Implementer: handoff includes DNS records to modify, TTL, and rollback plan
- Implementer -> HealthChecker: trigger validation after changes
- HealthChecker -> TrafficRouter: provide updated health data and routing weights
- TrafficRouter -> Supervisor: escalate if health degrades beyond threshold

Context, memory, and source-of-truth rules:
- Source of truth: central DNS config repository
- Memory: each agent stores last known state in memory with TTL
- Context: include environment, region, and policy settings

Tool access and permission rules:
- Implementer can modify DNS records in provider with read/write access
- HealthChecker can query DNS health endpoints
- TrafficRouter can fetch health metrics and route policies
- All actions require approval gate when changes exceed threshold

Architecture rules:
- Use idempotent DNS updates
- Prefer canary-based rollout with rollback
- Ensure eventual consistency

File structure rules:
- dns-load-balancer/
  - configs/
  - manifests/
  - agents/
    - planner/
    - implementer/
    - healthchecker/
    - router/
    - reviewer/
    - researcher/
  - dns_zone_configs/
  - health_checks/
  - scripts/
  - tests/
  - docs/

Data, API, or integration rules:
- Use provider APIs for DNS changes
- Use health endpoints for checks
- API keys stored in secrets vault

Validation rules:
- Validate DNS change is idempotent and reversible
- Validate TTL values within bounds
- Validate service health after update

Security rules:
- Secrets stored in vault
- Access control lists
- Avoid exposing DNS records publicly during tests

Testing rules:
- Unit tests for policy logic
- Integration tests between Planner and Implementer
- Synthetic load tests for canary rollout

Deployment rules:
- Canary deployment with monitoring and auto rollback on failure

Human review and escalation rules:
- Human reviewer required for changes outside baseline
- On-call escalation path for critical DNS updates

Failure handling and rollback rules:
- Rollback plan to previous DNS state
- Atomic swap of records when possible

Things Agents must not do:
- Do not bypass approvals
- Do not modify production DNS outside approved changes
- Do not ignore health check failures without escalation
- Do not share secrets in logs

Recommended Agent Operating Model

The agent operating model defines who decides what, and when to escalate. Planner defines strategy and policy in a centralized plan. Implementer executes production changes with careful rollout control. HealthChecker continuously validates state after changes. TrafficRouter enforces routing based on live health data. Reviewers ensure changes meet policy before going to production. Handoff rules ensure state consistency across transitions. Escalation paths ensure rapid human review for risky changes.

Recommended Project Structure

dns-load-balancer
├── configs
├── manifests
├── docs
├── scripts
├── tests
└── agents
    ├── planner
    ├── implementer
    ├── healthchecker
    ├── router
    ├── reviewer
    └── researcher

Core Operating Principles

• Single source of truth for DNS configuration
• Deterministic, policy-driven routing decisions
• Clear, auditable agent handoffs
• Strict security and secret management
• Immutability of deployment artifacts wherever possible

Agent Handoff and Collaboration Rules

Planner hands off to Implementer with a complete change plan. Implementer passes to HealthChecker for validation. HealthChecker feeds TrafficRouter with updated health data. If issues arise, Reviewer or on-call escalate. All handoffs include state snapshots, provenance, and rollback instructions.

Tool Governance and Permission Rules

• DNS changes require versioned plans and approvals
• Secrets must be retrieved from a vault; never embedded in code
• DNS API keys granted per-environment with least privilege
• Production changes require canary rollout and monitoring gates
• Audit logs kept for all DNS operations

Code Construction Rules

• DNS config files must be idempotent and versioned
• TTL values must be within defined bounds
• Canary deployments require explicit canary traffic percentages
• Scripts must be shell or Python with strict error handling
• All code changes must pass lint and basic tests before review

Security and Production Rules

• Secrets in vault with rotation policies
• Access controls and multi-factor approvals for production changes
• DNS changes are reversible with a defined rollback path
• Monitor for anomalous DNS activity and alert on drift

Testing Checklist

• Unit tests for policy logic and decision rules
• Integration tests for Planner-Implementer-HealthChecker interactions
• Canary rollout tests with health checks and fallback
• End-to-end tests for DNS update, propagation, and rollback

Common Mistakes to Avoid

• Skipping approvals for production DNS changes
• Ignoring health check results during rollout
• Overlooking drift between DNS state and central repo
• Reusing credentials or leaking secrets in logs

Related implementation resources: AI Use Case for Gym Franchises Using Excel To Analyze Membership Peak Check-In Times and Adjust Staffing Levels and AI Use Case for Corporate Event Managers Using Slack To Orchestrate Day-Of Venue Tasks Across Multi-Department Teams.

FAQ

What is the purpose of this DNS based load balancing AGENTS.md Template?

This template provides an operating manual for DNS based load balancing workflows using AI coding agents, covering multi-agent orchestration, handoffs, tool governance, and security rules.

Who should use this template?

Developers, SREs, platform teams implementing DNS based load balancing with AI agents.

How are changes governed and audited?

All changes are versioned, require approvals, and include rollback plans with canary testing.

How are rollbacks executed?

Rollbacks revert DNS records to the previous state and validate health after rollback.

Where are secrets stored and who can access them?

Secrets live in a vault with least privilege access and are rotated regularly; access is audited.