Agents

Governed machine access for Craft CMS and Craft Commerce.

Agents gives Craft a safe API and control plane for AI agents, automations, and integrations. It provides one governed machine-access layer with scoped APIs, managed credentials, diagnostics, and optional approval controls, so production behavior stays predictable, observable, and auditable.

Managed accounts can be used by external runtimes such as agents, orchestrators, workers, and scripts.

You set the boundary. External runtimes work inside it. Agents enforces the rules through scopes, approvals, and audit records.

Current plugin version: 0.29.1

For Agencies Running Craft Sites For Clients

Agents is designed for agencies and delivery teams that need to introduce automation without losing visibility, approval control, or operational accountability.

Product Positioning

Agents helps agencies turn AI and automation work into a governed service layer on top of client websites. Instead of building custom endpoints or handing over risky backend access, teams get one control plane for machine credentials, approvals, diagnostics, and operational proof.

Why Teams Use Agents

• Ship automation work without inventing custom machine-access layers for every project
• Keep approvals, audit trail, and machine credentials inside the Craft CP
• Reuse successful job patterns across multiple client sites instead of rebuilding them each time

Current Product Focus

Near-term product work concentrates on two outcomes:

Safer Bounded Automation

Teams need to automate approved parts of a site without widening access beyond what the client or operator intended. That is where governed write boundaries, approvals, and clearer execution lanes matter.

Reusable Job Patterns

Teams also need more than raw API access. They need reusable patterns they can carry from one project to the next:

• account templates
• starter workers
• job guides
• bootstrap artifacts

That is the role of job starter kits: turning governed machine access into repeatable delivery patterns instead of one-off integration work.

Current managed jobs in Agents are configuration and handoff surfaces, not hosted jobs. Agents can store job intent and show operator-facing visibility, but the actual schedule runner, fetch/reasoning loop, and execution still live in an external runtime you operate.

What Agents Provides

• Structured API access:
  • /agents/v1/health
  • /agents/v1/readiness
  • /agents/v1/auth/whoami
  • /agents/v1/adoption/metrics
  • /agents/v1/metrics
  • /agents/v1/incidents
  • /agents/v1/lifecycle
  • /agents/v1/diagnostics/bundle
  • /agents/v1/products
  • /agents/v1/variants, /agents/v1/variants/show
  • /agents/v1/subscriptions, /agents/v1/subscriptions/show
  • /agents/v1/transfers, /agents/v1/transfers/show
  • /agents/v1/donations, /agents/v1/donations/show
  • /agents/v1/orders, /agents/v1/orders/show
  • /agents/v1/entries, /agents/v1/entries/show
  • /agents/v1/assets, /agents/v1/assets/show
  • /agents/v1/categories, /agents/v1/categories/show
  • /agents/v1/tags, /agents/v1/tags/show
  • /agents/v1/global-sets, /agents/v1/global-sets/show
  • /agents/v1/addresses, /agents/v1/addresses/show (flag-gated)
  • /agents/v1/content-blocks, /agents/v1/content-blocks/show
  • /agents/v1/users, /agents/v1/users/show (flag-gated)
  • /agents/v1/changes
  • /agents/v1/sections
  • /agents/v1/sync-state/lag
  • /agents/v1/sync-state/checkpoint
  • /agents/v1/templates
  • /agents/v1/starter-packs
  • /agents/v1/schema
• API contract descriptors:
  • /agents/v1/capabilities
  • /agents/v1/openapi.json
  • aliases: /capabilities, /openapi.json
  • vendor agent handbook (Markdown): https://marcusscheller.com/docs/agents/agent-handbook.md
• Webhook reliability:
  • signed webhook delivery with retries
  • per-key event routing interests
  • dead-letter queue visibility + replay (/agents/v1/webhooks/dlq*)
• Operator notifications:
  • email-first notifications for approvals, execution issues, webhook failures, and scheduled system-status changes
• Governed control-plane flows (feature-flagged):
  • policies
  • approvals with explicit assurance modes and audit trail
  • dry-run policy simulation
  • idempotent action execution
  • immutable audit trail
• Craft CP operations:
  • Status (merged readiness and security operator surface)
  • Settings (runtime switches, operator notifications, webhook transport, reliability thresholds)
  • Accounts (scopes, event routing interests, TTL/reminder, IP allowlists)
  • Approvals (when experimental governed writes are enabled)

Trust Boundary

• Operators define the governed boundary.
• External runtimes operate inside that boundary.
• Production actions flow through scoped HTTP APIs, request validation, policy gates, and audit records.
• The plugin is not a shell execution layer for production agents.
• craft agents/* commands are operator and developer tooling, not the production trust boundary.
• /capabilities and /openapi.json are the canonical machine-readable contract descriptors.
• Experimental governed-write surfaces remain behind PLUGIN_AGENTS_WRITES_EXPERIMENTAL.

See Execution Model for explicit trust-boundary and stability details.

Start Here

1. Installation & Setup
2. Configuration
3. First Worker
4. Agents vs Element API
5. Job Guides
6. Get Started
7. Status, Accounts & Approvals
8. API Overview
9. Agent Bootstrap
10. Starter Packs
11. Security

If you want the roadmap view, see the Roadmap.