MAPL: Model Action Programming Language

מודלי שפה גדולים המצוידים ביכולת קריאה לכלים חיצוניים פועלים כיום בלולאה סדרתית: המודל פולט קריאת כלי אחת, ממתין לתוצאה, מקבל את כל ההקשר מחדש, מחליט על הפעולה הבאה, וחוזר חלילה. ארכיטקטורה זו יוצרת עלות מיותרת של round-trips שחוזרים למודל, כפילות טוקני הקשר, וזמן תגובה מצטבר גבוה גם כאשר לוגיקת ההסתעפות בין הכלים פשוטה ודטרמיניסטית. עבודות קודמות כגון LLMCompiler (Kim et al., 2024) התמקדו בהקבלת קריאות כלים עצמאיות אך לא הציעו מנגנון שבו המודל מבטא תנאים, יציאות מוקדמות, והסתעפויות ישירות בפלט שלו, כך שהרצה דטרמיניסטית תבצע אותן ללא קריאות נוספות למודל. גישות חדשות יותר כמו Programmatic Tool Calling של Anthropic (2025) מאפשרות למודל לכתוב קוד Python שמתזמר כלים אך מסתמכות על שפת תכנות כללית (Turing-complete) שדורשת sandbox אינה מבטיחה סיום ומהווה שכבה חיצונית למודל ולא חלק מהפורמט הפנימי שלו.

מימוש הדגמה של MAPL זמין לעיון וניסוי כאן

במאמר זה אני מציע את MAPL (Model Action Programming Language) שפת תחום (DSL) קומפקטית ומוגבלת בכוונה (non-Turing-complete) שמקודדת ישירות כspecial tokens בפורמט הפנימי של מודלי שפה באותו רובד שבו מקודדים היום <|tool_call|>, <|eom_id|>, ו<|python_tag|>. המודל פולט תוכנית MAPL שלמה כחלק מהפלט שלו וסביבת הרצה דטרמיניסטית מבצעת אותה. MAPL מאפשרת למודל לתאר בקריאה אחת תוכנית מלאה הכוללת קריאות כלים סדרתיות ומקביליות, תנאים על תוצאות ביניים, יציאות מוקדמות שקטות, וסוגי קריאות שונים (חוסמות או שגר-ושכח). אני מנתח תיאורטית את החיסכון בקריאות מודל, בטוקנים, ובזמן תגובה, ונראה שבתרחישים טיפוסיים של 2-5 כלים עם הסתעפויות, MAPL מפחיתה 20%-50% מקריאות לכלים ומזמן התגובה, תוך שהיתרון המשמעותי ביותר מתקבל בתהליכי אוטומציה שמסתיימים לעיתים קרובות ביציאה מוקדמת ללא תגובה.

1. מבוא

1.1 הרקע: tool calling כפרדיגמה מרכזית

היכולת של מודלי שפה גדולים לקרוא לכלים חיצוניים - ממשקי API, מסדי נתונים, מנועי חיפוש ושירותים נוספים - הפכה לאחד הנדבכים המרכזיים בפריסת סוכני AI במערכות ייצור. מאז הצגת function calling בGPT-4 (OpenAI, 2023) והרחבתו למודלים פתוחים כמו Llama 3.1 (Dubey et al., 2024) וMistral (Jiang et al., 2024), ספקי מודלים מובילים כגון OpenAI, Anthropic, Google, Mistral, וMeta הטמיעו תמיכה בtool calling ישירות בתוך המודלים שלהם, באמצעות אימון ייעודי על פורמטים מובנים.

