Live Dashboard Architecture AGENTS.md Template

Overview

Direct answer: This AGENTS.md Template defines a multi-agent workflow for a live dashboard architecture, clarifying roles, handoffs, and governance to deliver real-time dashboards with reliable data and auditable decisions. It serves both single-agent operations and multi-agent orchestration by codifying responsibilities, memory rules, and tool access in one source of truth.

The template governs the end-to-end lifecycle of a live dashboard: data ingestion from sources, transformation and normalization, real-time rendering, monitoring, alerting, and governance handoffs. It provides project-level operating context that agents can reference to avoid context drift and ensure consistent behavior across runs.

When to Use This AGENTS.md Template

• When building a real-time or near-real-time dashboard that requires multiple AI coding agents to collaborate across data, logic, and presentation layers.
• When you need explicit handoffs, escalation paths, and a single source of truth for the dashboard state and data lineage.
• When tool governance, secrets management, and production safeguards are essential to maintain auditable changes.
• When onboarding new agents or teams, to provide a concrete operating manual that minimizes context drift.

Copyable AGENTS.md Template

# AGENTS.md

Project Role: Live Dashboard Architecture Agent Team

Agent roster and responsibilities:
- IngestAgent: fetch real-time data from streaming sources and APIs, with schema versioning.
- TransformAgent: normalize, deduplicate, enrich, and window data for dashboard readiness.
- RenderAgent: feed the frontend data layer and drive real-time visuals; verify rendering latency SLAs.
- OrchestratorAgent: coordinate timing, memory, handoffs, retries, and error routing between agents.
- AlertAgent: monitor dashboards for anomalies, thresholds, and data quality issues; trigger alerts.
- ReviewAgent: human-in-the-loop QA and approval for production changes.
- ObservabilityAgent: collect metrics, traces, and dashboards health signals.

Supervisor or orchestrator behavior:
- OrchestratorAgent maintains the canonical dashboard state, enforces time-bounded handoffs, and routes failures for retry or escalation.
- It enforces memory boundaries, source-of-truth access, and end-to-end validation before rendering.

Handoff rules between agents:
- IngestAgent → TransformAgent: data availability within 200ms of source event.
- TransformAgent → RenderAgent: transformed payload ready, with schema version and latency metadata.
- RenderAgent → AlertAgent: if data quality or anomaly flags exceed thresholds.
- Any failure → OrchestratorAgent: apply retry policy; escalate to ReviewAgent if manual intervention is required.

Context, memory, and source-of-truth rules:
- All agents read/write to a single canonical data store with write-through semantics; memory is scoped to a dashboard session and cleared on session end.
- The source of truth is the primary ledger for data lineage and state transitions; derived views must reference this store.

Tool access and permission rules:
- Each agent has scoped API keys and role-based access; production dashboards can only be updated through the RenderAgent under approval.
- Secrets are stored in a vault; rotations and access must be auditable.

Architecture rules:
- Event-driven, idempotent transforms, and time-bounded operations; maintain end-to-end latency targets.
- All state changes must be auditable and replayable for debugging.

File structure rules:
- live-dashboard/
  - agents/
    - ingest/
    - transform/
    - render/
    - orchestrator/
    - alert/
    - reviewer/
    - observability/
  - data/
  - dashboards/
  - config/
  - tests/
  - docs/

Data, API, or integration rules when relevant:
- Data sources publish schema version and timestamps; APIs must be accessed through orchestrated routes with timeouts.
- No direct write to dashboards from non-render agents; all changes are mediated by the orchestrator.

Validation rules:
- Schema validation on ingest, data quality checks, and UI rendering checks for latency and correctness.

Security rules:
- Secrets vault, least privilege, rotation, and access auditing; production endpoints require approval gates.

Testing rules:
- Unit tests per agent, integration tests for the data flow, end-to-end dashboard tests, and rollout gating.

Deployment rules:
- Canary or blue/green deployments for UI changes; feature flags to enable incremental rollouts.

Human review and escalation rules:
- ReviewAgent signs off on data model changes and dashboard changes with potential impact to users; escalate to product owner for critical design decisions.

Failure handling and rollback rules:
- On critical failure, roll back to last known good snapshot; notify via AlertAgent and suspend changes until approved.

Things Agents must not do:
- Do not bypass the orchestrator; do not modify canonical data store directly; do not persist PII beyond necessity; do not perform production changes without approval.

