AGENTS.md Template for Global Load Balancing Strategy

Overview

AGENTS.md template for global load balancing strategy defines a project-level operating context for coordinating AI coding agents in a multi-agent orchestration pattern across DNS-based routing, health checks, and edge policy application.

Direct answer: This AGENTS.md template governs the agent workflow and ensures clear handoffs, single source of truth, and auditable decisions across the global load balancing flow.

When to Use This AGENTS.md Template

• Use when implementing a global load balancing strategy across multi-region deployments and edge layers.
• When using DNS-based, geo-based, or Anycast routing with health checks and policy-driven routing.
• When coordinating multiple AI coding agents (planner, DNS, health, routing) with clear handoffs and governance.

Copyable AGENTS.md Template

Paste this into your AGENTS.md file to initialize the operating context for your global load balancing workflow.

# AGENTS.md

Project: Global Load Balancing Strategy

Overview:
  This AGENTS.md template defines the project-level operating context for coordinating AI coding agents that implement a global load balancing strategy across DNS, edge routing, and health/gate checks. It supports both single-agent execution and multi-agent orchestration with explicit handoffs and governance.

Agent roster and responsibilities:
  - Orchestrator (Planner): defines policy, coordinates agent tasks, validates end-to-end routing decisions.
  - DNSAgent: applies DNS-based routing policies and updates DNS records as instructed by the orchestrator.
  - LoadBalancerAgent: evaluates load-balancing strategy, computes weights, and enforces routing decisions at edge/load balancers.
  - HealthCheckAgent: performs and evaluates health checks for regions, endpoints, and services.
  - GeoRoutingAgent: applies geographic routing rules and geo-based traffic shaping.
  - CachePolicyAgent: manages edge caching and content delivery policy.
  - SecurityAgent: ensures policy changes meet security standards and approvals.
  - AuditorAgent: records decisions and outcomes for traceability.
  - ReviewerAgent: conducts manual review as part of escalation path.
  - TesterAgent: validates changes in staging or canary environments before production.

Supervisor or orchestrator behavior:
  - Maintains the source of truth for routing policies and health metrics.
  - Triggers handoffs between agents when a policy decision is made.
  - Logs decisions, outcomes, and escalations for auditability.

Handoff rules between agents:
  - Planner -> DNSAgent: publish DNS policy changes with validation context.
  - DNSAgent -> LoadBalancerAgent: report updated records and health constraints.
  - LoadBalancerAgent -> HealthCheckAgent: run health evaluation after policy change.
  - HealthCheckAgent -> GeoRoutingAgent: confirm regional availability and constraints.
  - Any agent -> AuditorAgent: emit traceable decision records.
  - Escalation: if any agent reports failure, escalate to ReviewerAgent or on-call if critical.

Context, memory, and source-of-truth rules:
  - Context: policy_id, version, timestamp, region, health metrics, and current routing decision.
  - Memory: last stable policy version and last successful deployment event.
  - Source of truth: central policy store and DNS/edge configuration repo.

Tool access and permission rules:
  - DNS API keys stored in secret manager; only DNSAgent has write access.
  - Edge config and routing policies editable only via orchestrator approvals.
  - All tool actions are logged and auditable.

Architecture rules:
  - Stateless agent executions; all decisions must be evaluated against the central policy store.
  - Clear separation of concerns among DNS, routing, health, and security components.

File structure rules:
  - policies/: policy definitions and versioned changes.
  - agents/: agent implementations and templates.
  - orchestrator/: planner and state machine definitions.
  - integrations/: external service connectors (DNS, health, monitoring).
  - tests/: tests and staging configurations.
  - docs/: operating guidelines and runbooks.

Data, API, or integration rules when relevant:
  - All data must be immutable after commit; write-ahead logs retained.
  - Use typed schemas for policy payloads; validate before deployment.

Validation rules:
  - Validate policy syntax, DNS feasibility, and health constraints before applying changes.
  - All changes require a green health check in staging before production.

Security rules:
  - Secrets must not be stored in code; fetch at runtime from a secure vault.
  - Changes require role-based approvals and traceable sign-offs.

