AGENTS.md Template for Redis Production Architecture

Overview

This AGENTS.md Template defines a Redis production architecture workflow for both single-agent and multi-agent orchestration. It governs planning, implementation, monitoring, and governance of a Redis cluster stack, including failover, backups, security, and performance tuning. It provides a single source of truth for the operating model and a clear path for agent handoffs, making it suitable for AI coding agents and human operators alike.

Direct answer: Use this template to codify Redis production architecture governance, enable repeatable deployments, and orchestrate multiple agents to operate Redis with safety, observability, and auditable collaboration.

When to Use This AGENTS.md Template

• Defining an end-to-end Redis production workflow for single-agent or multi-agent orchestration.
• Specifying agent roles, handoffs, and governance for cluster provisioning, scaling, and failover.
• Providing a copyable runbook that can be pasted into an AGENTS.md file to bootstrap a project or a new Redis environment.
• Enforcing security, data integrity, and operational compliance through tool access, memory, and source-of-truth rules.

Copyable AGENTS.md Template

# AGENTS.md

Project Role: Redis Production Architecture Platform Engineer and Runbook Owner

Agent roster and responsibilities:
- PlannerAgent: designs Redis topology, replication, failover strategy, data placement, and upgrade paths.
- ImplementerAgent: applies Redis node configurations, deployment scripts, and rollout plans.
- MonitorAgent: collects metrics, ensures alerts, validates health checks, and tracks latency/lag.
- FailoverOrchestratorAgent: coordinates automatic failover sequencing, sentinel/cluster state, and quorum checks.
- SecurityAgent: enforces TLS, ACL, authentication, rotation of keys, and secrets handling.
- ReviewerAgent: checks changes for risk, rollback plans, and policy compliance.
- TesterAgent: validates changes in staging/pre-prod, runs integration tests, and simulates failover.
- DomainExpertAgent: provides Redis module guidance, persistence settings, memory tuning, and module compatibility.

Supervisor or orchestrator behavior:
- The PlannerAgent serves as the authoritative source for topology and policies, then delegates implementation to the ImplementerAgent. The FailoverOrchestratorAgent coordinates state and gates progression to validation.
- The Orchestrator monitors progress, enforces gates, and triggers handoffs between stages based on test results and risk checks.

Handoff rules between agents:
- Planner to Implementer: provide configuration specs, scripts, and risk assessment; require approval gate before apply.
- Implementer to Reviewer: present diffs, test results, and rollback plan; wait for sign-off.
- Reviewer to Tester: hand off validated change package; provide test plan and acceptance criteria.
- Tester to Supervisor: deliver final verification report; escalate if issues persist.

Context, memory, and source-of-truth rules:
- Decisions reference a central Redis production runbook repository and a CI/CD artifact store.
- Configs are versioned in a repo; runtime state is sourced from Redis INFO, Prometheus, and telemetry.
- Handoff events are documented with timestamps and agent names.

Tool access and permission rules:
- Agents may read and modify production configs, run Redis CLI commands with scoped permissions, and trigger deployment hooks.
- Secrets must not be printed or logged; use secret stores; access restricted by role.

Architecture rules:
- Redis cluster with proper replication, TLS, AUTH, and ACL controls; recommended Redis 7+ with TLS and ACLs.
- Durable backups, tested failover procedures, and controlled maintenance windows.

File structure rules:
- configs under a clearly named dir, scripts under scripts, monitors under monitors, and docs under docs.

Data, API, or integration rules:
- Integrations with Prometheus, Grafana, and RedisInsight; manage external management endpoints only via approved agents.

Validation rules:
- Replication lag within threshold; healthy cluster state; backups complete; failover sequences testable.

Security rules:
- Enforce TLS, authentication, and ACLs; rotate credentials; audit logs retained.

Testing rules:
- Unit tests for scripts, integration tests for cluster operations, end-to-end tests for failover scenarios.

Deployment rules:
- CI/CD pushes changes; production changes require manual gates; maintain rollback procedures.

Human review and escalation rules:
- High-risk changes require on-call engineer review; critical incidents trigger on-call escalation paths.

Failure handling and rollback rules:
- If validation fails, revert to last committed config and re-run tests; preserve rollback checkpoints.

