awesomechecklists
llms.txtGitHub ↗
/

17 — AI Agents and Tool Orchestration Checklist#

Verify that AI agents achieve bounded tasks through permitted tools, safe handoffs, controlled state, and meaningful human supervision. The model may propose plans and actions, but independent application controls must enforce access, approvals, budgets, and actual execution.

Scope: Frontend-specific. This file is one part of the 17_AI_Agents_and_Tool_Orchestration.md checklist. Apply the domain-wide release gate across all applicable scope files; each checklist ID remains unique.

Review details#

  • Project / product:
  • Release / version / environment:
  • Scope and applicable jurisdictions / markets:
  • Agent tasks, delegated roles, and tool inventory:
  • Model / runtime / connector versions and execution environment:
  • Authorized users, approvals, permissions, and limits:
  • Review / security / operations owner:
  • Review date:
  • Decision: Pending / Approved / Approved with documented exceptions / Blocked

How to use#

  1. Copy this shared template into project-specific review records; leave all repository checkboxes unchecked.
  2. Define the agent's goal, scope, tool authority, user delegation, human-approval policy, and stop conditions before running tests or granting production access.
  3. Mark [x] only after verifying workflow diagrams, tool permissions, adversarial and failure-mode tests, approval traces, safe retry behavior, monitored execution limits, or qualified risk decisions. Track failures, evidence, accepted exceptions, and justified N/A in project records/issues keyed by AGENT ID rather than adding an evidence table here.
  4. Review ## API Checks and ## Frontend Checks separately where those surfaces exist; document N/A and why for headless or disconnected deployments.
  5. Do not assume particular SDK approval, session, or MCP protocol features apply to other frameworks. Treat model messages and tool outputs as untrusted; enforce permissions, schemas, and side-effect safeguards in the calling application or infrastructure.
  6. Reassess after changing tools, providers, delegated identities, workflow goals, model or policy versions, execution sandboxes, approval rules, or user-facing actions. Coordinate detailed red-team, governance, monitoring, and regression review with the other AI-specific templates.

Frontend Checks#

  • AGENT-117 Tell users when the system may perform actions using an AI agent and what its authorized capabilities are.
  • AGENT-118 Distinguish read-only assistance, suggested actions, and actual changes to external accounts or data.
  • AGENT-119 Show meaningful workflow progress and pending steps without inventing tool successes or completion states.
  • AGENT-120 Display the exact proposed action, destination, material data, and consequences before asking for approval.
  • AGENT-121 Provide explicit and accessible approve, reject, cancel, and request-changes controls for applicable actions.
  • AGENT-122 Do not preselect high-impact approvals or imply that a generic message grants unlimited future permission.
  • AGENT-123 Clearly indicate when approvals have expired, were rejected, or must be requested again because arguments changed.
  • AGENT-124 Test approval interfaces against stale browser tabs, duplicate clicks, disconnected sessions, and retries.
  • AGENT-125 Make it easy to inspect an authorized history of completed tool actions and their confirmed results.
  • AGENT-126 Provide understandable status for queued, in-progress, paused, partially successful, failed, and canceled runs.
  • AGENT-127 Prevent frontend state from being interpreted by the server as proof of authorization or completed execution.
  • AGENT-128 Protect pending approval details, tokens, and session context from other users and browser-account switches.
  • AGENT-129 Offer a visible stop or cancel control where workflows can continue or consume resources after the initial response.
  • AGENT-130 Communicate which actions may already have completed when cancellation or rollback is requested.
  • AGENT-131 Give users an appropriate way to correct mistakes, undo supported actions, or escalate irreversible outcomes.
  • AGENT-132 Ensure run updates, progress announcements, tool statuses, and approval dialogs work with keyboard and assistive technologies.
  • AGENT-133 Keep streaming outputs or agent plans clearly distinct from final verified results and authoritative external state.
  • AGENT-134 Safely render tool names, model-proposed arguments, retrieved text, and external service messages without script injection.
  • AGENT-135 Test localized approval language and high-impact confirmation text where multiple languages are supported.
  • AGENT-136 Provide a means to report harmful or unauthorized agent behavior with privacy-respecting diagnostic references.