Testing rules:
  - Unit tests for policy evaluation; integration tests for DNS and edge interactions.
  - Canary testing for routing changes with rollback window.

Deployment rules:
  - Changes deployed through CI/CD with feature flags and canary approvals.
  - Rollback planned and tested; revert to previous policy if stellar health cannot be achieved.

Human review and escalation rules:
  - Automated checks pass; still require human on-call review for production-impacting changes.
  - Escalate to on-call incidents for critical routing failures.

Failure handling and rollback rules:
  - If health checks fail for a sustained window, revert to the last known-good policy.
  - Maintain a rollback journal and provide a one-click revert path.

Things Agents must not do:
  - Do not bypass approvals or modify production routing without consent.
  - Do not store credentials in code or logs.
  - Do not perform unsupervised changes to DNS or edge configuration.

Recommended Agent Operating Model

Roles and decision boundaries: Orchestrator defines policy; each agent enforces its domain; reviewers and testers validate outcomes. Escalation paths are explicit to minimize drift and ensure governance.

Recommended Project Structure

GlobalLB/
├── policies/
├── agents/
│   ├── dns_agent/
│   ├── load_balancer_agent/
│   ├── health_check_agent/
│   ├── geo_routing_agent/
│   ├── security_agent/
│   └── auditor_agent/
├── orchestrator/
├── integrations/
├── tests/
├── docs/

Core Operating Principles

• Single source of truth for routing policies and health data.
• Deterministic, auditable decision-making with explicit memory.
• Idempotent actions and reversible changes with clear rollback paths.
• Strict separation of duties among agents and governance controls.
• Security-first: secrets managed in a vault and never embedded in code.

Agent Handoff and Collaboration Rules

• Planner defines policy and state; implements plan via sequential handoffs to domain agents.
• DNSAgent and LoadBalancerAgent coordinate via policy IDs and health score signals.
• Reviewer and Tester validate changes in staging; Auditor records decisions and outcomes.
• Domain specialists provide input for geo-rules, security constraints, and compliance.
• Handoff requires consensus or explicit sign-off for production changes.

Tool Governance and Permission Rules

• Only approved agents may execute DNS changes or edge configuration edits.
• All API calls and file edits are versioned and auditable.
• Secrets must be retrieved from a vault; avoid exposing credentials in logs.
• Production changes require on-call review and runbook-triggered approvals.

Code Construction Rules

• Favor declarative policy definitions; minimize imperative logic in codeblocks.
• All changes must be tested with canary routing and health checks.
• Provide deterministic outputs for every policy evaluation.

Security and Production Rules

• Zero-trust access to production: only authenticated and authorized agents and humans.
• All production changes must pass a security review and threat-model assessment.

Testing Checklist

• Unit tests for policy evaluation logic.
• Integration tests with DNS provider and health endpoints.
• Canary deployment verification and rollback validation.

Common Mistakes to Avoid

• Skipping reviews or bypassing the approvals gate.
• Drifting away from the central policy store or single source of truth.
• Hard-coding credentials or secrets in code or logs.

Related implementation resources: AI Use Case for Corporate Event Managers Using Slack To Orchestrate Day-Of Venue Tasks Across Multi-Department Teams and AI Agent Use Case for Wholesalers Using Multi-Currency Ledger Trackers To Calculate Foreign Exchange Risk Exposure Across Global Accounts.

FAQ

What is the purpose of this AGENTS.md Template?

It provides a concrete operating manual for governing a global load balancing strategy with AI coding agents, clarifying roles, handoffs, and governance.

How does multi-agent orchestration work in this workflow?

The orchestrator coordinates domain agents (DNS, load balancer, health, geo) with explicit handoffs, shared context, and a central policy store to produce deterministic routing decisions.

What are the handoff rules between planner, implementer, and reviewer agents?

Planner publishes a policy; DNS/LoadBalancer implementers apply changes; Reviewer and Tester validate in staging; Auditor records outcomes; on failure, escalate.

How are secrets and credentials managed?

Secrets are retrieved from a vault at runtime; never stored in code or logs; access is restricted by RBAC and audited.

What happens on failure or rollback?

Health checks trigger rollback to the last known-good policy; the rollback is logged, and a one-click revert path is documented in the runbook.