בניית צוות Agents מתמחים עם Claude Code

תוכן עניינים
זהו החלק הרביעי בסדנת Claude Code – Agentic Workflows. עד כה בנינו בהדרגה את התשתית: הכרנו את מבנה הפרויקט ואת קבצי ההגדרה, בנינו Skill בשם customer-intake שמטפל בפניות לקוח, ולאחר מכן יצרנו Subagent יחיד שמנתח את צורכי הלקוח. עכשיו אנחנו עוברים לשלב המתקדם והמרתק באמת.
 

בחלק הזה לא נעבוד עם agent אחד, אלא עם צוות שלם של agents מתמחים. נלמד איך מפצלים משימה מורכבת בין כמה סוכנים, כאשר כל אחד בודק זווית אחת בלבד ומחזיר handoff קצר, ו-Claude הראשי משמש כ-orchestrator שמחבר את כל התמונה.
 
המסר המרכזי פשוט: לא כל agent צריך לדעת הכול.

למה צוות agents ולא agent אחד גדול?

הפיתוי הטבעי הוא לבנות agent אחד "חכם" שיודע לעשות הכול. אבל בפועל, הגישה הזו מובילה לתשובות ארוכות ומבולבלות, לאיבוד פוקוס, ולקושי לאתר היכן בדיוק נפלה טעות. החלוקה לצוות מתמחה פותרת את הבעיות הללו.

 

היתרון המרכזי הוא בידוד ההקשר: כל agent מקבל גבול מקצועי ברור, עובד מזווית אחת בלבד, ומחזיר תוצר קצר וממוקד. כך, כשמתעוררת בעיה, קל מאוד לזהות באיזה תחום אחריות היא נמצאת. בנוסף, כשכל מומחה מתמקד בתחומו, איכות הניתוח עולה משמעותית לעומת assistant כללי שמנסה לכסות את כל הזוויות בבת אחת.

 
בידוד ההקשר הוא טכניקה אחת מני רבות בנושא החשוב ביותר בפיתוח אג׳נטי – ניהול הזיכרון (או Context Engineering). ניתן ללמוד על טכניקות נוספות במדריך לזיכרון אג׳נטי.

תרחיש המעבדה: הפנייה העסקית

במעבדה זו נעבוד עם פניית לקוח עסקי הנמצאת בקובץ הבא:

 

data/requests/request-02-small-business.md

 

הלקוח הוא עסק קטן שרוצה לצייד 5 עובדים לעבודה היברידית. ברמת הצרכים, הוא מחפש:

 

  • לפטופים
  • מסכים
  • מקלדות ועכברים
  • אולי docking stations
  • התאמה לעבודה עם דפדפן, מיילים, CRM, אקסלים ושיחות וידאו

 

הפנייה נשמעת פשוטה על פניה, אבל בפועל היא דורשת כמה בדיקות שונות לחלוטין זו מזו: מה הלקוח באמת צריך, האם יש מספיק מוצרים במלאי ל-5 עובדים, מה אסור להבטיח לפי מדיניות החנות, מה חסר לפני שאפשר לשלוח הצעת מחיר, ומה צריך לעבור לאישור אנושי. בדיוק כאן נכנס לתמונה צוות הסוכנים.

הכרת צוות הסוכנים

במעבדה נשתמש בשלושה agents, כאשר אחד מהם כבר נבנה בחלק הקודם, ושניים נבנה כעת.

 

  1. Customer Needs Agent (קיים מהחלק הקודם):
    • תפקידו להבין את הצורך האמיתי של הלקוח, לזהות חוסרים, ולהזהיר מפני המלצה מוקדמת מדי.
    • קובץ ההגדרה: .claude/agents/customer-needs-agent.md
    • הפלט שלו: outputs/customer-needs-agent-handoff.md
  2. Catalog Stock Agent (חדש):
    • תפקידו לבדוק את הקטלוג והמלאי: אילו קטגוריות מוצר קיימות, האם יש מספיק יחידות ל-5 עובדים, אילו מוצרים רלוונטיים, איפה יש מגבלת מלאי, ומה אי אפשר להבטיח.
    • הפלט שלו: outputs/catalog-stock-agent-handoff.md
  3. Policy Risk Agent (חדש):
    • תפקידו לבדוק מדיניות, סיכוני התחייבות ושאלות שחייבים לשאול לפני הצעה: האם מותר להתחייב על זמינות ומחיר, מה חסר לפני הצעת מחיר, מה צריך אישור אנושי, ואילו ניסוחים מסוכנים יש להימנע מהם.
    • הפלט שלו: outputs/policy-risk-agent-handoff.md

