Forward-deployed זה לעבוד בתוך הריפו ובסטאק שלכם, לא מערוץ Slack חיצוני. אני כותב ושולח את הקוד שסוגר את הפער בין דמו עובד לבין מערכת שאפשר להשאיר רצה. רוב הזמן זה retrieval grounding, כיסוי evals, גבולות של כלים ומסלול rollback. מה שמתקבל בסוף - commits ו-runbooks, לא מצגות.
שווה כשמשימה חוצה כמה משטחי כלים, ארוכה מקונטקסט אחד של מודל או דורשת audit trail חתום לכל צעד. over-engineering כשסוכן יחיד מוקפד עם גבולות כלים נוקשים כבר מספיק. Bernstein בנוי לתרחיש הראשון. אם ה-workflow שלכם הוא פרומפט אחד וכלי אחד, אתם לא צריכים אורקסטרטור, אתם צריכים evals טובים יותר.
שאילתות דמו ידידותיות, תעבורת פרודקשן לא. ה-retriever מחזיר בשקט קונטקסט שנשמע סביר אבל שגוי, המודל כותב סביבו טקסט בטוח, ושום דבר בסטאק לא תופס את זה. מה שאני בדרך כלל מתקן: hybrid retrieval, תבנית תשובה עם ציטוטים ברמת עמוד, ו-eval set עם שאילתות עוינות שמקבע את המצבים שבאמת נופלים אצלכם, לא את אלה שהפריימוורק מדמיין.
כשהעומס נוגע במידע רגולטורי, ברשת סגורה או בשער LLM בצד הלקוח שאי אפשר לעקוף. Bernstein מחזיק state בקבצים, scheduling דטרמיניסטי וסקופ הרשאות לכל סוכן - הכל בתוך הפרימטר שלכם. אין קריאות יוצאות שלא אישרתם. אותו אורקסטרטור רץ על לפטופ, ב-CI וב-VM מוקשח - וזה מה ש-compliance בדרך כלל רוצה לראות.
כל שינוי נשלח עם gold set של קלטים, judge דטרמיניסטי ו-gate fail-closed ב-CI. מצבי כשל חדשים נתפסים כ-eval cases לפני שהתיקון נכנס, כך שהרגרסיה לא חוזרת בשקט. האורקסטרטור מתעד כל צעד של הסוכן, וכשמטריקה זזה אפשר לשחזר את הריצה המדויקת שהזיזה אותה. בלי releases לפי תחושה.
