Binex is een gratis opensourceprogramma waarmee je een reeks AI-stappen op je eigen computer laat uitvoeren, bijvoorbeeld: stel een bestelling op, laat een mens die goedkeuren en verwerk dan de betaling. Het legt vast wat elke stap kreeg, opleverde en kostte, zodat een ontwikkelaar bij een fout eindresultaat kan zien welke stap het veroorzaakte. Eén ontwikkelaar begon eraan in maart 2026.
Wat doet Binex?
De README van maart 2026 (versie 0.6.5) noemt het een "open-source visual orchestrator for AI agent workflows" die "100% locally" draait. Je beschrijft een workflow als een gerichte acyclische graaf (DAG): stappen, nodes genoemd, met invoer, uitvoer en afhankelijkheden, en zonder lussen. Je schrijft die in YAML of bouwt hem in een drag-and-drop-editor in de browser (binex ui).
Een node is een van zes soorten: een LLM-agent, een lokaal script, invoer door een mens, goedkeuring door een mens, uitvoer naar een mens, of een agent op afstand die Binex bereikt via A2A, een protocol voor communicatie tussen agents. LLM-nodes kunnen via LiteLLM meer dan 40 aanbieders gebruiken, ook lokale modellen via Ollama. Onderdelen uit LangChain, CrewAI en AutoGen kunnen via plug-ins als node draaien. Elke run blijft op je eigen machine: een SQLite-database bewaart de runs, de uitvoeringsgegevens en de kosten, en de uitvoer van elke node wordt als JSON-bestand opgeslagen.
Zo is Binex een kleine tool voor AI-orkestratie met ingebouwde observability. De README sluit af met het doel erachter: "AI agents shouldn't be black boxes."
Hoe vind je de stap die fout ging?
Via de opdrachtregel:
binex run workflow.yamlvoert een workflow uit.binex debug <run_id> --node researchertoont de invoer en uitvoer van één node in een run.binex trace <run_id>toont de run als tijdlijn.binex diffvergelijkt twee runs, enbinex bisectzoekt de eerste node waar ze uiteenlopen.binex replayvoert een workflow opnieuw uit vanaf een gekozen stap, eventueel met een andere agent voor een node.binex cost showsplitst de kosten uit per node.
De webinterface toont dezelfde overzichten, en daar kun je het model of de prompt van één node wisselen en alleen die node opnieuw draaien.
Waar liggen de grenzen?
- Het is een project van één persoon. Op 23 september 2026 telde GitHub 650 commits van de maker, Alexli18, en één van iemand anders; de repository had 62 sterren en 11 forks. Versie 0.8.0 verscheen op 31 augustus 2026.
- Lokaal geldt voor de runtime en de gegevens. Een LLM-node stuurt zijn prompt nog steeds naar de aanbieder die je instelt; de README wijst naar Ollama voor runs die volledig lokaal blijven.
- De vertakkingen volgen vaste regels op de uitvoer van een node, terwijl wat een LLM-node schrijft per run kan verschillen. Runs vergelijken is waar
diffenbisectvoor zijn.
Voorbeeld
Het human-in-the-loop-voorbeeld uit de repository handelt een pizzabestelling af. Een scriptnode stelt de bestelling op, een goedkeuringsnode zet de run stil tot een mens goedkeurt of afwijst, en een when-voorwaarde bepaalt of de betaling of de annulering wordt uitgevoerd:
1 name: human-in-the-loop 2 nodes: 3 builder: 4 agent: "local://echo" 5 system_prompt: "Build pizza order" 6 inputs: {} 7 outputs: [order] 8 confirm_payment: 9 agent: "human://approve" 10 system_prompt: "Review and approve payment" 11 inputs: 12 order: "${builder.order}" 13 outputs: [decision] 14 depends_on: [builder] 15 pay: 16 agent: "local://echo" 17 system_prompt: "Process payment" 18 inputs: 19 order: "${builder.order}" 20 outputs: [receipt] 21 depends_on: [confirm_payment] 22 when: "${confirm_payment.decision} == approved" 23 cancel: 24 agent: "local://echo" 25 system_prompt: "Cancel order" 26 inputs: {} 27 outputs: [cancellation] 28 depends_on: [confirm_payment] 29 when: "${confirm_payment.decision} == rejected"
De goedkeuringsstap is een human-in-the-loop-controlepunt. De post Hoe bouw je betrouwbare multi-agentsystemen? zet Binex naast andere tools uit maart 2026.