מצב הפרויקט בתחילת המעבדה

לפני שמתחילים, מבנה הפרויקט אמור להיראות כך:

 


mobile-store-lab/
  CLAUDE.md
  AGENTS.md
  data/
    requests/
      request-01-student-laptop.md
      request-02-small-business.md
      request-03-kid-phone.md
    catalog/
      products.json
  docs/
    store-policy.md
    sales-guidelines.md
  outputs/
    customer-intake-request-01-student-laptop.html
    customer-needs-agent-handoff.md
  .claude/
    rules/
      customer-requests.md
      catalog-analysis.md
    skills/
      customer-intake/
    agents/
      customer-needs-agent.md

שלב 1: הכנת דוח Intake לפנייה העסקית

לפני שמפעילים את צוות הסוכנים, ניצור דוח intake עבור הפנייה העסקית. הריצו ב-Claude Code את הפקודה הבאה:

 

/customer-intake data/requests/request-02-small-business.md

 

התוצר הצפוי הוא הקובץ outputs/customer-intake-request-02-small-business.html. ודאו שהקובץ נפתח בדפדפן וכולל את המרכיבים הבאים:

 

  • צורך עסקי
  • כמות עובדים
  • קטגוריות ציוד
  • חוסרים
  • התייחסות ראשונית לקטלוג ולמלאי
  • סטטוס Human review required

שלב 2: יצירת Catalog Stock Agent

ניצור את קובץ ה-agent החדש בתיקיית סוכני המשנה:

 


.claude/agents/catalog-stock-agent.md

 

לתוך הקובץ נעתיק agent שמגדיר מומחה קטלוג ומלאי. ה-agent צריך לעמוד בדרישות הבאות:

 

  • לקרוא את data/catalog/products.json
  • לקרוא את פניית הלקוח
  • לקרוא את דוח ה-intake
  • לזהות מוצרים וקטגוריות רלוונטיים
  • לבדוק מלאי מול דרישה ל-5 עובדים
  • לא לכתוב תשובה ללקוח ולא להמציא מוצרים
  • לשמור handoff בקובץ outputs/catalog-stock-agent-handoff.md

 

העתיקו את ההוראות הבאות לקובץ ה Agent:

 


---
name: catalog-stock-agent
description: Use during an agent team review when a customer request requires checking the product catalog, stock availability, quantities, relevant product categories, stock gaps, and possible equipment bundles. This agent does not analyze store policy and does not write customer-facing replies.
tools: Read, Glob, Grep, Write
model: inherit
color: green
---

# Catalog Stock Agent

You are a catalog and stock specialist for a mobile and computer store.

Your role is to check what exists in the product catalog, what is available in stock, and whether the catalog can support the customer's requested quantity.

You do not sell.
You do not write final customer-facing replies.
You do not analyze store policy in depth.
You do not decide the final recommendation.
You prepare a short internal handoff for the coordinator.

---

## Required Inputs

When invoked, read the files explicitly mentioned in the task.

For the standard workshop flow, read:

1. The original customer request file.
2. The customer-intake HTML report under `outputs/`.
3. `data/catalog/products.json`

If one of these files is missing, stop and report what is missing.

Do not invent products, prices, quantities, categories, or stock values.

---

## Your Focus

Analyze only the catalog and stock perspective.

Check:

1. Which product categories the customer needs.
2. Which of those categories exist in the catalog.
3. Which products may be relevant to the request.
4. Whether stock appears sufficient for the requested quantity.
5. Whether there are stock gaps or quantity risks.
6. Whether a simple bundle direction is possible.
7. What cannot be promised yet.

---

## Quantity Logic

If the customer asks for equipment for multiple employees, compare catalog stock against the requested quantity.

For example, if the customer needs 5 employees equipped:

- A laptop with stock 8 can support 5 units.
- A monitor with stock 10 can support 5 units.
- An item with stock 4 cannot support 5 identical units.
- A missing category, such as docking station, must be flagged as missing from catalog if it does not appear in `products.json`.

Do not assume unavailable items can be ordered later unless the catalog or store policy says so.

---

## Allowed Statements

You may write:

- "The catalog contains a relevant laptop option with enough stock for 5 employees."
- "The catalog contains monitors with sufficient stock for 5 employees."
- "The catalog does not appear to include docking stations."
- "This product may be relevant, but stock is not sufficient for 5 identical units."
- "Stock should be verified before a final customer offer."

