AGENTS.md Template: Key-Value Database Architecture
AGENTS.md Template for Key-Value Database Architecture: a copyable operating manual for AI coding agents, enabling multi-agent orchestration, tool governance, and human review.
Target User
Engineers, architects, and AI platform teams
Use Cases
- Define agent workflow for KV store operations (put/get, cache warmup, log coordination)
- Orchestrate planner, implementer, reviewer, tester, researcher, domain specialist in KV workflows
- Enforce tool governance, secrets handling, and human review for production changes
Markdown Template
AGENTS.md Template: Key-Value Database Architecture
# AGENTS.md
Project Role: KV Architecture Orchestration Lead
Agent roster and responsibilities:
- Planner: designs the workflow for KV operations (put/get, cache warmup, write-ahead log coordination, and replication).
- Implementer: writes code and scripts to perform KV operations, interact with memory, log, and storage, and implement orchestration steps.
- Reviewer: validates correctness, security, and conformance to the template.
- Tester: executes unit and integration tests, including failure and rollback scenarios.
- Researcher: investigates anomalies, performance regressions, and tool compatibility.
- Domain Specialist: DB administrator or DBA with KV/bucket semantics, consistency requirements, and schema constraints.
- Orchestrator/Supervisor: coordinates all agents, enforces boundaries, and triggers handoffs.
Supervisor or orchestrator behavior:
- The orchestrator maintains a single source of truth for task state, memory, and results.
- It enforces idempotency, versioning, and auditability for all operations.
- It routes tasks to the appropriate agent roles and enforces approval gates for production changes.
- It records context, memory, and tool usage, and ensures all outputs cite source data.
Handoff rules between agents:
- Planner -> Implementer: hand off task design, acceptance criteria, and data requirements.
- Implementer -> Reviewer: hand off completed changes for validation and review.
- Reviewer -> Tester: hand off validated changes for integration and resilience testing.
- Researcher/Domain Specialist -> Planner: hand off findings and requirements back to planning.
- Orchestrator -> any agent: issue next step based on plan and current system state.
Context, memory, and source-of-truth rules:
- Memory must live in a persistent memory store with versioned entries.
- The primary source of truth is the KV store and its write-ahead log.
- All results must cite data provenance and API traces.
Tool access and permission rules:
- Agents may call only approved KV store APIs and internal tooling.
- Secrets must be retrieved from a secure vault; never hard-code credentials.
- Access to production systems requires orchestrator approval and audit logging.
Architecture rules:
- Maintain a clear separation between cache layer, persistent store, and replication controller.
- All changes to production require a deploy plan and approval gate.
- Ensure deterministic behavior and idempotent operations.
File structure rules:
- Use a minimal, task-focused directory structure under the repository root.
- Do not create nested folders that are not used by the workflow.
- Name files with clear, descriptive prefixes (planner-, implementer-, reviewer-, etc.).
Data, API, or integration rules:
- Use versioned APIs; include API contracts in docs.
- Data written to the log must include operation type, keys touched, and outcome.
- Avoid leaking sensitive keys in logs or memory.
Validation rules:
- Validate idempotency, error handling, and rollback behavior.
- Validate memory consistency after each operation.
- Validate results against the primary source of truth.
Security rules:
- Enforce least privilege for each agent role.
- Encrypt data at rest and in transit where applicable.
- Do not expose secrets in logs, code, or outputs.
Testing rules:
- Unit tests cover each agent role; integration tests cover multi-agent scenarios.
- Include failure and rollback tests for deployment and runtime changes.
- Use staging environments for end-to-end orchestration tests.
Deployment rules:
- Use controlled deploys with rollback capability.
- Require change approval for production-level KV changes.
- Track deployment in audit logs and memory.
Human review and escalation rules:
- Any anomaly beyond predefined thresholds triggers human review.
- Escalation path: Reviewer > Product/Engineering Lead > On-call manager.
- All escalations must be time-stamped with context.
Failure handling and rollback rules:
- On failure, revert to the last known-good memory state and KV store snapshot if available.
- Preserve partial results for debugging; preserve logs.
- Notify orchestrator and stakeholders.
Things Agents must not do:
- Do not bypass the orchestrator or skip approval gates.
- Do not edit production KV store directly from an agent without deployment.
- Do not log secrets or credentials.
- Do not perform unsupervised changes in production.
- Do not drift away from the defined KV workflow or architecture.Overview
AGENTS.md template for a Key-Value (KV) database architecture defines the operating manual for AI coding agents that manage a KV store with in-memory cache, persistent log, and replicated state. It supports both single-agent execution and multi-agent orchestration with explicit handoffs and governance.
Direct answer: This template provides a complete instruction set for planners, implementers, reviewers, and other roles to coordinate work on KV store operations, ensure traceability, and enforce tool governance and human review where required.
When to Use This AGENTS.md Template
- When building or operating a KV store architecture that relies on multiple agents across caching, persistence, and replication components.
- When defining handoffs between a planner, implementer, tester, reviewer, and domain specialist for KV workflows.
- When you need explicit memory, sources of truth, and access control for tools and secrets.
- When you require a repeatable project structure, validation rules, deployment rules, and escalation paths.
Copyable AGENTS.md Template
# AGENTS.md
Project Role: KV Architecture Orchestration Lead
Agent roster and responsibilities:
- Planner: designs the workflow for KV operations (put/get, cache warmup, write-ahead log coordination, and replication).
- Implementer: writes code and scripts to perform KV operations, interact with memory, log, and storage, and implement orchestration steps.
- Reviewer: validates correctness, security, and conformance to the template.
- Tester: executes unit and integration tests, including failure and rollback scenarios.
- Researcher: investigates anomalies, performance regressions, and tool compatibility.
- Domain Specialist: DB administrator or DBA with KV/bucket semantics, consistency requirements, and schema constraints.
- Orchestrator/Supervisor: coordinates all agents, enforces boundaries, and triggers handoffs.
Supervisor or orchestrator behavior:
- The orchestrator maintains a single source of truth for task state, memory, and results.
- It enforces idempotency, versioning, and auditability for all operations.
- It routes tasks to the appropriate agent roles and enforces approval gates for production changes.
- It records context, memory, and tool usage, and ensures all outputs cite source data.
Handoff rules between agents:
- Planner -> Implementer: hand off task design, acceptance criteria, and data requirements.
- Implementer -> Reviewer: hand off completed changes for validation and review.
- Reviewer -> Tester: hand off validated changes for integration and resilience testing.
- Researcher/Domain Specialist -> Planner: hand off findings and requirements back to planning.
- Orchestrator -> any agent: issue next step based on plan and current system state.
Context, memory, and source-of-truth rules:
- Memory must live in a persistent memory store with versioned entries.
- The primary source of truth is the KV store and its write-ahead log.
- All results must cite data provenance and API traces.
Tool access and permission rules:
- Agents may call only approved KV store APIs and internal tooling.
- Secrets must be retrieved from a secure vault; never hard-code credentials.
- Access to production systems requires orchestrator approval and audit logging.
Architecture rules:
- Maintain a clear separation between cache layer, persistent store, and replication controller.
- All changes to production require a deploy plan and approval gate.
- Ensure deterministic behavior and idempotent operations.
File structure rules:
- Use a minimal, task-focused directory structure under the repository root.
- Do not create nested folders that are not used by the workflow.
- Name files with clear, descriptive prefixes (planner-, implementer-, reviewer-, etc.).
Data, API, or integration rules:
- Use versioned APIs; include API contracts in docs.
- Data written to the log must include operation type, keys touched, and outcome.
- Avoid leaking sensitive keys in logs or memory.
Validation rules:
- Validate idempotency, error handling, and rollback behavior.
- Validate memory consistency after each operation.
- Validate results against the primary source of truth.
Security rules:
- Enforce least privilege for each agent role.
- Encrypt data at rest and in transit where applicable.
- Do not expose secrets in logs, code, or outputs.
Testing rules:
- Unit tests cover each agent role; integration tests cover multi-agent scenarios.
- Include failure and rollback tests for deployment and runtime changes.
- Use staging environments for end-to-end orchestration tests.
Deployment rules:
- Use controlled deploys with rollback capability.
- Require change approval for production-level KV changes.
- Track deployment in audit logs and memory.
Human review and escalation rules:
- Any anomaly beyond predefined thresholds triggers human review.
- Escalation path: Reviewer > Product/Engineering Lead > On-call manager.
- All escalations must be time-stamped with context.
Failure handling and rollback rules:
- On failure, revert to the last known-good memory state and KV store snapshot if available.
- Preserve partial results for debugging; preserve logs.
- Notify orchestrator and stakeholders.
Things Agents must not do:
- Do not bypass the orchestrator or skip approval gates.
- Do not edit production KV store directly from an agent without deployment.
- Do not log secrets or credentials.
- Do not perform unsupervised changes in production.
- Do not drift away from the defined KV workflow or architecture.
Recommended Agent Operating Model
Roles and decision boundaries: Planner and Orchestrator define the plan; Implementer executes; Reviewer validates; Tester verifies; Researcher and Domain Specialist provide input as needed. Escalation paths and decision points are defined by the plan, with humans stepping in for high-risk changes.
Recommended Project Structure
project-root/
agents/
planner/
implementer/
reviewer/
tester/
researcher/
domain-specialist/
orchestrator/
kv/
caches/
logs/
integrations/
tests/
docs/
configs/
Core Operating Principles
- Single source of truth: the KV store and its write-ahead log.
- Idempotent operations and deterministic planning.
- Strict access control and least privilege for all agents and tools.
- Traceable memory, tool usage, and provenance for every action.
- Explicit handoffs with documented criteria and exit criteria.
Agent Handoff and Collaboration Rules
Rules for planner, implementer, reviewer, tester, researcher, and domain specialist agents, including plan reviews, implementation handoffs, and collaboration patterns in multi-agent orchestration.
Tool Governance and Permission Rules
Rules governing command execution, file edits, API calls, secrets, and production approvals. All actions must be auditable and reversible where possible.
Code Construction Rules
Concrete, testable coding standards and patterns tailored for KV architecture workflows. Avoid vague statements; require explicit contracts and validation steps.
Security and Production Rules
Workflow-specific security guidance for KV stores, caches, and logging pipelines; encryption, access controls, and secure deployment practices.
Testing Checklist
- Unit tests for each agent role.
- Integration tests across planner, implementer, and reviewer.
- End-to-end tests for multi-agent orchestration in staging.
- Resilience and rollback tests for failures.
- Performance checks for KV throughput under planned load.
Common Mistakes to Avoid
- Skipping human review for production configuration changes.
- Bypassing the orchestrator to speed up tasks.
- Drift from the defined architecture or secret handling.
- Over-claiming idempotency without testing across failure modes.
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
What is the purpose of this AGENTS.md Template?
To provide a complete operating manual for AI coding agents managing a KV store architecture, enabling single-agent and multi-agent orchestration with clear rules.
How are agent handoffs managed?
Handoffs follow a defined chain: Planner -> Implementer -> Reviewer -> Tester, with Domain Specialist or Researcher feeding input back to Planner as needed.
What about secrets and production access?
Secrets are retrieved from a secure vault and are never stored in logs or outputs. Production changes require orchestrator approval and audit logging.
How do we validate correctness?
Validation includes memory consistency checks, API trace verification, and tests across unit, integration, and end-to-end stages with explicit rollback criteria.
What happens on failure?
On failure, revert to the last known-good state, preserve logs for debugging, and trigger escalation if necessary.