Release gate#

  • The agent's business purpose, task boundaries, permitted tools, authorized user population, run limits, and responsible owners are documented and reviewed.
  • Tool and connector inventory, least-privilege scopes, tenant boundaries, schema validation, and external execution/network restrictions have been tested against unauthorized access and tool misuse.
  • Representative end-to-end tasks meet agreed outcome and severe-error criteria, including blocked objectives, malformed tool data, and adversarial indirect instructions.
  • Routing and handoff tests confirm that specialist agents cannot gain extra privileges, improperly disclose context, or bypass normal approval and resource limits.
  • High-impact tool calls require authenticated, action-specific human approval bound to exact parameters; rejected, expired, changed, or replayed approvals do not execute.
  • Cancellation, shutdown, crash recovery, duplicate delivery, and partial external side effects have tested safe outcomes or a documented compensating/escalation procedure.
  • API and frontend consumers can distinguish proposed actions from confirmed execution and handle pauses, refusals, errors, and partial completion safely.
  • Monitors, alerts, incident response, execution traces, cost and throughput limits, and emergency tool revocation are operational with named responders.
  • Material unresolved authority, user-harm, privacy, prompt-injection, or side-effect risks are resolved or have an explicitly authorized and time-bound disposition.

Domain-specific approval rule: Block sign-off if an agent can reach unauthorized data or tools, autonomously cross approved scope, execute material unapproved side effects, resume with forged authority, or replay irreversible actions without accepted controls. Passing the checklist does not imply that agents are infallible, that actions are exactly once, or that a specific security or regulatory certification has been achieved.

Trusted references and scope#

The following primary and authoritative sources inform these practical review checks. Their SDK-specific details should be mapped to the actual framework and deployment environment rather than assumed to apply universally.

Applicability: MCP tool discovery is not permission to invoke every available function. Its November 2025 authorization specification is optional for some transports and implementations, and newer drafts may differ. OpenAI and Microsoft agent approvals must be implemented with server-owned decisions and current permission checks; resuming a previously approved run does not ensure exactly-once external side effects. OpenTelemetry conventions describe instrumentation but do not justify storing protected prompts or tool payloads. OWASP risk lists and NIST AI RMF practices support threat modeling and governance rather than certifying deployment safety. Anthropic's 2024 orchestration article carries an explicit notice that tooling has evolved.

Source review date: 2026-11-12.

Suggested testing tools#

Choose tools appropriate to the project's stack and risks; automation supports evidence but does not approve the checklist.

  • Test focus: tool permissions, budgets, retries, state handoffs, and high-risk approval gates; include browser and client behavior where applicable.
  • Cross-stack: promptfoo + OpenTelemetry.
  • Python: LangGraph testing + pytest; for pytest-based suites, run python -m pytest -q.
  • TypeScript: promptfoo + Vitest; for Vitest-based suites, run npx vitest run (or npx playwright test for E2E).
  • JavaScript: promptfoo + Jest; for Jest-based suites, run npx jest --ci (or npx playwright test for E2E).
  • Evidence: Save tool versions, configuration, test environment, fixtures, results, and links in project-specific review records using the existing checklist IDs. Expert review remains necessary where relevant.

Suggested AI skills for verification#

These are optional agent review aids, not automated passes or release approval. Each linked repository had at least 1,000 GitHub stars when checked on 2026-11-12; counts are per repository, not per skill, and do not indicate security or correctness.

  • agent-owasp-compliance — Review agentic threat and tool-abuse scenarios (github/awesome-copilot, 41,073 repo stars).
  • workflow-orchestration-patterns — Check agent state, retries, and handoffs (wshobson/agents, 42,437 repo stars).
  • agentic-eval — Test bounded tool outcomes and regressions (github/awesome-copilot, 41,073 repo stars).

How to check: In a project-specific copy, have the agent audit the frontend scope and map findings to this file's existing checklist IDs, with code/configuration references, reproducible test results, failed or inapplicable cases, and uncertainties. Independently verify findings; keep shared template boxes unchecked and retain human approval requirements.

Before use: Read the skill's SKILL.md, referenced scripts, license, and requested tool permissions. Only execute vetted skills with appropriate access in a controlled environment.

Important warning: reference only#

⚠️ Reference only — not a definitive or exhaustive checklist. This template is a starting point for review, not the ultimate authority or a guarantee of project safety, quality, regulatory compliance, accessibility, security, or launch readiness.

Use project-specific judgment and independent verification. Requirements and risks evolve and differ by project, technology, and jurisdiction. Adapt the checks, consult current authoritative sources, perform relevant tests, and obtain qualified specialist review or approval when appropriate. Checking every box does not replace these steps.

Reference, not a certification. Check applicability, verify important claims against current primary sources, and seek expert review where necessary. Suggest an improvement.