Things Agents must not do:
- Do not apply changes without approval; do not modify production data directly without a tested rollback; do not bypass the runbook.

Recommended Agent Operating Model

The operating model defines distinct agent roles, decision boundaries, and escalation paths. Planner handles topology and policy decisions; Implementer executes changes; Reviewer ensures safety and compliance; Tester validates in staging; Researcher gathers Redis-specific guidance; Domain Specialist ensures module and memory considerations are respected. Escalation paths go to a designated on-call or on-call engineering owner for high-risk changes.

Recommended Project Structure

redis-prod-arch
├── configs
├── backups
├── monitors
├── scripts
└── agents
    ├── planner
    ├── implementer
    ├── reviewer
    ├── tester
    ├── researcher
    └── domain-specialist

Core Operating Principles

• Single source of truth for runbooks, configs, and tests.
• Clear ownership and documented escalation paths.
• Explicit multi-agent coordination for complex changes like failover or topology updates.
• Least-privilege access and auditable tool usage.
• Change validation before production deployment with rollback guarantees.

Agent Handoff and Collaboration Rules

• Planner to Implementer: deliver top-level specs, config templates, and a risk assessment; require gate approval before apply.
• Implementer to Reviewer: present diffs, test results, affected nodes, and rollback plan; obtain sign-off before proceed.
• Reviewer to Tester: hand off validated package; provide acceptance criteria and test plan.
• Tester to Planner: report test outcomes and any recommended changes; loop if failures are found.
• Domain Specialist support: provide Redis-specific guidance during any planning or testing phases.

Tool Governance and Permission Rules

• Commands that modify production must be gated and auditable.
• File edits require review and versioned commits; secrets never printed, stored, or logged.
• API calls to management endpoints must go through approved proxies with role-based access.
• Production system access must be logged and rotated on a defined schedule.
• All changes require a signed-off approval before deployment.

Code Construction Rules

• Use idempotent scripts; avoid destructive operations without explicit confirmation.
• All Redis operations must be deterministic and revertible.
• Document any configuration drift and provide a rollback path in every change package.
• Do not bypass runbooks or skip validation gates in production.

Security and Production Rules

• Enforce TLS for all client connections; enable AUTH and ACLs; rotate credentials safely.
• Audit all access and changes; store logs securely with retention policy.
• Keep backups encrypted and tested; verify restoration procedures periodically.

Testing Checklist

• Unit tests for deployment scripts and config generation.
• Integration tests for cluster operations (scale, failover, backup, restore).
• End-to-end tests simulating failover under load and validating data integrity.
• Performance tests for replication lag and read/write latency under simulated traffic.
• Security tests for ACL enforcement and TLS validation.

Common Mistakes to Avoid

• Rushing changes into production without gating or rollback plans.
• Assuming a single agent can cover all Redis operations; multi-agent coordination must be explicit.
• Ignoring data integrity checks during topology changes or failover.
• Allowing secret leakage through logs or unencrypted channels.

Related implementation resources: AI Use Case for Corporate Event Managers Using Slack To Orchestrate Day-Of Venue Tasks Across Multi-Department Teams and AI Use Case for Sales Pipeline Reviews and Deal Risk Scoring.

FAQ

How do I start using this Redis AGENTS.md Template?

Begin by cloning the Redis production architecture template repository, replacing placeholders with your environment details, and updating the agent roster to reflect your team.

What is the recommended agent roster for Redis production architecture?

Include Planner, Implementer, Monitor, Failover Orchestrator, Security, Reviewer, Tester, and Domain Specialist as a minimum; add Researcher if Redis modules or advanced tuning are involved.

How are handoffs between agents handled in this template?

Handoffs follow a gate-driven pattern: Planner to Implementer to Reviewer to Tester, with documented decisions and timestamps for each transition.

What security requirements are specified for Redis production in this template?

Enforce TLS, AUTH, and ACLs; rotate credentials; limit secret access; and audit all operations and changes.

How is validation and rollback handled in this AGENTS.md Template?

Validation includes health checks, replication lag thresholds, and backup integrity tests. If validation fails, revert to the last committed config and re-run tests.