AGENTS.md Template for Frontend Error Monitoring

Overview

Direct answer: This AGENTS.md Template governs the Frontend Error Monitoring workflow for AI coding agents, enabling both single-agent operation and multi-agent orchestration with explicit handoffs, tool governance, and human review points.

This template documents a repeatable, auditable, and secure workflow for detecting, reproducing, triaging, and resolving frontend errors. It supports orchestrated multi-agent activity as well as isolated single-agent runs, with clear constraints, source-of-truth, and escalation paths. It emphasizes AI coding agents interacting with frontend tooling, monitoring services, and CI/CD gates to maintain user-facing stability.

When to Use This AGENTS.md Template

• When you need to monitor and triage frontend errors from production and user reports across browsers and devices.
• When you want a clear, auditable handoff path between planner, detector, repro-archiver, implementer, tester, reviewer, and domain specialists.
• When governance, memory discipline, and security controls matter for automated remediation and human review.
• When you require reproducible steps, rollback points, and integration with your alerting and incident workflow.

Copyable AGENTS.md Template

# AGENTS.md

Project: Frontend Error Monitoring

Agent roster and responsibilities:
- planner (Orchestrator): define goals, task scopes, success criteria, and handoffs.
- error-detector: collect browser console/logs, network errors, and performance signals.
- repro-archiver (Researcher): create reproducible steps and synthetic repro data when possible.
- triage-watcher (Reviewer): classify severity, priority, and routing; approve fixes for implementation.
- patch-implementer (Implementer): implement code changes, config updates, and feature flags as needed.
- tester (Tester): run automated tests, simulate user sessions, and validate fixes in staging.
- reviewer (Reviewer): review patches, verify changes against acceptance criteria, and sign off.
- domain-specialist: verify domain-specific constraints (APIs, auth, user flows).
- monitor (Operator): observe production after changes and report anomalies.

Supervisor/Orchestrator behavior:
- The planner coordinates tasks, enforces timelines, and allocates resources. It may re-plan when blockers arise and ensures compliance with tool governance.
- All agents report status to the orchestrator and follow escalation paths for failures or blocked tasks.
- The orchestrator enforces memory rules, source-of-truth, and data access policies.

Context, memory, and source-of-truth rules:
- Source-of-truth includes production error logs, frontend telemetry, and versioned PRs.
- Memory is scoped to the current incident window; avoid long-term drift or leaking PII.
- All decisions and outputs must reference the canonical data sources (logs, traces, receipts).

Tool access and permission rules:
- Agents may call approved tooling via the orchestrator (e.g., repo actions, CI gates, issue trackers).
- Secrets are accessed via a vault; do not store secrets in agent memory or code.
- Production edits require explicit approvals and have rollback points.

Architecture rules:
- Favor declarative, idempotent changes. Avoid side effects outside approved pipelines.
- Use feature flags for risk-controlled deployments and staged rollouts.

File structure rules:
- Keep all workflow artifacts under a dedicated frontend-error-monitoring/ root.
- Each agent type gets its own folder with role-specific guidelines and templates.

Data, API, or integration rules:
- All external calls must go through approved proxies; handle retries and timeouts.
- Log inputs must be sanitized; avoid logging user PII.

Validation rules:
- Each patch must pass unit tests, integration tests, and a manual review plan before deployment.
- Reproductions must be validated against the observed incident.

Security rules:
- Do not expose secrets in logs or PR comments.
- Limit access by role and enforce least privilege.

Testing rules:
- Include regression tests that cover the error path and recovery path.

Deployment rules:
- Deploy changes through CI with a canary/staged rollout and post-deploy checks.

Human review and escalation rules:
- If automatic remediation is not approved by triage-watcher, escalate to human review.
- If a failure cannot be reproduced, escalate to domain-specialist.

Failure handling and rollback rules:
- If a fix causes new errors, rollback to the previous stable build and reopen the incident.
- Maintain an incident record with root cause and remediation steps.

