Agent Autonomy

“Agent Basics for Product Managers” part six
Previous: Agents, Skills, Tools, and MCP · Series home · Next: State Management in Agent Products

Agent demos often treat “the system did many steps on its own” as a benefit. In a real product, every additional autonomous decision introduces another path for error, excess cost, permission mistakes, or behavior that cannot be explained.

Autonomy is a product permission to allocate, not a default setting.

Start with one agent

One agent + tools
  → extract repeated methods into skills
  → isolate narrow tasks as specialists
  → control critical paths with workflows
  → add approval at high-risk steps
  → add trace, evaluation, and replay across the run

Structure should be added when real tasks reveal a stable boundary.

When a specialist is justified

A candidate task should recur, have clear input and output, benefit from independent context, models, tools, or permissions, support its own evaluation, and fail without taking down the whole system.

If it only needs a fixed method, use a skill. If it only performs an action, use a tool. If its steps are predictable, use a workflow node. Turning every business role into an agent usually projects an org chart into software.

Common orchestration patterns

A meeting-notes-to-PRD product may need one main agent, a set of BRD and review skills, a workflow for stage transitions, and perhaps a rubric-based reviewer. It does not need five agents holding a simulated meeting.

Product exercise

For every agent in an architecture, write down its unique context, tools, permissions, evaluation, and failure boundary. If those are not distinct, move the capability back into a skill, tool, or workflow node.

Do not create an agent when a tool is enough. Do not add free-form conversation when a skill is enough. Do not rely on model improvisation when a workflow can control the path.