AI-agentruntime voor gecoördineerd werk | Dweve Nexus

Kies de doelgroep die bij je vraag past

De pagina bevat drie selecteerbare lezingen van hetzelfde onderwerp.

AI-codeagent en ondersteuning voor operators. Demostatistieken zijn illustratief.

Terminal, zoeken, linting, tests, Git en meer.

Gespecialiseerde agents werken samen over verschillende aandachtspunten.

Elke stap wordt met een tijdstempel vastgelegd.

Beleid, controles en tests worden altijd uitgevoerd.

Bekijk diffs, vraag wijzigingen aan en geef definitief akkoord.

Speel elke sessie bit voor bit opnieuw af als review nodig is.

Autonome agents die code schrijven en bewijs bijhouden

om netwerk timeouts, 5xx-responses en idempotent-safe condities af te handelen. Pure helper, volledig unit-getest.

Input, beleid, redenering in één artefact

gevormd rond één taak, en het laat zien wat het doet

intentie, scope, inhoud, ethiek, anomalie, runtime

doel obj-281 · team 5 specialisten · cyclus 1/1

De runtime voor uitvoerbare organisaties · één doel, één gevormd team, één spoor

beslissing uitvoeren · betaling aan leverancier v-281 vasthouden

actie · goedkeuringspoort · beslissing #4f9e2c

in wachtrij voor ops, wacht op goedkeurder

ondertekend · M. Bos, ops-3 · 2026-04-12 09:14 CET

vastleggen · beperkingsspoor verzegeld, van begin tot eind herhaalbaar

Werkgeheugen, episodisch geheugen, semantisch geheugen, procedureel geheugen en kennisbank

Een organisatie met verantwoordelijkheid ontstaat

Geef Nexus een doelstelling die nu nog mensen, systemen, regels en goedkeuringen doorkruist. Zie hoe het werk wordt opgedeeld, hoe de organisatie zich vormt, hoe bevoegdheid wordt toegewezen, hoe falen wordt ingeperkt en hoe elke bijdrage terugkeert naar één resultaat waarvoor iemand verantwoordelijk is.

Elke bijdrage keert terug naar de doelstelling

Pipeline, fan-out, delegatie, blackboard, debat

Dweve Nexus, de runtime voor uitvoerbare organisaties

Nexus is een Python-runtime voor multi-agentwerk dat meer structuur vraagt dan een promptlus. De implementatie scheidt agents, taaklevenscyclus, workflows, geheugen en capabilitygebaseerde routering in afzonderlijke componenten. Met Python-builders, DweveScript en een CLI definieer en draai je dat werk.

Python-runtime, afzonderlijke componenten

Capabilitymatching, expliciete vereisten

Gebruik de Python-builders, DweveScript of de CLI om agents, taken en workflows te definiëren voor het werk dat je wilt coördineren.

Componenten voor gecoördineerd agentwerk

Werkgeheugen, episodisch, semantisch, procedureel en kennis

Van deductief tot hybride, gekozen voor de taak

Dweve Nexus, elke taak krijgt zijn eigen team

De meeste AI-tools geven elke klus aan dezelfde assistent. Nexus werkt anders. Achter Fabric vormt het een team rond wat je vroeg, stuurt het elk onderdeel naar de specialist die daarbij past en levert het één resultaat terug in het gesprek dat je al had geopend. Jij vraagt één keer. Nexus organiseert alles daarachter.

Vraag het één keer. Laat Nexus het team samenstellen, het werk verdelen, de stukken samenbrengen en één resultaat teruggeven. De organisatie werkt voor jou. De bevoegdheid blijft bij jou.

Getypeerde overdrachten houden de runtime coherent. Wie voor het werk tekent, leest iets anders.

De huidige implementatie biedt Python-builders voor agents en een DweveScript-compiler voor declaratieve agent- en workflowdefinities. De CLI parseert, compileert en draait DweveScript-bestanden. Dit zijn aanvullende interfaces op dezelfde Python-implementatie en geen claim over gelijkwaardige clients in Rust, TypeScript of Go. Een definitie die in de een is geschreven is dezelfde definitie wanneer je haar uit de ander leest, zodat een team tussen het declaratieve bestand en de builder kan wisselen zonder twee beschrijvingen van dezelfde organisatie te onderhouden.

Naast point-to-point-berichten draait een getypeerde eventbus, waar een groep agenten daadwerkelijk op coördineert: taakverzoeken en -resultaten, acceptatie en afwijzing, claims en releases, en levenscyclus- en gezondheidsgebeurtenissen, met abonnees die kunnen filteren, doorsturen, weggooien en transformeren wat ze ontvangen. Twee soorten status worden bewust buiten individuele berichten gehouden. Een blackboard is een gedeclareerde structuur die agenten lezen en schrijven, zodat bijdragen buiten hun schrijver leesbaar zijn.

Gebeurtenissen, en de status die bedoeld is om te delen