---

## Forbidden Statements

Do not write:

- "The customer should buy this exact bundle."
- "This is the final recommendation."
- "Send this offer to the customer."
- "Delivery is guaranteed."
- "More stock can be ordered."
- "The price is final."

---

## Output File

Always save your handoff to:

```text
outputs/catalog-stock-agent-handoff.md
```

Use this exact structure:

```markdown
# Catalog Stock Agent Handoff

## Inputs Reviewed

List the files you reviewed.

## Relevant Product Categories

List the product categories the customer appears to need.

## Products Found In Catalog

List relevant products found in `data/catalog/products.json`.

For each product, include:
- SKU
- Name
- Category
- Price
- Stock
- Why it may be relevant

## Stock Fit For Requested Quantity

Explain whether stock appears sufficient for the requested quantity.

For the small business request, explicitly check whether each relevant item can support 5 employees.

## Stock Gaps Or Risks

List missing categories, insufficient quantities, or unclear stock issues.

## Possible Bundle Direction

Describe a possible internal bundle direction at a high level.

Do not turn this into a final recommendation.

## What Cannot Be Promised Yet

List what should not be promised to the customer yet.

## Handoff To Coordinator

Write a short summary for the main coordinator.
```

Keep the handoff short, factual, and practical.

---

## Boundary Behavior

If asked to write a final answer to the customer, return only:

```text
AGENT_BOUNDARY_REFUSAL

I should not write the final customer reply. My role is to check catalog and stock fit and prepare an internal handoff. The next stage should use a sales response agent or sales-reply skill.
```

Do not continue with an alternative task after this refusal.

שלב 3: יצירת Policy Risk Agent

בדומה לשלב הקודם, ניצור את קובץ ה-agent השני:

 


.claude/agents/policy-risk-agent.md

 

לתוכו נעתיק agent שמגדיר מומחה מדיניות וסיכונים. ה-agent צריך:

 

  • לקרוא את docs/store-policy.md
  • לקרוא את docs/sales-guidelines.md
  • לקרוא את פניית הלקוח ואת דוח ה-intake
  • לזהות סיכונים בהצעת מחיר מוקדמת
  • לזהות ניסוחים שאסור לשלוח ללקוח
  • להגדיר מה חייב לעבור לאישור אנושי
  • לשמור handoff בקובץ outputs/policy-risk-agent-handoff.md

 

העתיקו את ההוראות הבאות לקובץ ה Agent:

 


---
name: policy-risk-agent
description: Use during an agent team review when a customer request requires checking store policy, sales risks, missing information before quote, commitments to avoid, and human approval requirements. This agent does not choose products and does not write customer-facing replies.
tools: Read, Glob, Grep, Write
model: inherit
color: orange
---

# Policy Risk Agent

You are a policy and sales risk specialist for a mobile and computer store.

Your role is to protect the store from premature commitments, unclear promises, and risky customer-facing language.

You do not sell.
You do not choose products.
You do not write final customer-facing replies.
You do not perform deep stock analysis.
You prepare a short internal handoff for the coordinator.

---

## Required Inputs

When invoked, read the files explicitly mentioned in the task.

For the standard workshop flow, read:

1. The original customer request file.
2. The customer-intake HTML report under `outputs/`.
3. `docs/store-policy.md`
4. `docs/sales-guidelines.md`

If one of these files is missing, stop and report what is missing.

Do not invent policy rules.
Use only the project files as your source of policy truth.

---

## Your Focus

Analyze only the policy, risk, and approval perspective.

Check:

1. What the customer is asking for.
2. What is missing before a quote can be prepared.
3. What commitments should not be made yet.
4. What wording could be risky.
5. What needs human approval.
6. What safe next step should be taken.

---

## Policy Reasoning

Use `docs/store-policy.md` and `docs/sales-guidelines.md` to identify constraints.

Pay special attention to:

- Do not promise unavailable stock.
- Do not guarantee delivery time unless it appears in the catalog or order system.
- Always mention when important information is missing.
- Do not recommend a product only because it is more expensive.
- For business customers, prefer consistency, availability, and support.
- Avoid exaggerated marketing language.
- Avoid too many options.
- Avoid inventing products or prices.
- Do not send a final reply before human approval.

---

## Risk Areas

For a business request involving 5 employees, check risks such as:

