Agent Autonomy Tiers

Agent Autonomy Tiers define explicit boundaries for AI agent actions, allowing me to delegate routine tasks fully while requiring approval for external-facing or high-impact operations. This system ensures that while my AI agents handle the bulk of the studio's operational and development work, I maintain oversight where it matters most, preventing unintended consequences.

What it is

Agent Autonomy Tiers are a classification system for the actions my AI agents can take, determining the level of human oversight required before execution. I categorize agent tasks into distinct tiers, from fully autonomous execution to requiring explicit human approval for every step. This isn't about limiting capability, but about managing risk and maintaining control over critical paths. The tiers are baked directly into my agent orchestration layer, VERA, which routes proposed actions based on their classification. For example, a code generation task for an internal utility might be Tier 0 (full autonomy), while deploying a new feature to production or sending an email to a customer would be Tier 2 (human review required). It's a pragmatic approach to agentic engineering, learned the hard way after a few too many unexpected deployments.

Why I do it this way

Operating a multi-product studio with AI as the team means delegating significant responsibility. Without clear autonomy tiers, I'd either be reviewing every trivial action or risking errors in critical areas. This system allows me to push the decision-making down to the agents for low-risk, high-volume tasks, freeing my time for architectural work and strategic decisions. It's a core component of how I manage risk across brands like Total Formula 1 and Pregnancy Power Hour. For instance, an agent tasked with updating dependencies in a monorepo can proceed without my direct intervention, but if that agent proposes a change to a Stripe integration, I need to see it first. This tiered approach is also crucial for maintaining a lean operational footprint; it's how I manage to run the entire studio without a traditional team. It directly supports my approach to CI Local Before CI Remote, ensuring that even autonomous changes are validated rigorously before reaching production environments.

How it works in practice

My agent orchestration layer, VERA, classifies each proposed agent action based on predefined rules. These rules consider the action's type (e.g., code commit, API call, database write, external communication), the target system (e.g., internal utility, production database, customer-facing service), and the potential impact.

• Tier 0: Full Autonomy. Agents execute directly. This applies to internal refactors, documentation updates, or generating boilerplate code. For example, a Claude Code agent might refactor a utility function in the Inky codebase, commit it, and push to a feature branch without my explicit approval. This is often paired with Docs as Source, where agents automatically update documentation based on code changes.
• Tier 1: Human Review (Async). Agents propose an action and generate a summary for my review. I receive a notification (e.g., via Slack or email through Resend) and can approve or reject the action at my convenience. This is used for non-critical deployments, minor content updates on static sites, or generating marketing copy drafts.
• Tier 2: Human Approval (Sync). Agents halt execution and require immediate, explicit approval before proceeding. This is reserved for high-impact actions: deploying to production on Vercel, making changes to financial systems via Mercury or Stripe APIs, sending emails to customer segments, or significant database schema migrations. This tier often triggers a more detailed audit process, sometimes even involving an Audits as Crons check before final approval.

Where this breaks down

The primary challenge with Agent Autonomy Tiers is maintaining accurate classification rules. As the complexity of my products evolves, new types of actions emerge, and existing ones might shift in their risk profile. A rule that worked for a simple API integration might be insufficient for a complex, multi-party transaction. I've learned the hard way that a poorly defined tier can lead to either excessive oversight (slowing down agent productivity) or insufficient oversight (leading to errors). False positives in Tier 2 can create unnecessary friction, while false negatives in Tier 0 can introduce bugs or security vulnerabilities without immediate detection. It requires continuous refinement of the classification logic within VERA and a clear understanding of the potential blast radius for each system.