מבחינה טכנית tool calling מיושם באמצעות special tokens - טוקנים מיוחדים שאינם חלק מהשפה הטבעית אלא משמשים כהוראות מבניות למודל ולסביבת ההרצה. למשל Llama 3 משתמשת ב<|python_tag|> לסימון תחילת קריאת כלי ו<|eom_id|> לסימון שהמודל מצפה לתוצאה לפני שימשיך, בעוד <|eot_id|> מסמן סוף תור מלא. Mistral מגדירה control tokens ייעודיים כגון [TOOL_CALLS], BEGIN_TOOL_RESULTS וEND_TOOL_RESULTS. פורמט Hermes (NousResearch) משתמש ב<tool_call> ו</tool_call>. פורמט ChatML של OpenAI משתמש ב<|im_start|> ו<|im_end|> לתיחום תפקידים בשיחה.

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

1.2 הבעיה: round-trips מיותרים

הארכיטקטורה הרווחת כיום לשימוש בכלים מבוססת על הפרדיגמה שהציגו Yao et al. (2023) בעבודתם על ReAct: המודל חושב, מחליט על פעולה, מבצע אותה, מקבל תצפית, חושב שוב, וחוזר חלילה עד שמגיע לתשובה סופית. פרדיגמה זו אינטואיטיבית וגמישה אך היא מטילה מבנה ביצוע סדרתי קשיח: כל צעד דורש round-trip מלא למודל שבו כל ההקשר - הוראות המערכת, הגדרות הכלים, הודעת המשתמש, היסטוריית השיחה, ותוצאות כלים קודמות - נשלחים מחדש. בתהליך שכולל N קריאות כלים הדבר מצריך בדרך כלל N+1 קריאות למודל, כאשר עלות הטוקנים גדלה ליניארית עם כל צעד.

הבעיה מתחדדת כשבוחנים את אופי ההחלטות שהמודל מקבל בין קריאות כלים. ברוב הworkflows ההחלטות הללו הן דטרמיניסטיות ולא סמנטיות: "אם אין תוצאות חיפוש - עצור", "אם יש תוצאות - העבר לכלי הבא", "אם הסטטוס הוא X - קרא לכלי Y". אין צורך במודל שפה כדי לבדוק אם רשימה ריקה - זו בדיקה שקוד פשוט יכול לבצע. המודל כבר “יודע” מראש מה הלוגיקה, אבל הפרוטוקול הקיים מאלץ אותו לגלות אותה צעד אחרי צעד.

בנוסף לכפילות ההקשר ושיקול הדעת המיותר, קיימת בעיית זמן תגובה מצטבר. כל קריאה למודל דורשת 1-3 שניות וכל כלי דורש 0.5-2 שניות. תהליך סדרתי של ארבע קריאות מודל ושלושה כלים יכול לקחת 8-15 שניות, גם כאשר הלוגיקה פשוטה.

1.3 מגבלות הגישות הקיימות

עבודות מאוחרות יותר זיהו את חוסר היעילות הזה. LLMCompiler (Kim et al., 2024) הציע ארכיטקטורה בהשראת מהדרים קלאסיים: המודל מייצר גרף תלויות (DAG) של משימות ויחידת ביצוע מריצה משימות עצמאיות במקביל. גישה זו הצליחה להפחית באופן משמעותי את זמן התגובה (עד 3.7x) ואת העלות (עד 6.7x) ביחס לReAct. אולם LLMCompiler לא תומך בתנאים (if/else) על תוצאות כלים ולא ביציאות מוקדמות (early exit); כאשר נדרשת הסתעפות המודל חוזר ל"מצב תכנון מחדש" (replanning) שהוא בפועל round-trip נוסף.

ReWOO (Xu et al., 2023) הפריד בין שלב התכנון לשלב הביצוע: המודל מייצר תוכנית מלאה מראש, וWorkers מבצעים את הכלים. אך גם כאן אין תנאים - התוכנית היא רצף קבוע. גישת Plan-and-Solve (Wang et al., 2023) מפרידה בין שלב תכנון לשלב ביצוע אך התוכנית היא רשימת צעדים ליניארית ללא branching.