Recommended Agent Operating Model

The operating model defines each agent’s decision boundaries and escalation paths for live dashboard orchestration:

• IngestAgent: trusted source-of-truth for data input; cannot infer UI semantics.
• TransformAgent: enforces schema and temporal alignment; cannot mutate source data.
• RenderAgent: deterministic rendering path; validates latency budgets before pushing UI updates.
• OrchestratorAgent: always the single point of handoff and failure routing; owns the end-to-end SLA.
• AlertAgent: thresholds and anomaly detection; escalates when signals cross defined limits.
• ReviewAgent: gates changes requiring human approval; ensures business and compliance alignment.
• ObservabilityAgent: ensures telemetry coverage; feeds dashboards about agent health.

Recommended Project Structure

live-dashboard/
├── agents/
│   ├── ingest/
│   │   └── ingest.py
│   ├── transform/
│   │   └── transform.py
│   ├── render/
│   │   └── render.py
│   ├── orchestrator/
│   │   └── orchestrator.py
│   ├── alert/
│   │   └── alert.py
│   ├── reviewer/
│   │   └── review.py
│   └── observability/
│       └── observe.py
├── data/
│   └── sources/
├── dashboards/
│   └── live/
├── config/
│   └── dashboards.yaml
├── tests/
│   ├── unit/
│   └── e2e/
└── docs/

Core Operating Principles

• Single source of truth for dashboard state; all agents reference canonical data.
• Explicit, auditable handoffs with time-bounded transitions.
• Least privilege access and secret management with rotation.
• Idempotent operations and deterministic results for reproducibility.
• Clear escalation paths for failures and design decisions.

Agent Handoff and Collaboration Rules

• Planner/Architect defines goals and acceptance criteria for dashboards.
• Implementer (Ingest/Transform/Render) executes against those criteria with observable traces.
• Researcher or Domain Specialist validates data semantics and domain constraints.
• Tester runs unit/integration tests; Reporter logs results and issues.
• Reviewer approves model changes and dashboard UI updates before production.
• Handoffs are explicit, time-bound, and accompanied by a shared memory snapshot and source-of-truth reference.

Tool Governance and Permission Rules

• Command execution is mediated by the orchestrator; no direct backdoor access to production endpoints.
• File edits require review and change control; secrets access is restricted to approved contexts.
• APIs must use vetted connectors with rate limits and retries; production keys are rotated.
• Approval gates exist for data model changes and dashboard release; rollbacks are pre-defined.

Code Construction Rules

• All agent code should be modular and testable; avoid hard-coding values; use configuration.
• Maintain traceability: all outputs include timestamps, source IDs, and schema versions.
• Ensure idempotence and deterministic results; do not rely on ephemeral memory for source-of-truth.
• Document assumptions in the AGENTS.md file and in code comments.

Security and Production Rules

• Secrets vault usage; keys rotated and access audited.
• Dashboard updates require approval; monitoring guards ensure no silent deployments.
• Data privacy controls: minimize PII exposure in real-time streams.

Testing Checklist

• Unit tests for each agent; integration tests for the end-to-end data flow.
• End-to-end tests for live dashboard latency and correctness.
• Canary/rollout checks and rollback plans for dashboard releases.

Common Mistakes to Avoid

• Skipping explicit handoffs or memory synchronization between agents.
• Direct data store writes bypass orchestrator or audit trails.
• Overloading agents with UI responsibilities beyond their domain.
• Ignoring latency budgets and data lineage during changes.

Related implementation resources: AI Use Case for Car Dealerships Using Facebook Marketplace Data To Price Incoming Trade-In Vehicles Competitively and AI Use Case for Corporate Event Managers Using Slack To Orchestrate Day-Of Venue Tasks Across Multi-Department Teams.

FAQ

What is an AGENTS.md Template for live dashboards?

It defines a project-level operating manual for AI coding agents executing a live-dashboard workflow, including roles, handoffs, and governance.

Who should use this template?

Teams building real-time dashboards with multiple agents, such as data engineers, frontend renderers, and orchestrators.

What are the core tools and access rules?

Secrets, API keys, and production endpoints are restricted and accessed via approved flows; changes require sign-off.

How are agent handoffs defined?

Handoffs are explicit, time-bounded transitions between agents with shared context and source-of-truth.

How do I validate and deploy changes?

Run unit tests, integration tests, and staged deployments with rollback plans.