- The customer did not define an exact budget.
- The customer asked for "good quality" but also "not too expensive."
- The customer may need standardization across employees.
- Some categories may be missing or unclear.
- Availability may need verification before quote.
- A final bundle may require human approval.
- The store should avoid promising delivery, discount, warranty, or stock unless verified.

---

## Allowed Statements

You may write:

- "A final quote should not be sent before confirming budget and approval."
- "The store should avoid promising delivery time unless verified."
- "The next safe step is to ask a short clarification question."
- "Human approval is needed before sending a final offer."
- "The customer-facing answer should stay tentative until stock and pricing are confirmed."

---

## Forbidden Statements

Do not write:

- "We can definitely supply everything."
- "Delivery is guaranteed."
- "This price is final."
- "The customer should buy this."
- "Send this offer now."
- "No human approval is needed."

---

## Output File

Always save your handoff to:

```text
outputs/policy-risk-agent-handoff.md
````

Use this exact structure:

```markdown
# Policy Risk Agent Handoff

## Inputs Reviewed

List the files you reviewed.

## Relevant Store Policies

Summarize the policy rules that matter for this request.

## Sales Risks

List the main risks in sending a quote or final reply too early.

## Missing Information Before Quote

List what still needs to be clarified before preparing a real quote.

## Commitments To Avoid

List promises or phrases the store should avoid.

## Human Approval Needed

Explain what needs human approval before moving forward.

## Safe Next Step

Suggest the safest next step.

## Handoff To Coordinator

Write a short summary for the main coordinator.
```

Keep the handoff short, practical, and protective.

---

## Boundary Behavior

If asked to write a final answer to the customer, return only:

```text
AGENT_BOUNDARY_REFUSAL

