AI-agentruntime för samordnat arbete | Dweve Nexus

Choose the audience that matches your question

The page contains three selectable readings of the same subject.

Kodagent och operatörsassistans. Demomätvärdena är illustrativa.

Terminal, sökning, lint, test, git med mera.

Specialiserade agenter samarbetar över olika områden.

Varje steg registreras med tidsstämplar.

Policyer, kontroller och tester körs alltid.

Granska diffar, begär ändringar, slutgiltigt godkännande.

Spela upp valfri session bit för bit när något behöver granskas.

Autonoma agenter som skriver kod och lämnar kvitton

för att hantera nätverkstimeouts, 5xx-svar och idempotenta villkor. Ren hjälpfunktion, fullt enhetstestad.

Indata, policy, resonemang på en artefakt

formad kring en uppgift, och den visar sitt arbete

avsikt, omfattning, innehåll, etik, avvikelse, körning

objekt obj-281 · team 5 specialister · cykel 1/1

Körtiden för exekverbara organisationer · ett mål, ett format team, en spårning

kör beslut · håll betalning till leverantör v-281

agera · godkännandegrind · beslut #4f9e2c

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

konto · begränsningsspårning förseglad, uppspelbar från början till slut

Arbetsminne, episodiskt, semantiskt, procedurellt, kunskapsbas

Ge Nexus ett mål som idag korsar människor, system, regler och godkännanden. Se hur arbetet delas upp, hur organisationen formas, hur befogenhet tilldelas, hur fel begränsas och hur varje bidrag återförs till ett ansvarigt resultat.

Pipeline, fan-out, delegering, blackboard, debatt

Dweve Nexus, körningen för exekverbara organisationer

Nexus är en Python-körning för multiagenter som hanterar arbete som behöver mer struktur än en promptloop. Implementeringen separerar agenter, uppgiftslivscykel, arbetsflöden, minne och kapacitetsbaserad routing i distinkta komponenter. Python-byggare, DweveScript och ett CLI definierar och kör arbetet.

Använd Python-byggarna, DweveScript eller CLI för att definiera agenter, uppgifter och arbetsflöden för det arbete du behöver samordna.

Arbetsminne, episodiskt, semantiskt, procedur- och kunskapsminne

Deduktivt till hybrid, valt för uppgiften

Dweve Nexus, varje uppgift får sitt eget team

De flesta AI-verktyg ger varje jobb till samma assistent. Nexus fungerar annorlunda. Bakom Fabric bildar det ett team kring det du bad om, skickar varje del till specialisten som passar för den och returnerar ett resultat genom konversationen du redan öppnat. Du frågar en gång. Nexus organiserar allt bakom.

Fråga en gång. Låt Nexus bilda teamet, dela upp arbetet, föra samman delarna och returnera ett resultat. Organisationen arbetar för dig. Makten förblir hos dig.

Typade överlämningar håller runtime sammanhållen. Den som skriver under för arbetet läser något annat.

Den aktuella implementationen tillhandahåller Python-byggare för agenter och en DweveScript-kompilator för deklarativa agent- och arbetsflödesdefinitioner. Dess CLI tolkar, kompilerar och kör DweveScript-filer. Dessa är kompletterande gränssnitt till samma Python-implementation, snarare än anspråk på motsvarande Rust-, TypeScript- eller Go-klienter. En definition skriven i en av dem är samma definition när den läses från den andra, så ett team kan växla mellan den deklarativa filen och byggaren utan att underhålla två beskrivningar av samma organisation.

Vid sidan av punkt-till-punkt-meddelanden körs en typad eventbus, som är vad en grupp agenter faktiskt koordinerar kring: uppgiftsförfrågningar och resultat, acceptans och avvisande, anspråk och frigivningar, samt livscykel- och hälsa-händelser, med prenumeranter som kan filtrera, vidarebefordra, släppa och transformera det de tar emot. Två typer av tillstånd hålls medvetet utanför enskilda meddelanden. En blackboard är en deklarerad struktur som agenter läser och skriver, så ett bidrag är läsbart för något annat än den som skrev det.

Händelser och tillståndet som är tänkt att delas

En överlämning i Nexus är ett värde med en form snarare än ett stycke som en agent hoppas att en annan tolkar. Protokollskiktet bär A2A-kompatibla typer för meddelanden, uppgifter, artefakter, förmågor, färdigheter, roller och statusar, och JSON är ett sätt att lägga dessa på en tråd snarare än själva typsystemet. Verktyg och externa system anländer via kontrakt, och Model Context Protocol stöds som en av dessa gränser där en kund vill ha det. En mottagande komponent kan validera formen innan den agerar, och spåret håller överlämningen inspekterbar. JSON är ett transportval; det ersätter inte kontraktet.

Replay svarar på vad som hände. Det som delarna ger varandra är lika hårt typat.

