AGENTS.md Template for Feature Store System Design

Overview

Direct answer: This AGENTS.md template defines the operating manual for AI coding agents orchestrating a feature store system design, enabling both single-agent workflows and multi-agent orchestration with clear handoffs, memory, and governance.

When to Use This AGENTS.md Template

• When designing a feature store architecture (offline and online stores) and feature registry.
• When coordinating multi-agent workflows across planner, implementer, reviewer, tester, researcher, and domain specialist roles.
• When you need auditable, repeatable governance for data pipelines, feature computations, and serving layers.
• When you require explicit handoff rules, memory of decisions, and source-of-truth documents.
• When you want enforced tool governance and security in cloud environments.

Copyable AGENTS.md Template

# AGENTS.md

Project Role: Data Platform Lead / AI Platform Engineer responsible for the feature store system design, governance, and multi-agent orchestration.

Agent roster and responsibilities:
- Planner: defines architecture, objectives, constraints, and milestones; collects stakeholder requirements.
- Implementer: builds ingestion pipelines, feature computation, online/offline stores, and serving code.
- Reviewer: validates design, code quality, and adherence to governance rules.
- Tester: validates data quality, feature correctness, and end-to-end workflows.
- Researcher: investigates best practices for feature stores, registry schemas, and data models.
- Domain Specialist: ensures domain semantics and feature definitions align with business needs.

Supervisor or orchestrator behavior:
- The orchestrator maintains the plan, sequencing, and gating of handoffs between agents.
- It monitors constraints, memory, and source-of-truth; re-plans when drift is detected.

Handoff rules between agents:
- Planner -> Implementer: hand off architectural design, interfaces, and deliverables.
- Implementer -> Reviewer: hand off code, tests, and deliverables for validation.
- Reviewer -> Implementer: address feedback and re-run validations.
- Implementer -> Tester: provide end-to-end tests and data validations.
- Tester -> Planner: report results and corrective actions.

Context, memory, and source-of-truth rules:
- Maintain a shared knowledge base with decisions, rationales, and versioned artifacts.
- Source-of-truth: architecture doc, data dictionary, feature registry schema, and Git history.
- Memory scope: design decisions, data lineage, feature definitions, and dependencies.

Tool access and permission rules:
- Use least privilege for all tools; secrets are stored in a vault.
- Ingest and deploy happen through controlled pipelines with approvals.
- Do not expose credentials in code or logs.

Architecture rules:
- Feature store comprises offline store, online store, and a feature registry.
- Clear data lineage and versioning for features.
- Idempotent ingestion and deterministic feature calculation.

File structure rules:
- Keep architecture docs, pipeline configs, and code under organized folders.
- Do not include irrelevant assets.

Data, API, or integration rules:
- Define source connectors, data formats, schema evolutions, and API contracts.
- Enforce feature definition standards and metadata.

Validation rules:
- Every feature must pass unit tests, data quality checks, and end-to-end validations.
- Drift and anomaly checks on feature statistics.

Security rules:
- Secrets must be stored securely; access controls enforced on data planes.
- Codesign and approve changes before production.

Testing rules:
- Unit tests for feature computations; integration tests for ingestion and serving; end-to-end tests for scenarios.

Deployment rules:
- CI/CD pipelines with gatekeeping; blue/green or canary deployments for changes to production.

Human review and escalation rules:
- All critical design decisions require a human review; escalate when models or data do not meet policies.

Failure handling and rollback rules:
- Revert to previous feature definitions; rollback ingestion or serving if failures occur.

Things Agents must not do:
- Do not bypass approvals; do not mutate production data without tests and approvals.
- Do not leak credentials; never hardcode secrets.

Recommended Agent Operating Model

The agent roles operate with clear decision boundaries and escalation paths. The Planner designs architecture; the Implementer builds code; the Reviewer validates; the Tester confirms quality; the Researcher gathers best practices; the Domain Specialist ensures domain alignment. Handoffs are gated by tests and reviews; state is stored in a central memory and source-of-truth store to prevent drift. Escalation goes to a Human Supervisor when risk thresholds are exceeded.

Recommended Project Structure

feature-store-design/
├── orchestrator/
├── planner/
├── implementer/
├── reviewer/
├── tester/
├── researcher/
├── domain-specialist/
├── data/
├── docs/
└── configs/

Core Operating Principles

• Single source of truth for architecture and feature definitions.
• Explicit handoffs with gating by tests and reviews.
• Least privilege and secure handling of secrets.
• Idempotency and traceability of changes.
• Clear boundary between design, implementation, testing, and validation.

Agent Handoff and Collaboration Rules

• Planner passes architecture, interfaces, and acceptance criteria to Implementer.
• Implementer passes implemented components, tests, and docs to Reviewer.
• Reviewer provides feedback; Implementer iterates until acceptance.
• Tester runs data quality and end-to-end tests; results are reported to Planner.
• Researchers and Domain Specialists provide ongoing domain guidance and best practices throughout.

Tool Governance and Permission Rules

• All tool access follows least privilege; secrets in vault; audit logs kept.
• Code changes go through pull requests; production changes require approvals.
• API calls to external services must be authenticated and authorized.

Code Construction Rules

• Follow feature store design guidelines; maintain versioned artifacts.
• Keep functions small, testable, and well-documented.
• Ensure idempotent ingestion and deterministic feature computation.

Security and Production Rules

• Protect data and secrets; implement access controls and encryption in transit and at rest.
• Have rollback plans and incident response playbooks.

Testing Checklist

• Unit tests for feature calculations.
• Integration tests for ingestion pipelines and registry interactions.
• End-to-end tests for feature serving and drift checks.

Common Mistakes to Avoid

• Skipping governance and memory of decisions.
• Bypassing handoffs or skipping reviews to save time.
• Secret leakage or insecure storage of credentials.

Related implementation resources: AI Agent Use Case for Intermodal Transport Providers Using Rail Schedules To Coordinate Seamless Truck-To-Train Transfers and AI Agent Use Case for Aerospace Engineering Teams Using Wind Tunnel Test Data To Iterate Aerodynamic Winglet Designs.

FAQ

What is the purpose of this AGENTS.md Template for Feature Store System Design?

This AGENTS.md Template provides a formal operating manual for AI coding agents to design and govern a feature store system, enabling both single-agent and multi-agent orchestration with clear handoffs, memory, and source-of-truth rules.

How does multi-agent orchestration work in this template?

The Planner defines the architecture and milestones; the Implementer builds components; the Reviewer validates; the Tester confirms quality; Researchers gather best practices; Domain Specialists ensure domain alignment. The Orchestrator gates handoffs based on tests and reviews.

What are the critical handoff rules between agents?

Handoffs follow a gated sequence: Planner → Implementer (design and interfaces); Implementer → Reviewer (code and tests); Reviewer → Implementer (feedback); Implementer → Tester (end-to-end tests); Tester → Planner (results and actions).

How are security, data governance, and production rules enforced?

Least privilege access, vault-stored secrets, code reviews, and gated deployments guard production. Data contracts and lineage are maintained in the feature registry and documentation.

Can this template be adapted for offline and online feature stores?

Yes. The template supports both offline/online architecture, with a registry that versions features and maintains compatibility across serving layers.