Once you have a coordinator, you need specialized subagents that focus on specific domains. Each subagent gets its own instructions that define its expertise and boundaries.

Let me show you two examples.

First, a Payments API subagent. Its instruction file might say: "You are the Payments API specialist. Your domain includes the payment processing systems, third-party integration, transaction handling, and payment security. Focus on: API endpoint design, transaction validation, payment gateway integration, and error handling. Always consider: idempotency for payment operations, proper error handling for gateway failures, and audit logging for all financial transactions."

This agent knows the payments domain inside and out. When you ask it to add support for a new payment method, it knows to check the integration patterns, update the transaction monitoring system, add validation rules, and ensure proper audit logging - all the payments-specific concerns.

Second, a Trade UI agent - and by "trade" here I mean any user interface for a complex workflow. Its CLAUDE.md says: "You are the UI specialist. Your domain includes the user interface components, form handling, data visualization, and real-time updates. Focus on: component architecture, data flow, form validation, and user experience. Always consider: real-time data synchronization, optimistic UI updates, error recovery for failed operations, and responsive design."

This agent understands the frontend experience. Ask it to improve a complex form, and it knows to handle edge cases like validation states, error messaging, loading states, and data consistency - all the UI-specific concerns.

The key is making each agent deeply specialized. They don't need to know the whole system - just their corner of it. This focused expertise makes them much more effective than trying to make one agent understand everything.