כשמערכת Agent לא מספקת תוצאה טובה, התגובה האינסטינקטיבית היא לשדרג מודל: לעבור לגרסה חדשה יותר, להגדיל context window, או לבחור provider אחר. אבל זו לא תמיד הבעיה האמיתית.
בפועל, הרבה כשלים של Agents לא נובעים מהמודל אלא מהמערכת שמסביבו. Workflow לא ברור, tool calling לא אמין, קלט לא מספיק מובנה, או lack of verification — כל אלה משפיעים לפעמים יותר מהמודל עצמו. במילים אחרות, agent לא נכשל רק כי "הוא לא חכם מספיק", אלא כי המסגרת שבה הוא פועל לא תוכננה נכון.
זה נכון במיוחד במערכות אוטונומיות למחצה: סוכנים שמחפשים מידע, כותבים טיוטות, מפעילים כלים, ומקבלים החלטות על בסיס כמה שלבים. ככל שיש יותר שלבים, כך גדל הסיכוי שהבעיה היא orchestration ולא reasoning.
מתי כן להחליף מודל? כשברור שיש מגבלה בסיסית בהבנה, איכות ניסוח, או דיוק. מתי לעצור לפני זה? כשאין logging טוב, אין בקרת איכות, ואין חלוקה מסודרת לשלבים. במצב כזה, החלפת מודל פשוט תסתיר בעיה ארכיטקטונית.
המסקנה הפרקטית היא פשוטה: לפני שאתם משדרגים model, תבדקו אם בכלל תכננתם נכון את ה-agent. בהרבה פרויקטים, workflow טוב יותר שווה יותר ממודל חזק יותר.