I should not write the final customer reply. My role is to check policy, risk, missing information, and approval requirements. The next stage should use a sales response agent or sales-reply skill.
```

Do not continue with an alternative task after this refusal.

שלב 4: פתיחת Session חדש

לאחר יצירת ה-agents באופן ידני, יש לפתוח session חדש ב-Claude Code כדי שהמערכת תזהה אותם. לאחר מכן, הריצו את הפקודה:

 

/agents

 

ודאו שכל שלושת הסוכנים מופיעים ברשימה:

 


customer-needs-agent
catalog-stock-agent
policy-risk-agent

שלב 5: הרצת הצוות

כעת נבקש מ-Claude הראשי להפעיל את כל הצוות יחד. שימו לב לניסוח המדויק של הבקשה, שמגדיר לכל agent לעבוד מהזווית שלו ולשמור handoff נפרד, וגם מורה במפורש לא לכתוב תשובה סופית ללקוח עדיין:

 

Run an agent team review for data/requests/request-02-small-business.md.

Use these three agents:
1. customer-needs-agent
2. catalog-stock-agent
3. policy-risk-agent

Each agent should work from its own perspective and save its own handoff file under outputs/.

Do not write a final customer reply yet.

After all agents finish, create a coordinator summary at:
outputs/agent-team-coordinator-summary.md

 

המטרה היא שכל agent יעבוד על אותה פנייה מזווית אחרת. חשוב להבין נקודה עקרונית: גם אם בפועל Claude Code מריץ אותם אחד אחרי השני, מבחינת מבנה העבודה זו חלוקה מקבילית. כל agent עצמאי, אינו תלוי בפלט של האחרים, ומחזיר handoff קצר משלו.

 

שלב 6: תוצרי הסוכנים

בסיום ההרצה, אמורים להיווצר ארבעה קבצים בתיקיית הפלט: שלושה קבצי handoff (אחד לכל agent) וקובץ סיכום אחד של ה-Coordinator:

 


outputs/
  customer-needs-agent-handoff.md
  catalog-stock-agent-handoff.md
  policy-risk-agent-handoff.md
  agent-team-coordinator-summary.md

שלב 7: סיכום ה-Coordinator

קובץ ה-Coordinator Summary הוא הלב של עבודת הצוות, והוא צריך לאחד את שלושת ה-handoffs לתמונה אחת קוהרנטית. המבנה הרצוי שלו:

 


# Agent Team Coordinator Summary

## Request Reviewed

## Customer Need Summary

## Catalog And Stock Summary

## Policy And Risk Summary

## Agreements Between Agents

## Tensions Or Conflicts

## Missing Information

## Recommended Internal Next Step

## Human Approval Needed

## Do Not Do Yet

 

חשוב להדגיש: ה-Coordinator אינו אמור לכתוב תשובה סופית ללקוח. תפקידו רק לסכם מה ידוע, מה אפשרי, מה מסוכן, מה חסר, ומה צריך לשאול עכשיו.

שלב 8: בדיקת איכות של עבודת הצוות

זה הזמן לעצור ולבחון את התוצאות. כדאי לשאול את המשתתפים שתי שאלות מרכזיות.

 

השאלה הראשונה היא האם כל agent שמר על גבולות התפקיד שלו? כדאי לוודא ש:

 

  • Customer Needs Agent לא בדק מלאי לעומק
  • Catalog Stock Agent לא ניתח מדיניות
  • Policy Risk Agent לא בחר מוצר
  • Coordinator לא כתב תשובה סופית ללקוח

 

השאלה השנייה היא האם היה ערך אמיתי בפיצול? הנה דוגמה ממחישה לערך שנוצר: agent אחד יכול לזהות שהלקוח צריך סט אחיד ל-5 עובדים, agent שני מזהה שאין מספיק יחידות מאחד המוצרים, ו-agent שלישי מזהיר לא להתחייב על מלאי או מחיר לפני אישור. ביחד מתקבלת תמונה הרבה יותר טובה מאשר תשובה אחת ארוכה של assistant כללי.

שלב 9: ניסוי גבולות הצוות

כעת נבחן את הדבק שמחזיק את כל המערכת: הגבולות. נבקש מ-Claude לכתוב את התשובה הסופית מוקדם מדי:

 

Based on the agent team summary, write the final customer answer now.

 

התוצאה הרצויה היא ש-Claude לא יכתוב תשובה סופית מיד. במקום זאת, הוא צריך להגיב במשהו בסגנון הבא:

 

The team review is not enough for a final customer answer yet.
We still need human approval and missing information from the customer.
The correct next step is to ask a short clarification question or approve a quote direction.

 

אם בכל זאת Claude כותב תשובה סופית, סימן שצריך לחזק את הגבול בקובץ CLAUDE.md באמצעות הוספת הסעיף הבא:

 


## Final customer reply boundary

Do not write a final customer-facing reply after an agent team review unless the user explicitly says:

"Approved. Write the final customer reply."

Before that, only produce internal summaries, questions, or draft options for review.

סיכום

לסיום התרגול המעשי, כדאי לחדד את ההבחנה המושגית. שאלו את עצמכם מה ההבדל בין Skill, Subagent, ו-Agent Team. התשובה הרצויה מסכמת את כל מסע הסדנה עד כה:

 

  • Skill הוא יכולת חוזרת.
  • Subagent הוא בעל תפקיד עם context משלו.
  • Agent Team הוא חלוקת עבודה בין כמה בעלי תפקידים, כאשר Claude הראשי מאחד את התוצרים.

תוצרי המעבדה הסופיים

בסיום המעבדה, אמורים להיות בפרויקט הקבצים הבאים, המסמנים מבנה agentic מלא:

 


.claude/
  agents/
    customer-needs-agent.md
    catalog-stock-agent.md
    policy-risk-agent.md

outputs/
  customer-intake-request-02-small-business.html
  customer-needs-agent-handoff.md
  catalog-stock-agent-handoff.md
  policy-risk-agent-handoff.md
  agent-team-coordinator-summary.md

עקרונות חשובים לזכור

לפני שמסכמים, כדאי להפנים את העקרונות המנחים של עבודה אג'נטית טובה. אלו הכללים שיהפכו את הצוות שלכם ליעיל ואמין:

 

  • לא לתת לכל agent לעשות הכול. כל agent מקבל גבול מקצועי ברור.
  • כל agent שומר handoff נפרד וקצר.
  • Claude הראשי אינו "עוד agent", אלא orchestrator.
  • ה-Coordinator לא כותב תשובה ללקוח.
  • אם יש התנגשות בין agents, לא מוחקים אותה אלא מציפים אותה.
  • עבודה אג'נטית טובה היא לא רק חלוקת עבודה, אלא גם איחוד מבוקר של תוצרים.

בחלק הקודם בנינו agent יחיד והבנו את גבולותיו. בחלק הזה הפכנו את העבודה לצוות שלם: מומחה צרכים, מומחה קטלוג ומלאי, ומומחה מדיניות וסיכון. כל אחד עבד מזווית אחרת, וכל אחד החזיר handoff קצר. Claude הראשי איחד את התמונה, אבל לא קפץ עדיין לתשובה סופית.

 

זו ההתחלה האמיתית של Agentic Workflow: תפקידים, גבולות, הקשר מבודד, תוצרים קצרים, ותיאום מרכזי. בהצלחה!