Working definition: a tool is agent-first when an agent can use it without relying on hidden UI state, unclear side effects, or repeated human translation. That makes it easier to choose, wire into a workflow, and monitor in production.
The six criteria
1. InspectableThe agent can discover capabilities, schemas, permissions, current state, errors, and examples before acting.
2. ScriptableEvery important workflow has a stable API, CLI, MCP tool, webhook, or file interface that can be called repeatably.
3. BoundedActions can be scoped by role, workspace, resource, budget, time, and approval level rather than relying on all-or-nothing access.
4. VerifiableThe tool exposes receipts: IDs, status endpoints, logs, diffs, previews, dry-runs, audit trails, and machine-readable success/failure signals.
5. RecoverableFailures are explicit, retries are safe, destructive operations have rollback paths, and partial completion is visible.
6. ComposableThe tool fits into wider agent workflows: repos, terminals, browsers, inboxes, docs, schedulers, CI, deployments, and human handoff.
What agent-first is not
Agent-first does not mean removing humans or giving a model unlimited authority. It means the tool gives agents clear limits, visible outcomes, and recovery paths.
- It is not “we have a chatbot”. A chatbot can be a front door, but agents need callable operations and clear state.
- It is not “we have an API”. APIs without docs, examples, scoped credentials, idempotency, and clear errors still force brittle guesswork.
- It is not “let the agent use the web app”. Browser control can help, but it should not be the main integration path.
A quick evaluation checklist
- Can an agent list available actions and required inputs without reading a private Notion page or guessing from the UI?
- Can it run a dry-run or preview before making a consequential change?
- Can credentials be scoped narrowly enough that a compromised agent cannot damage the whole account?
- Does every write action return a durable handle: URL, ID, commit, diff, job ID, receipt, or audit event?
- Can the agent ask “what happened?” after a timeout, crash, or network failure and get a truthful answer?
- Are error messages written for recovery, with codes and suggested next actions, not just for human display?
- Can a human review, approve, undo, or take over at natural checkpoints?
Example: a deployment tool
A basic deployment button says “deploy latest main” and returns a spinner. A better deployment tool exposes:
deploy planto preview files, services, migrations, and expected downtime.deploy run --ref <sha>with an idempotency key and scoped environment credentials.deploy status <job_id>with structured states rather than only streaming logs.deploy rollback <release_id>and a clear policy for irreversible steps.- Links to logs, health checks, diffs, and audit events that the agent can cite back to a human.
Why this matters when choosing tools
Teams are already using AI coding assistants, workflow agents, and automation platforms. The bottleneck is often the surrounding tools: they were built for people clicking screens, not agents working across systems. Better agent-tool fit makes agent work easier to verify, recover, and hand back to a human when needed.
Next: Use the scorecard, checklists, and patterns to review tools before agents depend on them.