CodeAct (Wang et al., 2024) הציע שהמודל יפלוט קוד Python אמיתי שמבצע קריאות כלים. זה מאפשר תנאים ולולאות, אך דורש sandbox מלא של Python, מעלה סיכוני אבטחה, ומקשה על validation סטטי של התוכנית.

Programmatic Tool Calling (PTC) של Anthropic (2025) הולך צעד נוסף ומאפשר למודל Claude לכתוב קוד Python שמתזמר קריאות כלים בסביבת sandbox. תוצאות ביניים נשארות בסביבת ההרצה ולא נכנסות לcontext של המודל. הגישה הזו הוכיחה חיסכון של 37% בטוקנים במשימות מחקר מורכבות, ושיפור דיוק בbenchmarks פנימיים. אולם PTC מסתמכת על Python - שפה שלמה מבחינת Turing - שדורשת code execution sandbox, אינה מבטיחה סיום, ומהווה שכבה חיצונית (API-level feature) ולא חלק מהפורמט הפנימי של המודל. (Fun Fact כבר חשבתי על זה בעבר)

PASTE (Sui et al., 2026) הציע ביצוע כלים ספקולטיבי על בסיס דפוסי זרימה חוזרים. FlowMind (Liu et al., 2026) הציע מסגרת Execute-Summarize שבה המודל מבצע קודם ואז מחלץ workflow מובנה. OrchDAG (Lu et al., 2025) מודל tool execution כDAG עם מורכבות נשלטת, ומשתמש בRLVR לאימון. Quasar (Mell et al., 2025) מציע שפת תכנות חדשה לפעולות קוד של מודלים, עם הקבלה אוטומטית, כימות אי-ודאות, ותכונות אבטחה - אך זו עדיין שפת תכנות חיצונית שהמודל כותב כטקסט. Semantic Router DSL (Chen et al., 2026) מציע שפת מדיניות דקלרטיבית לניתוב inference ותזמור סוכנים, אך ממוקד במדיניות ניתוב - איזה מודל לבחור, האם לאשר קריאת כלי -ולא בתזמור הכלים עצמם.

כל הגישות הקיימות חולקות הנחה משותפת: שהתזמור קורה מחוץ לפורמט הפנימי של המודל כשכבה חיצונית (Python, DSL חיצוני, framework). החלל שנשאר פתוח הוא ברור: אין מנגנון קיים שבו המודל מבטא לוגיקה מותנית ישירות בפורמט הטוקנים שלו, כחלק טבעי מהפלט, כך שתבוצע דטרמיניסטית ללא שום round-trip.

1.4 מטאפורת המתכנת

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

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

2. שפת MAPL

2.1 עקרונות תכנון

MAPL מתוכננת לפי ארבעה עקרונות מנחים.

הראשון הוא הטמעה ברמת הטוקנים. MAPL מקודד כspecial tokens באותו רובד שבו מקודדים היום tool calls. הוא לא טקסט שהמודל כותב אלה חלק מהvocabulary של המודל. זו ההבחנה המהותית ביותר מגישות כמו CodeAct, PTC, וQuasar שבהן המודל כותב קוד כטקסט רגיל.

השני הוא מוגבלות מכוונת. MAPL הוא non-Turing-complete אין בו לולאות, רקורסיה, או מצב משתנה. יש רק תנאים, רצפים, וביצוע מקבילי. מגבלה זו מבטיחה שכל תוכנית MAPL מסתיימת, ושruntime דטרמיניסטי יכול לבצע אותה ללא סיכון ללולאות אינסופיות ובלי צורך בsandbox.

השלישי הוא מינימליזם. MAPL מוסיף מספר קטן של primitives מעל tool calling קיים. כל מה שאפשר לבטא בtool call רגיל אפשר לבטא בMAPL. MAPL מוסיף רק את היכולת לשרשר, להתנות, ולבצע במקביל. אין משתנים כלליים, אין פונקציות מוגדרות-משתמש. אלו ירחיבו את מרחב השגיאות של המודל ללא תועלת מספקת.

