Skip to main content
Designing and provisioning cloud networks can quickly overwhelm a single AI agent. This guide shows how to split responsibilities into subagents for safe, auditable, and scalable VPC automation. The approach mirrors a real operations team: one orchestrator coordinating smaller specialists (subagents) with tightly scoped permissions. Why not one large agent?
  • A single agent that handles design, networking, and security accumulates a huge context and needs broad permissions. That increases the blast radius for misconfigurations and makes debugging hard.
  • When network topology, firewall rules, and security audits all live in one conversation, unrelated details crowd each other, and authority is not separated.
Instead, build a team of subagents
  • A subagent is a focused Claude agent spawned by a parent (orchestrator) to perform one task.
  • Each subagent has:
    • its own conversation context (so domain chatter doesn’t interfere),
    • a narrow toolset (principle of least privilege),
    • a system prompt that defines its role and constraints.
Typical agent-definition fields Registering subagents
  • Register subagents by passing a list of agent definition objects to the SDK client.
  • If you start a definition with “Use proactively”, Claude will select that specialist automatically when a request matches the description.
Roles for VPC automation
  • Network agent: creates the VPC, subnets, route tables, and attaches gateways.
  • Security agent: creates security groups, NACLs, policy checks and performs audits.
  • Orchestrator (parent): decomposes requests, delegates to subagents via the Task tool, and aggregates results.
A dark-themed diagram titled "One Orchestrator, Two Specialists" showing a request to "Build a VPC for a 3-tier web app" where an Orchestrator delegates tasks to a Network Agent (VPC, subnets, route tables) and a Security Agent (security groups, NACLs) and then aggregates results.
Principle of least privilege: lock tools per agent
  • Limit each subagent to only the tools necessary for its job.
  • Example tool sets:
    • Network agent: ["Bash", "Read"] (run AWS CLI commands and inspect state).
    • Security agent: ["Bash", "Read"] (create and audit security rules).
    • Orchestrator (parent): ["Bash", "Read", "Write"] (coordinate and perform higher-privilege tasks).
  • Narrow tool access reduces the blast radius and enforces separation of duties at runtime. Combine this with a precise system prompt for defense in depth: neither the network agent nor the security agent should be able to perform the other’s responsibilities, either by prompt or by tools.
Restrict tools to the minimum required for each agent. Combined with a precise system prompt, this reduces risk by enforcing separation of duties.
Order matters: create networking resources (VPC, subnets, route tables) before attaching security controls that depend on resource IDs. Also ensure credentials and IAM roles used by agents follow least privilege rules.
How the team builds a 3-tier VPC
  • The network agent runs first to create the underlying resources:
    • VPC: 10.0.0.0/16
    • Public subnets with a route to an Internet Gateway (for the web tier)
    • Private subnets with no direct internet route (for app and DB tiers)
  • The security agent runs next to apply policies:
    • Create security groups for web, app, and database tiers (default deny, explicit allow).
    • Create subnet-edge NACLs to harden ingress/egress at the subnet level.
    • Apply rules: web tier allows 80/443 from the internet; app accepts traffic only from the web security group; db accepts traffic only from the app security group.
A diagram of an AWS VPC (10.0.0.0/16) showing a public subnet (10.0.1.0/24) and a private subnet (10.0.11.0/24). The private subnet contains Web, App, and Database tiers with security group rules, a route to an Internet Gateway, and a subnet-edge NACL.
Run it statefully using a Claude SDK client
  • Use a stateful client so conversation context (and resource IDs) persist across turns.
  • A typical run has four turns:
Turn 1 — Design
  • Orchestrator plans a complete VPC for a three-tier web app and determines necessary resources and dependency order.
Turn 2 — Network
  • Orchestrator delegates to the network configurator using the Task tool.
  • The network agent runs Bash commands (e.g., aws ec2 create-vpc) and returns real resource IDs.
Turn 3 — Security
  • Orchestrator passes the created resource IDs to the security specialist.
  • The security agent creates security groups and NACLs with the correct allow/deny rules for each tier.
Turn 4 — Review
  • Orchestrator verifies the final state, checks least privilege across tiers, and returns a consolidated report.
Example CLI-style run
Sample agent definition (JSON)
  • Register each subagent as a definition object and supply the tools field to enforce least privilege.
Extend the team
  • Add extra specialists (e.g., audit-specialist, iam-manager, terraform-applier) to plug in external tools or cross-check configurations.
  • Use the Task tool for delegation so the orchestrator never calls subagents directly — Claude chooses the right specialist automatically based on description.
Benefits summary Links and references What was once one overloaded agent is now a small, safe, well-run team with clear ownership and limited permissions — suitable for production-grade VPC automation.

Watch Video

Practice Lab