Nexus har separata komponenter för routing, arbetsflödeskörning, kommunikation, resonemang, minne, säkerhet och återställning. Den separationen gör det möjligt att inspektera den relevanta komponenten när arbete beter sig oväntat, snarare än att behandla varje fel som ett promptproblem. Varje komponent registrerar vad den beslutade i det ögonblick den beslutade det, så frågan efter en incident är vilken komponent som ändrades snarare än vilken mening som var dåligt formulerad. Den registreringen är vad en replay läser tillbaka.

Captured replay återanvänder de inspelade utdata från varje externt anrop och rekonstruerar den ursprungliga körningen, vilket testar runtime-egna beslut med omvärlden stillastående. Live replay anropar beroendena igen och jämför, vilket är testet som kan misslyckas och därför det som är värt att köra. Captured replay svarar på om runtime fattade samma beslut med omvärlden stillastående. Live replay svarar på om dagens beroenden fortfarande producerar samma resultat. Jämförelsen är därför ett test av miljön, inte en andra kopia av historien.

Allt detta kan ses live. Det som runtime beslutar för sig själv är fastställt innan det körs.

Strukturerade händelser emitteras per entitet, och driftsättningen bestämmer vilken butik som tar emot dem: begränsat minne på en utvecklingsmiljö, en beständig butik i produktion, och append-only eller manipulationssäker lagring där registret måste stå emot någon utanför byggnaden. Var och en av dessa kallas vad den är. Runtime kallar inte vanliga muterbara loggar för oföränderliga, vilket är skillnaden mellan bevis någon accepterar och ett påstående de testar. Händelser behåller sin entitet och lagringshållning.

De olika typerna av entiteter tar emot olika frågor, och asymmetrin är det användbara. Att fråga en agent hur frisk den är är meningsfullt, men att fråga en operation samma sak är inte det, eftersom en operation antingen är blockerad eller inte, och dess hälsa är bara hälsan hos den som befinner sig i den. En arbetsenhet har en deadline och ett antal försök, och en grupp har ingetdera: vad en grupp har är ett medlemskap och en registrering av vad den har arbetat med. Eftersom inga två av dessa uppsättningar matchar, besvarar en enda platt ström av rader alla fyra dåligt.

En produktionsfråga handlar sällan om vad en logg sa. Den handlar om vilken arbetsenhet som missade sin deadline, vilken agent som är ohälsosam, vilken del av operationen som är blockerad och på vad. Nexus rapporterar tillstånd om samma saker som det exekverar, så frågan går till den som äger svaret istället för att sättas samman av rader som råkar nämna det. Det gör frågan adresserbar utan att spela upp en konversation. Tillståndet tillhör den entitet som äger arbetet, så en missad deadline, en ohälsosam agent eller en blockerad operation kan undersökas utifrån dess registrering och aktuella tillstånd.

Återhämtning är något du får veta om. Att se den medan den kör är en annan typ av krav.

Två konsekvenser som en ingenjör kan använda. Eftersom väntetiden är en deterministisk fixpunkt som beräknas från försöksnumret snarare än ett drag från en slumpkälla, är schemat för en misslyckad körning en del av det som spelas upp, så ett argument om hur lång tid gårdagen tog har ett svar snarare än en teori. Och eftersom kretsen tillhör agenten snarare än typen av arbete, stoppar en misslyckad beroende routing till en plats medan samma arbete förblir dirigerbart överallt annars. Varje ersättning skrivs ner när den sker: omdirigeringen namnger ersättningsagenten och det tillstånd som färdades med den, så en räddad körning läses efteråt som ett enda arbete med en återhämtning inuti.

Något kommer att misslyckas, och den intressanta frågan är inte vilket svar som väljs. Det är vad som hindrar återhämtningen från att bli arbetsbelastningen. Varje del av den är begränsad innan problemet börjar: hur många försök, hur lång varje väntan är, hur mycket av tilldelningen en räddning får använda, och hur mycket av egendomen en dålig beroende tar med sig. Ingenting här slutar för att en loop bestämde att den hade försökt tillräckligt. Körningen registrerar försöksnumret, beräknad väntan, kretsens tillstånd, ersättningen och tillståndet som fördes över. Det ger en incidentgranskning en begränsad väg att inspektera: ett försök kan spelas upp, en stängd rutt kan förklaras och ett terminalt fel kan skiljas från en räddning som avslutades.

Policy bestämmer vad som får hända. Något måste bestämma vad som händer när det inte kommer att hända.

Vid sidan av policy finns en uppsättning kontroller som letar efter de operativa fel som ett väluppfostrat enstaka körning aldrig visar dig: samma arbete tilldelat två gånger, en uppgiftstyp utan kvalificerad ägare, resurser som förbrukats utöver vad som finns, en agent som svälts, och latensgränser som missas. Var och en är en operativ invariant som utvärderas mot den levande egendomen snarare än mot ett diagram, och en kontroll som utlöses namnger den entitet den utlöstes på, så att fixen går till en agent snarare än till en teori om designen.