הרביעי הוא הדרגתיות. מודל יכול לפלוט tool call רגיל (ללא MAPL) למשימות פשוטות, ותוכנית MAPL רק כאשר יש ערך ללוגיקה מותנית. המערכת לא מכריחה DSL על כל אינטראקציה. ההבחנה מתבצעת על ידי הspecial token הראשון שהמודל פולט: <|tool_call|> לקריאה רגילה, <|program_start|> לתוכנית MAPL.

2.2 פרימיטיבים

MAPL מגדירה חמישה פרימיטיבים בסיסיים.

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

fire - קריאת כלי לא-חוסמת (שגר-ושכח). הruntime שולח את הקריאה אך ממשיך מיד לצעד הבא, ללא המתנה לתוצאה ובלי לאחסן אותה בstate. שימושי לפעולות צדדיות כמו רישום לlog, שליחת התראה, או עדכון מצב.

if - תנאי על תוצאת כלי קודם. התנאי מבוטא על שדות של תוצאת הכלי באמצעות אופרטורים פשוטים: השוואה מספרית ומחרוזתית, בדיקת קיום שדה, בדיקת ערך null/empty, ואופרטורים לוגיים (and, or, not). התנאי מכתיב איזה ענף (branch) יבוצע - כל if מכיל ענף then ואופציונלית ענף else.

parallel - ביצוע מקבילי של מספר קריאות כלים עצמאיות. הruntime מריץ את כולן בו-זמנית ואוסף את התוצאות לפני שממשיך.

finish - סיום התוכנית. יכול להיות מסוג respond (יש לחזור למודל לניסוח תשובה סופית, כאשר ה-runtime מעביר למודל את הstate המצטבר) או מסוג silent (סיום ללא תגובה כלל - הruntime לא חוזר למודל ולא פולט תשובה למשתמש).

2.3 Special Tokens

MAPL מגדיר את הspecial tokens הבאים:

<|program_start|>  - תחילת תוכנית MAPL
<|program_end|>    - סוף תוכנית MAPL
<|call|>           - קריאת כלי חוסמת
<|fire|>           - קריאת כלי לא-חוסמת
<|if|>             - תחילת תנאי
<|else|>           - ענף else
<|endif|>          - סוף תנאי
<|parallel|>       - תחילת בלוק מקבילי
<|end_parallel|>   - סוף בלוק מקבילי
<|finish|>         - סיום (עם פרמטר silent או respond)

2.4 דוגמאות מלאות

דוגמה 1: בדיקת מיילים חדשים

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

בtool calling רגיל התהליך דורש 3-4 round-trips:

<|start_header_id|>assistant<|end_header_id|>

<|python_tag|>{"name": "gmail.search", "parameters": {"query": "is:unread newer_than:1d"}}<|eom_id|>

<|start_header_id|>ipython<|end_header_id|>

{"result_count": 3, "results": [{"id": "m1", ...}, {"id": "m2", ...}, {"id": "m3", ...}]}<|eot_id|>

<|start_header_id|>assistant<|end_header_id|>

<|python_tag|>{"name": "memory.deduplicate", "parameters": {"items": [...]}}<|eom_id|>

<|start_header_id|>ipython<|end_header_id|>

{"new_count": 2, "new_items": [{"id": "m1", ...}, {"id": "m3", ...}]}<|eot_id|>

<|start_header_id|>assistant<|end_header_id|>

הנה סיכום המיילים החדשים שלך:
1. ...<|eot_id|>

כל <|start_header_id|>assistant<|end_header_id|> הוא קריאה נפרדת למודל עם כל ההקשר מחדש.

בMAPL המודל פולט את הכל בקריאה אחת:

<|start_header_id|>assistant<|end_header_id|>

<|program_start|>
<|call|> id=search tool=gmail.search {"query": "is:unread newer_than:1d"}
<|if|> search.result_count == 0
  <|finish|> silent
