Module 16 · Lesson 01

Named Agent Design — From Vague Need to Specific Capability

Reading time: 18 minutes Track: Yungsten Tech Employee Curriculum · Engineer/Consultant path

What a named agent is

A named agent is a Claude-powered tool configured for a specific, recurring job — given a name, a personality, a set of instructions, and connections to the data and tools it needs to do that job. "Mia" reviews contracts. "Remi" drafts client status updates. "Kai" analyzes the week's sales data and surfaces anomalies.

Naming matters. A named agent is a team member, not a feature. The name creates accountability, clarity about what it does and doesn't do, and a natural way for the team to talk about it. "Ask Mia" is a workable instruction. "Use the AI thing in the contract folder" is not.

The design process: four questions

Question 1: What is the one job?

Every agent has one primary job. Not ten jobs. One.

Start with the client's description ("help with contracts") and narrow until you have a specific action: "Review vendor contracts for non-standard indemnification clauses and flag them with a plain-language explanation."

If the description still has "and" in it — "review contracts and generate summaries and track deadlines" — it's not scoped yet. That's three agents, not one.

Question 2: What are the inputs?

What does the agent need to do its job? Documents, data, context? Where do these come from? How are they provided — pasted in, uploaded, pulled from a system?

The input definition determines what systems you need to connect and how the operator will interact with the agent.

Question 3: What is the output?

What does the agent produce? A document, a list, a decision, a summary, a flag, a draft?

The output definition determines the format of the system prompt, what the operator does with the result, and how you measure whether the agent is working.

Question 4: What are the operating constraints?

What should the agent never do? What data should it never use? What should it flag for human review rather than handle autonomously?

The constraint definition is where you bake in the client's risk tolerance. A conservative client with regulatory exposure gets tighter constraints than a scrappy startup. Both are valid; document the choice explicitly.

The agent specification

Before building anything, write a one-page agent specification:

Agent name: [Name]
Primary job: [One sentence, one verb]
Inputs: [What it receives and from where]
Outputs: [What it produces]
Constraints: [What it must not do or decide]
Operator: [Who runs this and at what capability level]
Success criteria: [How we know it's working]

This specification is the reference document for building, testing, and handoff. Any time the agent's behavior is questioned, you return to it.

Common scoping mistakes

Too broad: "Help with customer communications" — this is a category, not a job.

Too narrow: "Draft the exact email we send to Enterprise customers in the Midwest after their second renewal" — this is a template, not an agent.

Solving the wrong problem: The client asks for a meeting summary agent when their actual pain is action items that don't get followed up. The right agent generates and tracks action items, not summaries.

The scoping conversation is where you add the most value — often more than in the building itself.