Programmatic tool calling: Factory Droid 1.0 Script mode

Tvůj coding agent má za úkol přesunout 151 issues v Linearu do backlogu a u každého ověřit, že se změnil jen stav. Klasický agent na to potřebuje stovky samostatných volání nástrojů a po každém z nich znovu čte celou dosavadní konverzaci. Factory ve svém agentovi Droid 1.0 zvolilo jinou cestu: model napíše krátký skript a ten udělá všechna volání najednou. Tomuhle principu se říká programmatic tool calling a od 29. října 2026 je v Droidu výchozím režimem.

V článku si ukážeme, jak to funguje, co Factory sama naměřilo, kde jsou slabiny a jak z toho vytěžit něco i ve svém vlastním workflow.

01Co je programmatic tool calling

Běžný agent pracuje v cyklu: model požádá o jeden nástroj (nebo několik), harness ho spustí, výsledek vrátí modelu, model rozhodne o dalším kroku. Každé kolo je jeden požadavek na model, který zaplatíš za všechny vstupní tokeny včetně historie.

Programmatic tool calling cyklus obrací. Model místo jednotlivých volání napíše program a ten běží v izolovaném prostředí. Program volá nástroje, zpracovává výsledky, filtruje je a nakonec vypíše jen to důležité. Zpátky k modelu se dostane jen vytištěný výstup.

Hlavní rozdíl v klasickém režimu projde každý mezivýsledek kontextem modelu. Ve skriptovém režimu se mezivýsledky zpracují mimo model.

02Jak to dělá Droid 1.0

Factory tuhle funkci implementovalo jako jediný nástroj s názvem Script. Podle jejich článku Droid 1.0: Building a Frontier Harness funguje takto:

• Model píše JavaScript, který běží v sandboxu. Sandbox nemá vlastní přístup k souborům, síti ani systému, může jen volat nástroje, které mu harness zpřístupní.
• Jeden skript zvládne stovky volání nástrojů v rámci jednoho požadavku na model.
• Nezávislá volání běží souběžně.
• Do kontextu se vrací jen vytištěný výstup, jehož velikost je omezená (přesný limit Factory neuvádí). Úplné výsledky se ukládají do logu, takže v nich model může později hledat.
• Skript čeká nejvýše 5 minut. Pak vrátí, co do té doby vypsal, nebo se dá spustit na pozadí. Na kontrolu, čekání a zastavení běžících programů je zvláštní nástroj a po dokončení práce na pozadí Droid model znovu probudí.
• Úpravy souborů uvnitř skriptu vracejí stejné krátké shrnutí jako přímé úpravy.

Důležitý detail: skript nemá žádná práva navíc. Neobejde oprávnění, která Droid má i bez něj. Jak přesně funguje schvalování akcí uvnitř skriptu, Factory v tomto článku nepopisuje, proto si to před nasazením na citlivé repozitáře ověř v dokumentaci.

03Které modely to mají zapnuté

Script mode je podle Factory zapnutý ve výchozím stavu pro modely GPT-6.1 Sol, GPT-6.1 Terra, GPT-6 Astra, GPT-6 Sol, GPT-5.6 Sol, Claude Fable 5.1, Claude Fable 5, Claude Opus 5.5, Claude Opus 5 a Kimi K3. Návod, jak ho vypnout, na stránce není. Factory navíc uvádí, že prompty, popisy nástrojů i režim volání ladí pro každý podporovaný model zvlášť.

04Co Factory naměřilo

Všechna čísla níže pocházejí od samotné Factory. Nezávislé ověření zatím nemáme a absolutní ceny za jednotlivé běhy nejsou zveřejněné.

Úklid Linearu: 151 issues

Úkol: přesunout 151 schválených issues do backlogu a ověřit, že se u každého změnil jen stav.

Při pesimističtějším odhadu 3 volání na požadavek by přímý režim potřeboval dokonce zhruba 107 požadavků. Práce je tedy stejná, ale model do ní zasahuje mnohem méně.

Kontrola CI: 5 384 jobů

Droid prošel 5 384 jobů ve 547 během pomocí 550 volání nástrojů a vystačil si se 2 požadavky na model. Přímý režim by odhadem potřeboval 59 až 187 požadavků. Model viděl jen pětičíselné shrnutí (včetně 41 neúspěšných jobů) a do jeho kontextu se dostalo méně než 0,1 % výsledků z nástrojů.

Úspora nákladů a benchmark

Na Claude Opus 5.5 podle Factory Script mode snižuje náklady Droida o 15 % oproti přímému volání nástrojů. Na Terminal-Bench 4 (tři běhy na úlohu, 23.–28. října 2026) uvádí Factory pro Opus 5.5 s vysokým reasoningem tyto výsledky:

U GPT-6.1 Sol má Droid 57,6 % (0,79 $ za úlohu) proti 54,0 % u Codexu. Rozdíly jsou tedy několik procentních bodů a jde o benchmark, který spustil výrobce sám, takže s ním zacházej opatrně.

