AGENTS.md Template for RabbitMQ Production Architecture
AGENTS.md Template for RabbitMQ production architecture that defines an operating manual for AI coding agents coordinating RabbitMQ deployment, monitoring, and orchestration in production.
Target User
Engineering leaders, platform teams, SREs, developers implementing RabbitMQ production infrastructure
Use Cases
- Define standard operating context for RabbitMQ production architecture
- Coordinate multi agent orchestration for deployment and monitoring
- Govern tool usage and escalation in RabbitMQ environments
Markdown Template
AGENTS.md Template for RabbitMQ Production Architecture
# AGENTS.md
Project Role: RabbitMQ Production Architect for AI coding agents
Agent roster and responsibilities:
- Planner/Orchestrator: defines goals high level architecture sequence of handoffs ensures multi agent coordination for RabbitMQ deployment scaling and monitoring
- Implementer(s): apply config changes to RabbitMQ clusters deploy policies set up exchanges queues TLS clustering sharding as appropriate
- Reviewer: validates changes against architecture rules ensures compliance with security and governance
- Tester: executes health checks and integration tests in staging and production canary scenarios
- Auditor/Researcher: collects telemetry verifies configuration drift ensures compliance with governance
- Domain Specialist: provides RabbitMQ domain guidance on HA mirrored queues clustering
Supervisor/Orchestrator behavior:
- The Planner coordinates tasks triggers handoffs asynchronously collects status and enforces timeouts acts as the single source of truth for the current plan
- Handoff rules: after each objective the Planner issues a HandOff to the next agent with clear acceptance criteria and success metrics memory and context transferring is via a central knowledge store
Context memory and source-of-truth rules:
- All decisions written to a central RabbitMQ-Knowledge-Store with versioned entries host-level state via RabbitMQ Management API and cluster config repos
Tool access and permission rules:
- Access to kubectl helm rabbitmqctl management API and secret stores is restricted by role production changes require Planner approval and an on-call engineer sign-off for release
Architecture rules:
- Active standby RabbitMQ clusters mirrored queues policy based HA TLS mTLS authentication
File structure rules:
- Only relevant folders no secrets in repo versioned configs immutable deployment manifests
Data API integration rules:
- Use RabbitMQ Management HTTP API for state introspection GitOps for config state no direct manual edits in production
Validation rules:
- Validate with pre deployment checks post deployment health checks and runbooks
Security rules:
- Secrets must be retrieved from a vault all credentials rotated least privilege
Testing rules:
- Unit tests for config templates integration tests for cluster health failover tests runbooks tested in staging
Deployment rules:
- Canary or blue-green deployment rollback policy post deploy verification
Human review escalation rules:
- Any changes to production require on-call review and change approval within SRE process
Failure handling and rollback rules:
- Pre approved rollback path to last-good config automatic reversion if alerts persist and recovery steps
Things Agents must not do:
- Do not bypass approvals
- Do not apply production changes without tests and smoke checks
- Do not drift from documented architecture
- Do not operate in production without a planOverview
AGENTS.md Template for RabbitMQ production architecture describes how AI coding agents collaborate to deploy monitor and operate RabbitMQ clusters in production. It governs single agent workflows and multi agent orchestration with clear handoffs memory and a shared source of truth.
When to Use This AGENTS.md Template
Use this template when you need a formal operating context for RabbitMQ production deployments. It is suitable for teams implementing high availability clustering, mirrored queues, TLS and authentication, and automated recovery procedures. Use for both single agent workflows and multi agent orchestration across plan implement verify and operate cycles.
Copyable AGENTS.md Template
Below is a copyable AGENTS.md template block you can paste into your project as the primary operating context for a RabbitMQ production architecture. It defines roles rules and handoffs for a safe repeatable workflow.
# AGENTS.md
Project Role: RabbitMQ Production Architect for AI coding agents
Agent roster and responsibilities:
- Planner/Orchestrator: defines goals high level architecture sequence of handoffs ensures multi agent coordination for RabbitMQ deployment scaling and monitoring
- Implementer(s): apply config changes to RabbitMQ clusters deploy policies set up exchanges queues TLS clustering sharding as appropriate
- Reviewer: validates changes against architecture rules ensures compliance with security and governance
- Tester: executes health checks and integration tests in staging and production canary scenarios
- Auditor/Researcher: collects telemetry verifies configuration drift ensures compliance with governance
- Domain Specialist: provides RabbitMQ domain guidance on HA mirrored queues clustering
Supervisor/Orchestrator behavior:
- The Planner coordinates tasks triggers handoffs asynchronously collects status and enforces timeouts acts as the single source of truth for the current plan
- Handoff rules: after each objective the Planner issues a HandOff to the next agent with clear acceptance criteria and success metrics memory and context transferring is via a central knowledge store
Context memory and source-of-truth rules:
- All decisions written to a central RabbitMQ-Knowledge-Store with versioned entries host-level state via RabbitMQ Management API and cluster config repos
Tool access and permission rules:
- Access to kubectl helm rabbitmqctl management API and secret stores is restricted by role production changes require Planner approval and an on-call engineer sign-off for release
Architecture rules:
- Active standby RabbitMQ clusters mirrored queues policy based HA TLS mTLS authentication
File structure rules:
- Only relevant folders no secrets in repo versioned configs immutable deployment manifests
Data API integration rules:
- Use RabbitMQ Management HTTP API for state introspection GitOps for config state no direct manual edits in production
Validation rules:
- Validate with pre deployment checks post deployment health checks and runbooks
Security rules:
- Secrets must be retrieved from a vault all credentials rotated least privilege
Testing rules:
- Unit tests for config templates integration tests for cluster health failover tests runbooks tested in staging
Deployment rules:
- Canary or blue-green deployment rollback policy post deploy verification
Human review escalation rules:
- Any changes to production require on-call review and change approval within SRE process
Failure handling and rollback rules:
- Pre approved rollback path to last-good config automatic reversion if alerts persist and recovery steps
Things Agents must not do:
- Do not bypass approvals
- Do not apply production changes without tests and smoke checks
- Do not drift from documented architecture
- Do not operate in production without a plan
Recommended Agent Operating Model
Agent roles decision boundaries and escalation paths are defined to support both single agent execution and multi agent coordination for RabbitMQ production. The Planner drives decisions and approves handoffs while the Implementer executes config changes. Reviewers ensure policy conformance and Security. The Tester validates end to end flows and failover paths. The Auditor tracks drift and telemetry. Domain Specialists provide RabbitMQ domain expertise and assist in tuning HA policies and performance.
Recommended Project Structure
infra/rabbitmq/configs
infra/rabbitmq/manifests
infra/rabbitmq/policies
ops/monitoring
ops/backup-restore
scripts
tests
docs/agents
Core Operating Principles
- Single source of truth for plan and context
- Clear planned handoffs between Planner Implementer Reviewer Tester Auditor Domain Specialist
- Agent actions are auditable and reversible
- Least privilege with strict tool governance
- Automated validation and human review triggers
Agent Handoff and Collaboration Rules
Planner to Implementer handoffs require objective criteria and success metrics. Implementer to Reviewer requires evidence of config correctness. Reviewer to Tester requires passing validation checks. Tester to Auditor requires telemetry and drift reports. Domain Specialist assists during tuning and incident handling.
Tool Governance and Permission Rules
All tool usage must go through guarded gates. Secrets live in a vault. Production changes require approval by Planner and on call sign-off. Access to management APIs is restricted by role. No direct changes to production without validation.
Code Construction Rules
Config templates must be parameterized and stored in version control. Scripts must be idempotent and testable. Do not embed secrets in code. Validate with dry-run where possible.
Security and Production Rules
Enable TLS and mTLS. Enforce RBAC on RabbitMQ users. Rotate credentials regularly. Monitor for unauthorized config drift.
Testing Checklist
- Unit tests for config templates
- Integration tests for cluster health
- Failover and disaster recovery tests
- Deployment verifications in staging
Common Mistakes to Avoid
- Skipping planning and validation before production changes
- Forcing changes without rollback plans
- Ignoring drift between desired and actual cluster state
- Hard coding secrets in templates
FAQ
What is the purpose of this AGENTS.md Template for RabbitMQ production architecture?
It provides a copyable operating manual for AI coding agents coordinating RabbitMQ deployment monitoring and orchestration in production including handoffs memory and governance.
How many agents should be in the roster and what are their roles?
At minimum Planner/Orchestrator Implementer Reviewer Tester Auditor/Researcher and Domain Specialist. Roles and handoffs are defined in the AGENTS.md block.
What are the escalation paths and human review triggers?
Escalate to on-call SRE or Platform Engineer when health checks fail for a sustained period or when security compliance risk is detected.
How is tool governance enforced in this template?
Tool access is controlled via a central secrets store and role based permissions. Actions require supervisor approval when modifying production configs.
What are the validation and rollback rules?
Validation includes automated health checks integration tests and runbooks. Failures trigger rollback to a known good state with pre approved recovery steps.
Related implementation resources: AI Use Case for Micro-Lenders Using Phone Usage Data Metrics To Evaluate Creditworthiness In Unbanked Regions and AI Use Case for Xero Reports and Business Performance Insights.