Hoe ElevenAgents Architect werkt
Overzicht
Een gesprek met ElevenAgents Architect verloopt als een realtime ElevenAgents-gesprek, op dezelfde engine die de agents aandrijft die je bouwt. De tools van Architect worden in je browser uitgevoerd tijdens je ingelogde sessie. Elke tool roept dezelfde ElevenAgents-API’s aan als het dashboard, zodat elke lees- en schrijfbewerking wordt gecontroleerd aan de hand van je eigen rechten. Zie Machtigingen, goedkeuringen en concepten.
Wat ElevenAgents Architect standaard weet
Aan het begin van elk gesprek ontvangt Architect:
- Je account en workspace: je abonnement, workspace en gebruik.
- Waar je bent: de pagina en, wanneer je in een agent bent, die agent en de branch die je hebt geopend. In de sidebar krijgt Architect ook een momentopname van de pagina en vóór elk bericht een update als de pagina is gewijzigd.
- Een samenvatting van de agent: samengesteld door ElevenLabs wanneer je in een agent bent. Deze bevat de naam en eigenaar van de agent, de branches en hun verkeersverdeling, het belvolume van de afgelopen 7 dagen, de conceptstatus, verbonden agents, procedures, of tests zijn geconfigureerd en welke branches je kunt bewerken.
- Agentcontext: het
agents.md-document van de agent, gedeeld met iedereen die de agent bouwt. Zie Architect aanpassen. - Je voorkeuren: je persoonlijke
user.md-document, dat geldt voor elke agent die je bouwt. - Wat het startpunt heeft doorgegeven: bijvoorbeeld de mislukte tests, de Spotlight-bevinding of het probleem. Zie Een gesprek starten.
- Eerdere berichten in deze chat.
Architect begint niet met de volledige configuratie van de agent, de transcripten, testresultaten, Spotlight-gegevens of je andere Architect-chats. Architect leest deze met tools wanneer dat nodig is voor de taak. Zo blijft elk gesprek gefocust en werkt Architect altijd met actuele gegevens in plaats van een verouderde kopie.
Onderzoeken en directe instructies
Architect behandelt twee soorten verzoeken verschillend.
Directe instructies noemen de wijziging, bijvoorbeeld “Voeg een vangrail toe die gesprekken over prijzen van concurrenten blokkeert” of “Maak het eerste bericht korter.” Architect leest de relevante configuratie, voert de wijziging uit en meldt wat het heeft klaargezet. In de standaardgoedkeuringsmodus worden wijzigingen in de agentconfiguratie zonder te vragen in een concept klaargezet. Acties die live verkeer of gedeelde resources beïnvloeden, wachten op je goedkeuring.
Onderzoeken stellen een vraag zonder een oplossing te noemen, bijvoorbeeld “Waarom worden gesprekken over terugbetalingen geëscaleerd?” of “Hoe verbeter ik oplossingen voor terugbetalingen?” Architect onderzoekt dit voordat het iets wijzigt:
- Het schrijft een takenlijst voor het onderzoek, die boven de editor zichtbaar blijft terwijl items worden voltooid.
- Het begint met goedkope signalen, zoals aantallen gesprekken, onderwerpen en evaluatieresultaten, voordat het afzonderlijke transcripten leest.
- Het analyseert gesprekken parallel en groepeert bevindingen op hoofdoorzaak.
- De redenering is zichtbaar. Elke redeneerstap wordt samengevouwen tot Gedachte gedurende Ns en kan worden uitgeklapt.
- Het rapporteert wat het heeft gevonden, inclusief hoeveel gesprekken het daadwerkelijk heeft gelezen. Het presenteert een steekproef niet als volledig.
Planmodus
Schakel voor grotere wijzigingen de editor naar Plan (druk op Shift+Tab om tussen modi te wisselen). In de planmodus doet Architect onderzoek met alleen-lezen-tools, schrijft het een plan dat je kunt volgen terwijl het wordt opgesteld, en vraagt het je vervolgens om het plan Goed te keuren of Af te wijzen. Het brengt geen wijzigingen aan totdat je goedkeurt. Als je het plan met een opmerking afwijst, herziet Architect het en vraagt het opnieuw.
In het Architect-tabblad op volledig scherm verschijnt het plan in een paneel boven de editor. In de sidebar verschijnt het als kaart in de chat.
Uitgewerkt voorbeeld: oplossingen voor terugbetalingen verbeteren
Dit voorbeeld volgt één gesprek van een brede vraag tot een wijziging die klaar is voor beoordeling. Toolnamen worden weergegeven, zodat je elke stap kunt koppelen aan wat in het gesprek verschijnt. Architect kiest zelf zijn stappen, dus een echt gesprek kan verschillen in volgorde en detail.
Het verzoek, verzonden vanuit het Architect-tabblad van de agent:
Hoe verbeter ik oplossingen voor terugbetalingen?
Het onderzoek plannen
Architect schrijft een takenlijst (write_todos): het probleem meten, mislukte gesprekken over terugbetalingen
vinden, hoofdoorzaken identificeren en een oplossing voorstellen en testen.
Het probleem meten
Architect leest de onderwerpen van de agent (get_agent_topics, get_topics_summary) om het onderwerp terugbetalingen
en het succespercentage te vinden. Vervolgens telt en toont het recente gesprekken over terugbetalingen die de
evaluatie niet haalden (count_conversations, list_conversations).
De gesprekken lezen
Architect doorzoekt transcripten op verzoeken om terugbetaling (search_conversation_messages,
semantic_search_conversations) en analyseert vervolgens parallel een batch mislukte gesprekken
(analyze_conversation_subagent). Elke analyse rapporteert wat de gebruiker wilde, waar de agent
de fout in ging en in welke beurt dat gebeurde.
De hoofdoorzaak vinden
Architect vergelijkt de fouten met de huidige configuratie (get_agent_config,
list_procedures, get_procedure). Het rapporteert bijvoorbeeld: “In 31 van de 40 mislukte gesprekken over terugbetalingen
riep de agent lookup_order aan voordat om het ordernummer werd gevraagd, kreeg een foutmelding en
escaleerde.”
De wijziging op een branch uitvoeren
Architect maakt een branch (create_branch) zodat de wijziging is geïsoleerd van de live agent. Vervolgens
bewerkt het de terugbetalingsprocedure (update_procedure) om vóór de zoekopdracht om het ordernummer te
vragen. De bewerking wordt klaargezet in je concept op die branch. Voor live bellers is niets gewijzigd.
Tests voor de wijziging schrijven
Architect schrijft tests die de fout vastleggen: een simulatie van een beller die om een terugbetaling vraagt
zonder een ordernummer te geven (create_simulation_test), een tool-calltest die controleert dat
lookup_order niet als eerste wordt aangeroepen (create_tool_test), en een test die is gegenereerd op basis van een van de
echte mislukte gesprekken (generate_test_from_conversation). Architect mockt tools met bijwerkingen in simulaties,
zodat er geen echte terugbetalingen worden uitgevoerd.
De tests voor en na uitvoeren
Architect voert de tests uit op de agent zonder de wijziging (run_tests op de oorspronkelijke
branch, of run_agent_tests met include_draft: false), vervolgens op het concept met de
wijziging (run_agent_tests) en leest de resultaten (get_test_suite_summary,
get_test_suite_failures). Het verwachte resultaat is dat de nieuwe tests zonder de wijziging falen
en ermee slagen. Als tests nog steeds falen, leest Architect de fouten, past het de wijziging aan en
voert het ze opnieuw uit.
De wijziging presenteren
Architect vat de hoofdoorzaak, de wijziging en de testresultaten samen en opent het publicatievenster
(request_draft_publish). Je beoordeelt de diff en selecteert Publiceren, waarmee de
wijziging als nieuwe versie op de branch wordt vastgelegd. Architect kan niet namens jou publiceren.
Een voorstel openen
Architect leest de geschiedenis en mergepreview van de branch (get_branch_history,
merge_branch_preview) en opent een mergevoorstel naar main (create_merge_proposal). De
beschrijving bevat drie secties: Samenvatting, Testen en Hoe je beoordeelt, geschreven op basis van
de daadwerkelijke commits en testruns. Architect kan reviewers voorstellen
(suggest_merge_proposal_reviewers), maar jij kiest ze.
Validatie vindt plaats in het gesprek, voordat je wordt gevraagd iets te publiceren of te beoordelen. Wanneer het voorstel een reviewer bereikt, zijn de tests die de aanleiding vormden voor de wijziging al aan de agent gekoppeld en op de branch uitgevoerd. Zie Voorstellen en validatie voor wat de reviewer ziet.
De testrun voor en na is een goede werkwijze, maar Architect voert deze niet automatisch uit bij elke wijziging. Vraag er rechtstreeks om om er zeker van te zijn, bijvoorbeeld: “Laat me zien dat de nieuwe tests falen op main en slagen op de branch.”
Slash-commando’s
Typ / in de editor om de commando’s te zien die beschikbaar zijn op de huidige pagina.
De meeste commando’s zijn alleen van toepassing wanneer je in een agent bent. /clear en /feedback zijn niet beschikbaar op de startpagina van het Architect-tabblad.
Dashboards in de chat
Architect kan in het gesprek een dashboard bouwen om een vraag met gegevens te beantwoorden, bijvoorbeeld: “Splits de escalaties van deze week uit naar reden en laat me de trend zien.” Gebruik /dashboard of vraag er rechtstreeks om.
Architect verzamelt de gegevens met zijn tools, verwerkt ze met code en rendert een dashboard met dezelfde metriektegels, grafieken, lijsten en tekstkaarten als Spotlight. Een dashboard kan het volgende bevatten:
- Metriektegels met een hoofdwaarde, wijziging en sparkline.
- Grafieken: gebieds-, lijn-, staaf-, gestapelde gebieds- en donutgrafieken, en gerangschikte staaflijsten voor top-N-uitsplitsingen.
- Lijsten met statuslabels, datums en links naar pagina’s in ElevenAgents, zoals afzonderlijke gesprekken.
- Tekstkaarten voor bevindingen en aanbevelingen.
In het Architect-tabblad op volledig scherm worden dashboards inline in het gesprek gerenderd. In de sidebar openen ze in een paneel naast de chat.
Dashboardgegevens worden alleen in het geheugen bewaard in het browsertabblad waarin ze zijn gebouwd en nooit bij de chat opgeslagen. Nadat je de pagina opnieuw hebt geladen, de chat in een ander tabblad hebt geopend of meerdere grote dashboards hebt gebouwd, toont een ouder dashboard een bericht in plaats van de gegevens. Vraag Architect om het opnieuw te bouwen. Dashboards zijn alleen-lezenmomentopnamen. Ze hebben geen filters en worden niet live bijgewerkt.
Code uitvoeren
Architect kan korte Python-programma’s uitvoeren om gegevens uit zijn tools te tellen, groeperen en vergelijken, bijvoorbeeld om oplossingspercentages per week te berekenen voor enkele honderden gesprekken. De code wordt uitgevoerd in een sandbox in je browser met alleen de Python-standaardbibliotheek. Deze heeft geen netwerktoegang, geen toegang tot je ElevenLabs-account en een tijdslimiet van 20 seconden. Het uitvoeren van code wordt geleidelijk uitgerold en is mogelijk niet in elke workspace beschikbaar.
Grote responses
Wanneer een tool meer gegevens retourneert dan in het gesprek passen, zoals een lange lijst gesprekken, bewaart Architect de volledige response in het geheugen van je browsertabblad en werkt het met een samenvatting. Het kan de rest op verzoek doorzoeken en lezen. Een melding bij de tool-call toont wanneer dit is gebeurd. Deze responses worden nooit opgeslagen of geüpload.