Menší změny zlepšují i každodenní pocit z práce: základní prompt se zmenšil o 37 % (z 20 887 na 13 055 vstupních tokenů), definic nástrojů je předem jen 2 místo 11 a medián času do prvního vykreslení klesl z 1 839 ms na 488 ms.

05Kdy skriptový režim pomáhá a kdy ne

Princip se vyplatí tam, kde je hodně předvídatelných, opakovaných operací nad velkým množstvím položek.

Hodí se na:

• hromadné úpravy v issue trackeru (štítky, stavy, přiřazení),
• procházení logů nebo CI běhů a sestavení souhrnu,
• migrace nebo přejmenování napříč mnoha soubory,
• kontroly typu „projdi všechny repozitáře a vypiš ty, kde chybí X".

Nehodí se na:

• otevřený průzkum neznámého kódu, kde další krok závisí na tom, co model právě viděl. Autor rozboru na DEV Community upozorňuje, že tu je nutný návrat k přímým voláním,
• práci s nástroji, které nemají všechna potřebná data. Skript dokáže jen to, co mu povolené nástroje umožní.

06Slabá místa, na která si dej pozor

Zmíněný rozbor shrnuje několik reálných rizik, a platí pro každý podobný systém, nejen pro Droida:

1. Jeden pomalý nástroj zdrží celou dávku. Souběžnost pomáhá, ale čeká se na nejpomalejší volání.
2. Příliš dlouhý výstup může přetéct kontext v dalším kole. Omezení velikosti výpisu je užitečné, ale nezbavuje tě povinnosti tisknout jen souhrn.
3. Ladění je těžší. Selhání celého skriptu se hledá hůř než selhání jednoho volání. Ukládej plné logy i přesný zdroj skriptu, abys ho mohl přehrát.
4. Neúplné souhrny. Pokud skript něco shrnuje, nech ho vracet i signál „potřebuju víc dat", ať model nevyvozuje závěry z oříznutého výpisu.

07Jak si to vyzkoušet ve svém workflow

Nemusíš čekat na vlastní nasazení Droida. Princip lze uplatnit i jinde:

1. Vyber úlohu s hromadnou operací

Typicky něco, co bys jinak dělal ručně 50krát. Začni na úloze, kterou umíš zkontrolovat (třeba stav v issue trackeru).

2. Nejdřív suchý běh

Požádej agenta, ať skript nejdřív jen vypíše, co by změnil, a nic nezapisuje. U hromadných změn je to nejlevnější pojistka.

3. Zkontroluj výstup a log

Neptej se jen „povedlo se?". Projdi souhrn, spočítej položky (151 vstupních znamená 151 výsledků) a několik položek namátkově ověř ručně.

4. Vlastní agenti

Pokud stavíš agenta sám, podobný princip nabízí i API Anthropicu pod stejným názvem. Podmínky a dostupnost si ověř v aktuální dokumentaci, protože se rychle mění. Obecné pravidlo zůstává: do kontextu modelu posílej souhrn, ne surová data.

08Příklad: jak by vypadal skript pro hromadný úklid

Zadání pro agenta může znít: „Najdi v Linearu všechny schválené issues, přesuň je do backlogu a u každé ověř, že se změnil jen stav." V klasickém režimu by agent vypsal seznam, pak by 151krát volal úpravu a 151krát načítal výsledek. Ve skriptovém režimu napíše jeden program, který:

1. načte seznam schválených issues,
2. pro každou paralelně zavolá nástroj na změnu stavu,
3. načte upravenou issue zpět a porovná ostatní pole s původním stavem,
4. vytiskne jen souhrn: kolik položek prošlo, kolik selhalo a které to byly.

Model tak uvidí třeba tři řádky místo stovek odpovědí. Pokud selže pět issues, v dalším kole se věnuje jen jim. Právě tohle je podle Factory zdroj úspory: model neplatí za čtení výsledků, které jsou v pořádku.

Pozor i tady platí, že za výsledek odpovídáš ty. Při hromadných změnách v ostrých systémech si nech nejdřív vypsat seznam dotčených položek a teprve potom povol zápis.

09Co si z toho odnést

Programmatic tool calling není kouzlo, ale posun v tom, kde se odehrává práce. Místo aby model u každého kroku čekal na odpověď nástroje a četl celou historii, napíše plán jako kód a dostane zpět jen výsledek. U hromadných úloh to znamená méně požadavků, méně tokenů a rychlejší dokončení.

Pro tebe z toho plyne praktické pravidlo: u úloh s desítkami či stovkami stejných kroků nech agenta psát skript, u průzkumu a úvah nech běžný režim. A čísla od Factory ber jako zajímavý signál, ne jako hotový důkaz, dokud je nepotvrdí nezávislé testy.

10Časté otázky