Role Scoping & Naming

A well-scoped role has three properties: clear responsibility, explicit boundaries, and a defined deliverable. If you cannot state all three in two sentences, the role is not scoped. It is a vague intention dressed up as a job description.

Clear responsibility answers: "What does this agent do?" Not "helps with research" but "searches specified web sources and returns structured JSON with company name, funding stage, team size, product description, and three recent news items." Explicit boundaries answer: "What does this agent not do?" The research agent does not write prose. The research agent does not evaluate the quality of what it found. The research agent does not make recommendations. Boundaries prevent scope creep — and scope creep is the number one failure mode in multi-agent teams.

Naming is communication, not decoration. When you name an agent "Research Agent," the model immediately inherits expectations about what a researcher does. That is useful — it front-loads domain knowledge. But it is also dangerous if the name does not match the actual scope. An agent named "Analyst" that is actually responsible for data collection will confuse the parent coordinator and produce misrouted work.

The naming convention I use at Ryan Consulting follows a pattern: VERB + DOMAIN. HUNTER hunts leads. CLOSER closes deals. FORGE forges proposals. QUILL writes content. SCOPE scopes industries. The name communicates the action and the domain in a single word. For your own teams, the naming convention matters less than the consistency. Pick a pattern — verb-domain, role-title, function-name — and apply it across every agent in the team. Consistent naming makes the team architecture legible at a glance.

1. 1. State the Responsibility One sentence: "This agent searches the web for competitor pricing data and returns structured JSON." If you need two paragraphs to explain what the agent does, you have two agents, not one.
2. 2. Define the Boundaries List 3-5 things the agent explicitly does not do. "Does not write analysis. Does not evaluate data quality. Does not format for presentation." Boundaries are more important than responsibilities because they prevent the slow scope expansion that degrades team performance.
3. 3. Specify the Deliverable What exact format does the agent return? "Structured JSON with keys: company, product, price, tier, source_url." Ambiguous deliverables produce ambiguous outputs. Specify the schema.
4. 4. Choose a Clear Name The name should communicate the role at a glance. Prefer action-oriented names over status-oriented names. "Price Scanner" is better than "Data Helper." "Draft Writer" is better than "Content Assistant."