<|else|>
  <|call|> id=dedupe tool=memory.deduplicate {"items": "{search.results}"}
  <|if|> dedupe.new_count == 0
    <|finish|> silent
  <|else|>
    <|finish|> respond {"new_emails": "{dedupe.new_items}"}
  <|endif|>
<|endif|>
<|program_end|><|eot_id|>

הruntime מקבל את התוכנית ומבצע אותה:

(1) מפרש את <|program_start|>...<|program_end|>

(2) מריץ gmail.search מקבל {result_count: 3, results: [...]}

(3) בודק search.result_count == 0 - false נכנס לelse

(4) מריץ memory.deduplicate מקבל {new_count: 2, new_items: [...]}

(5) בודק dedupe.new_count == 0 false נכנס לelse

(6) פוגש <|finish|> respond מחזיר למודל רק את {new_emails: [...]}.

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

בתרחיש שאין מיילים חדשים הruntime מבצע קריאה אחת לgmail.search, בודק שהתוצאה ריקה, פוגש <|finish|> silent ועוצר. המודל נקרא פעם אחת בלבד כדי לייצר את התוכנית.

2.5 Validation

לפני ביצוע תוכנית, הruntime מבצע בדיקות validation סטטיות:

(1) כל הפניה (ref) מכוונת לid שהוגדר קודם לכן בעץ הביצוע

(2) כל if מכיל לפחות ענף then

(3) כל כלי שנקרא קיים בסכמת הכלים הזמינים

(4) כל path בעץ מסתיים בfinish. תוכנית שלא עוברת validation לא מבוצעת ובמקום זאת מוחזרת למודל עם הודעת שגיאה לתיקון בדומה לאופן שבו מטפלים היום בtool call עם פרמטרים לא תקינים.

2.6 מה MAPL לא כולל

MAPL לא כולל לולאות (for\while) כי לולאות על תוצאות כלים דורשות runtime מורכב עם ניהול state, ומכניסות סיכון של ביצוע בלתי מוגבל. MAPL לא כולל משתנים או מצב משתנה - תוצאת כל כלי זמינה תחת הidentifier שהמודל הגדיר (למשל $search, $dedupe), אך אין namespace מקונן או scope. MAPL לא כולל קריאות כלים דינמיות - שם הכלי והפרמטרים חייבים להיות ידועים בזמן הפלט, לא מחושבים מתוצאות. וMAPL לא כולל ניסוח טקסט - כל תשובה שדורשת שפה טבעית חייבת לעבור דרך finish respond שמחזיר את השליטה למודל.

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

3. ניתוח החיסכון

הערכת החיסכון של MAPL לעומת tool calling סדרתי היא הערכה גסה בלבד ולא תוצאה של ניסוי אמפירי או מדידה בשטח. באופן עקרוני בפרדיגמת ReAct רגילה המודל נקרא שוב אחרי כמעט כל קריאת כלי ולכן תהליך עם כמה כלים יכול לדרוש מספר רב של קריאות מודל ולצבור שוב ושוב את אותו הקשר.

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

לכן בתרחישים שבהם יש כמה שלבים טכניים או הסתעפויות פשוטות ניתן להעריך שהחיסכון עשוי להיות משמעותי: בערך 40%-80% בטוקנים ובקריאות מודל בתהליכים מרובי-כלים ולעיתים אף יותר באוטומציות שמסתיימות לעיתים קרובות בsilent finish כמו ניטור חדשות, בדיקת מיילים או בדיקת מלאי.

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

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

4. אימון

4.1 אימון על MAPL

MAPL דורשת שמודלי שפה יאומנו לייצר תוכניות בשפה זו, בדומה לאופן שבו מודלים כיום מאומנים לייצר tool calls בפורמט JSON.