Things Agents must not do:
- Do not modify production data or secrets. Do not bypass approvals. Do not drift away from the established incident lifecycle.

Recommended Agent Operating Model

The agent roster supports both single-agent operation and multi-agent orchestration. Roles include planner, error-detector, repro-archiver, triage-watcher, patch-implementer, tester, reviewer, domain-specialist, and monitor. Decision boundaries are clearly separated, with escalation to human review when uncertainty exceeds defined thresholds.

Recommended Project Structure

frontend-error-monitoring/
  ├─ agents/
  │  ├─ planner/
  │  ├─ detector/
  │  ├─ repro-archiver/
  │  ├─ triage-watcher/
  │  ├─ patch-implementer/
  │  ├─ tester/
  │  ├─ reviewer/
  │  ├─ domain-specialist/
  │  └─ monitor/
  ├─ orchestrator/
  ├─ data/
  ├─ src/
  ├─ tests/
  └─ .github/workflows/

Core Operating Principles

• Clear ownership and bounded context for each agent.
• Idempotent actions; repeated runs produce the same results without side effects.
• Maintain a single source of truth and reference data sources in all outputs.
• Use auditable logs and versioned artifacts for traceability.
• Respect privacy; avoid logging PII; encrypt secrets at rest and in transit.

Agent Handoff and Collaboration Rules

• Planner to Implementer: deliver a concrete task spec with acceptance criteria and success metrics.
• Implementer to Reviewer: submit a patch PR with a test plan and reproducible steps.
• Reviewer to Domain Specialist: route edge-case considerations and API constraints for validation.
• Tester to Planner: report test outcomes and trigger remediation if tests fail.
• Cross-agent collaboration: maintain a shared incident context document with links to logs, PRs, and test results.

Tool Governance and Permission Rules

• All tool calls must be mediated by the orchestrator and logged with task IDs.
• Code edits require PRs and automated checks; secrets must never be committed.
• APIs and external services must go through approved API gateways.
• Approval gates required before production deployment.

Code Construction Rules

• Follow project-wide coding standards and the incident lifecycle call trees.
• Keep changes small, well-scoped, and reversible via feature flags.
• Automated tests must cover error paths and normal operation.

Security and Production Rules

• Do not expose credentials in logs, PR comments, or artifacts.
• Enforce least privilege for all agents; rotate secrets per policy.
• All production changes require canary tests and rollback provisions.

Testing Checklist

• Unit tests for each new function or module.
• Integration tests with incident data and repro steps.
• End-to-end tests simulating real user error paths.
• Post-deploy validation in staging and canary environments.

Common Mistakes to Avoid

• Skipping reproducibility; relying on non-deterministic repro steps.
• Over-sharing secrets or bypassing approvals.
• Unclear handoffs leading to duplicated work or drift.
• Assuming the same agent model works for all errors or domains.

Related implementation resources: AI Agent Use Case for Construction Contractors Using On-Site Wearable Logs To Verify Mandatory Safety Training Compliance and AI Use Case for Rental Applications and Document Checks.

FAQ

What is the purpose of this AGENTS.md Template?

This template defines roles, handoffs, and constraints for frontend error monitoring using AI coding agents.

Which agents are involved in the Frontend Error Monitoring workflow?

Planner, error-detector, repro-archiver, triage-watcher, patch-implementer, tester, reviewer, domain-specialist, and monitor, with the orchestrator coordinating tasks.

How are handoffs between agents defined?

Handoffs occur at defined gates: planner assigns tasks, implementer completes, reviewer validates, tester verifies, and domain specialist confirms feasibility.

What tools and permissions are allowed?

Agents may call approved tooling via the orchestrator; secrets are stored in a vault and never logged or committed.

How is security and data privacy handled?

Only de-identified incident data is used; logs avoid PII; access is role-based and audited.