Een overdracht in Nexus is een waarde met een vorm in plaats van een alinea waarvan een agent hoopt dat een ander die parseert. De protocol laag draagt A2A-compatibele types voor berichten, taken, artefacten, capaciteiten, vaardigheden, rollen en statussen, en JSON is één manier om die op een draad te zetten in plaats van het typesysteem zelf. Tools en externe systemen komen binnen via contract, en Model Context Protocol wordt ondersteund als een van die grenzen waar een klant het wil. Een ontvangende component kan die vorm valideren voordat hij handelt, en de trace houdt de overdracht controleerbaar. JSON is een transportkeuze; het vervangt het contract niet.

Replay beantwoordt wat er is gebeurd. Wat de onderdelen elkaar aangeven is strak getypt.

Nexus heeft aparte componenten voor routering, workflow-uitvoering, communicatie, redeneren, geheugen, veiligheid en herstel. Door die scheiding kun je het relevante onderdeel bekijken wanneer werk zich onverwacht gedraagt, in plaats van elke storing als een promptprobleem te behandelen. Elk onderdeel legt vast wat het besloot op het moment van beslissen, zodat de vraag na een incident is welk onderdeel veranderde en niet welke zin ongelukkig geformuleerd was. Die vastlegging is wat een replay teruglees.

Vastgelegde replay hergebruikt de opgenomen uitvoer van elke externe aanroep en reconstrueert de oorspronkelijke run, wat de eigen beslissingen van de runtime test terwijl de buitenwereld stilgehouden wordt. Live replay roept de afhankelijkheden opnieuw aan en vergelijkt, wat de test is die kan falen en daarom de moeite waard is om te draaien. De vergelijking is dus een test van de omgeving, geen tweede kopie van de geschiedenis.

Dat alles kan live bekeken worden. Wat de runtime voor zichzelf beslist is bepaald voordat het draait.

Gestructureerde events worden per entiteit uitgezonden, en de deployment bepaalt welke opslag ze ontvangt: begrensd geheugen op een ontwikkelomgeving, een persistente opslag in productie, en append-only of manipulatiebestendige opslag waar het record stand moet houden tegenover iemand buiten het gebouw. Elk daarvan wordt genoemd wat het is. De runtime noemt gewone veranderlijke logs niet onveranderlijk, wat het verschil is tussen bewijs dat iemand accepteert en een claim die ze testen.

De soorten entiteiten stellen verschillende vragen, en de asymmetrie is het nuttige deel. Een agent vragen hoe gezond hij is, is logisch, en een operatie hetzelfde vragen niet, omdat een operatie geblokkeerd is of niet en zijn gezondheid alleen de gezondheid is van wie erin zit. Een werkeenheid heeft een deadline en een aantal hertellingen, en een groep heeft geen van beide: wat een groep heeft is een lidmaatschap en een record van waar het aan gewerkt heeft. Omdat die sets verschillen, beantwoordt één platte stroom alle vier slecht.

Een productievraag is zelden wat een log zei. Het is welke werkeenheid zijn deadline miste, welke agent ongezond is, welk deel van de operatie geblokkeerd is en waarop. Nexus rapporteert status over dezelfde dingen die het uitvoert, dus de vraag gaat naar wie het antwoord bezit in plaats van samengesteld te worden uit regels die het toevallig vermelden. Daardoor kun je de vraag beantwoorden zonder een gesprek opnieuw af te spelen. De status hoort bij de entiteit die het werk bezit, zodat je een gemiste deadline, ongezonde agent of geblokkeerde operatie vanuit het verslag en de actuele toestand kunt onderzoeken.

Herstel is iets waarover je verteld wordt. Het zien draaien is een andere eis.

Twee gevolgen zijn direct bruikbaar voor engineers. De wachttijd wordt deterministisch berekend uit het pogingsnummer, niet getrokken uit een willekeurige bron. Daardoor maakt het schema van een mislukte run deel uit van de replay en krijgt de vraag hoe lang het gisteren duurde een antwoord in plaats van een theorie. Daarnaast hoort de circuitonderbreker bij de agent, niet bij het soort werk: één falende afhankelijkheid sluit één route af, terwijl hetzelfde werk elders routeerbaar blijft. Elke vervanging wordt meteen vastgelegd. De omleiding noemt de vervangende agent en de toestand die met de taak meeging, zodat een herstelde run achteraf als één stuk werk met intern herstel leesbaar blijft.

Er zal iets falen, en de interessante vraag is niet welke reactie gekozen wordt. Het is wat voorkomt dat het herstel de werkbelasting wordt. Elk deel ervan is begrensd voordat de problemen beginnen: hoeveel pogingen, hoe lang elke wachttijd is, hoeveel van de toelage een redding mag uitgeven, en hoeveel van het landgoed één slechte afhankelijkheid meeneemt. Niets eindigt hier omdat een lus besloot dat het hard genoeg had geprobeerd. De runtime registreert het pogingsnummer, de berekende wachttijd, de circuitstatus, de vervanger en de overgedragen toestand. Zo heeft een incidentreview een begrensd pad om te onderzoeken: een retry kan worden afgespeeld, een gesloten route kan worden verklaard en een definitieve fout kan worden onderscheiden van geslaagd herstel.