תהליך האימון מרחיב את הפרדיגמה הקיימת: מוסיפים את הטוקנים המיוחדים של MAPL (<|program_start|>, <|program_end|>, <|call|>, <|fire|>, <|if|>, <|else|>, <|endif|>, <|parallel|>, <|end_parallel|>, <|finish|>) לvocabulary, מייצרים דוגמאות אימון של תוכניות MAPL נכונות עבור workflows שונים, ומאמנים את המודל לייצר אותן.

המודל לומד גם מתי להשתמש בMAPL ומתי בtool call רגיל. ההבחנה מתבצעת לפי הspecial token הראשון שנפלט.

4.2 המלצה: מודלים גדולים בלבד

בשל המורכבות היחסית של ייצור תוכניות MAPL נכונות (בהשוואה לtool call בודד) אני ממליץ להפעיל את יכולת MAPL רק במודלים גדולים בסדר גודל של 70B פרמטרים ומעלה. מודלים קטנים יותר עלולים לייצר תוכניות שגויות בשיעור גבוה מדי, מה שישלול את היתרון. ניתן לשקול מודלים קטנים יותר (8B-30B) רק אם הם עוברים fine-tuning ייעודי על MAPL עם dataset מספיק גדול ומגוון.

מקורות

Anthropic. (2024). Introducing the Model Context Protocol. https://www.anthropic.com/news/model-context-protocol

Anthropic. (2025). Introducing advanced tool use on the Claude Developer Platform. https://www.anthropic.com/engineering/advanced-tool-use

Chen, H., et al. (2026). From Inference Routing to Agent Orchestration: The Semantic Router DSL. arXiv:2603.27299.

Cheng, J., Liu, X., Zhang, Z., Wen, H., Zhang, Z., Yin, Q., Li, S., Nigam, P., Yin, B., Zhang, C., & Song, Y. (2026). Training LLMs for Multi-Step Tool Orchestration with Constrained Data Synthesis and Graduated Rewards. arXiv:2603.24709.

Dubey, A., et al. (2024). The Llama 3 Herd of Models. arXiv:2407.21783.

Jiang, A. Q., et al. (2024). Mistral 7B. arXiv:2310.06825.

Kim, S., Moon, S., Tabrizi, R., Lee, N., Mahoney, M. W., Keutzer, K., & Gholami, A. (2024). An LLM Compiler for Parallel Function Calling. In Proceedings of the 41st International Conference on Machine Learning (ICML), PMLR 235.

Liu, Y., et al. (2026). FlowMind: Execute-Summarize for Structured Workflow Generation from LLM Reasoning Traces. arXiv:2602.11782.

Lu, Y., Liu, S., & Dong, L. (2025). OrchDAG: Complex Tool Orchestration in Multi-Turn Interactions with Plan DAGs. arXiv:2510.24663.

Mell, S., et al. (2025). A Fast, Reliable, and Secure Programming Language for LLM Agents with Code Actions. arXiv:2506.12202.

Sui, Y., et al. (2026). Accelerating LLM Agents via Pattern-Aware Speculative Tool Execution (PASTE). arXiv:2603.18897.

Wang, L., Xu, W., Lan, Y., Hu, Z., Lan, Y., Lee, R. K.-W., & Lim, E.-P. (2023). Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models. In Proceedings of ACL 2023.

Wang, X., Wang, Y., Liu, J., Chen, Y., Yuan, L., Peng, H., & Ji, H. (2024). Executable Code Actions Elicit Better LLM Agents. ICML 2024. arXiv:2402.01030.

Xu, B., Peng, Z., Lei, B., Mukherjee, S., Liu, Y., & Xu, D. (2023). ReWOO: Decoupling Reasoning from Observations for Efficient Augmented Language Models. arXiv:2305.18323.

Yao, S., Zhao, J., Yu, D., Du, N., Shafran, I., Narasimhan, K., & Cao, Y. (2023). ReAct: Synergizing Reasoning and Acting in Language Models. ICLR 2023.