> This is a page from the ElevenLabs documentation. For a complete page index, fetch https://elevenlabs.io/docs/llms.txt. For the full documentation in a single file, fetch https://elevenlabs.io/docs/llms-full.txt.
# Så fungerar ElevenAgents Architect
## Översikt
En konversation med ElevenAgents Architect körs som en ElevenAgents-konversation i realtid, på samma motor som driver agenterna du bygger. Architects verktyg körs i din webbläsare under din inloggade session. Varje verktyg anropar samma ElevenAgents-API:er som instrumentpanelen använder, så varje läs- och skrivåtgärd kontrolleras mot dina egna behörigheter. Se [Behörigheter, godkännanden och utkast](/docs/sv/eleven-agents/operate/architect/authentication).
## Vad ElevenAgents Architect känner till som standard
I början av varje konversation får Architect:
* **Ditt konto och din arbetsyta**: din plan, arbetsyta och användning.
* **Var du är**: sidan och, när du är inne i en agent, den agenten och den gren du har öppen. I sidofältet får Architect även en ögonblicksbild av sidan samt en uppdatering före varje meddelande om sidan har ändrats.
* **En agentsammanfattning**: skapad av ElevenLabs när du är inne i en agent. Den omfattar agentens namn och ägare, dess grenar och deras trafikfördelning, samtalsvolym de senaste 7 dagarna, utkaststatus, anslutna agenter, procedurer, om tester är konfigurerade och vilka grenar du kan redigera.
* **Agentkontext**: agentens `agents.md`-dokument, som delas med alla som bygger agenten. Se [Anpassa Architect](/docs/sv/eleven-agents/operate/architect/customization).
* **Dina inställningar**: ditt personliga `user.md`-dokument, som gäller för varje agent du bygger.
* **Vad startpunkten skickade med**: till exempel misslyckade tester, en Spotlight-insikt eller ett triageärende. Se [Starta en konversation](/docs/sv/eleven-agents/operate/architect/entry-points).
* **Tidigare meddelanden i den här chatten.**
Architect startar **inte** med agentens fullständiga konfiguration, dess transkript, testresultat, Spotlight-data eller dina andra Architect-chattar. Den läser in detta med verktyg när uppgiften kräver det. Det håller varje konversation fokuserad och innebär att Architect alltid arbetar med aktuell data i stället för en inaktuell kopia.
## Undersökningar och direkta instruktioner
Architect hanterar två typer av förfrågningar olika.
**Direkta instruktioner** anger ändringen, till exempel ”Lägg till en skyddsräcke som blockerar diskussion om konkurrenters prissättning” eller ”Gör det första meddelandet kortare.” Architect läser relevant konfiguration, gör ändringen och rapporterar vad den har lagt i staging. I standardläget för godkännanden läggs ändringar av agentkonfigurationen i staging i ett utkast utan att fråga. Åtgärder som påverkar live-trafik eller delade resurser väntar på ditt godkännande.
**Undersökningar** ställer en fråga utan att ange en lösning, till exempel ”Varför eskaleras återbetalningssamtal?” eller ”Hur förbättrar jag återbetalningslösningar?” Architect undersöker innan något ändras:
* Den skriver en **att göra-lista** för undersökningen, som förblir synlig ovanför skrivfältet när uppgifter slutförs.
* Den börjar med billiga signaler, som antal konversationer, ämnen och utvärderingsresultat, innan den läser enskilda transkript.
* Den analyserar konversationer parallellt och grupperar det den hittar efter grundorsak.
* Dess resonemang är synligt. Varje resonemangssteg fälls ihop till **Tanke i Ns** och kan expanderas.
* Den rapporterar vad den hittade, inklusive hur många konversationer den faktiskt läste. Den framställer inte ett urval som fullständigt.
### Planläge
För större ändringar växlar du skrivfältet till **Plan** (tryck på Shift+Tab för att växla mellan lägen). I planläget undersöker Architect med skrivskyddade verktyg, skriver en plan som du kan se den utforma och ber dig sedan att **Godkänn plan** eller **Avvisa**. Den gör inga ändringar förrän du godkänner. Om du avvisar planen med en kommentar reviderar Architect den och frågar igen.
På Architect-fliken i helskärm visas planen i en panel ovanför skrivfältet. I sidofältet visas den som ett kort i chatten.
## Exempel: förbättra återbetalningslösningar
Det här exemplet följer en enda konversation från en bred fråga till en ändring som är redo för granskning. Verktygsnamn visas så att du kan koppla varje steg till det som visas i konversationen. Architect väljer sina egna steg, så en verklig konversation kan skilja sig åt i ordning och detaljnivå.
Förfrågan, skickad från agentens Architect-flik:
> Hur förbättrar jag återbetalningslösningar?
#### Planera undersökningen
Architect skriver en att göra-lista (`write_todos`): mät problemet, hitta misslyckade
återbetalningskonversationer, identifiera grundorsaker och föreslå samt testa en lösning.
#### Mät problemet
Architect läser agentens ämnen (`get_agent_topics`, `get_topics_summary`) för att hitta återbetalnings-
ämnet och dess lösningsgrad, räknar sedan och listar nyliga återbetalningskonversationer som misslyckades
i utvärderingen (`count_conversations`, `list_conversations`).
#### Läs konversationerna
Architect söker i transkript efter återbetalningsförfrågningar (`search_conversation_messages`,
`semantic_search_conversations`) och analyserar sedan ett urval av misslyckade konversationer parallellt
(`analyze_conversation_subagent`). Varje analys rapporterar vad användaren ville, var agenten
gjorde fel och vid vilken tur det hände.
#### Hitta grundorsaken
Architect jämför misslyckandena med den aktuella konfigurationen (`get_agent_config`,
`list_procedures`, `get_procedure`). Den rapporterar till exempel följande: ”I 31 av 40 misslyckade
återbetalningssamtal anropade agenten `lookup_order` innan den frågade efter ordernumret, fick ett fel och
eskalerade.”
#### Gör ändringen i en gren
Architect skapar en gren (`create_branch`) så att ändringen isoleras från live-agenten. Den
redigerar sedan återbetalningsproceduren (`update_procedure`) för att fråga efter ordernumret före
uppslaget. Ändringen läggs i staging i ditt utkast på den grenen. Inget har ändrats för live-uppringare.
#### Skriv tester för ändringen
Architect skriver tester som fångar felet: en simulering av en uppringare som ber om återbetalning
utan att ange ett ordernummer (`create_simulation_test`), ett verktygsanropstest som kontrollerar att
`lookup_order` inte anropas först (`create_tool_test`) och ett test som genereras från en av de
verkliga misslyckade konversationerna (`generate_test_from_conversation`). Architect simulerar verktyg som har
sidoeffekter i simuleringar, så inga verkliga återbetalningar utfärdas.
#### Kör testerna före och efter
Architect kör testerna mot agenten utan ändringen (`run_tests` på den ursprungliga
grenen, eller `run_agent_tests` med `include_draft: false`), sedan mot utkastet med
ändringen (`run_agent_tests`), och läser resultaten (`get_test_suite_summary`,
`get_test_suite_failures`). Det förväntade resultatet är att de nya testerna misslyckas utan ändringen
och godkänns med den. Om tester fortfarande misslyckas läser Architect felen, justerar ändringen och
kör dem igen.
#### Presentera ändringen
Architect sammanfattar grundorsaken, ändringen och testresultaten och öppnar publicerings-
dialogrutan (`request_draft_publish`). Du granskar diffen och väljer **Publicera**, vilket genomför
ändringen som en ny version i grenen. Architect kan inte publicera åt dig.
#### Öppna ett förslag
Architect läser grenens historik och sammanslagningsförhandsvisning (`get_branch_history`,
`merge_branch_preview`) och öppnar ett sammanslagningsförslag till `main` (`create_merge_proposal`).
Beskrivningen har tre avsnitt, **Sammanfattning**, **Testning** och **Så granskar du**, skrivna utifrån
de faktiska ändringarna och testkörningarna. Architect kan föreslå granskare
(`suggest_merge_proposal_reviewers`), men du väljer dem.
#### Erbjud en gradvis utrullning
Architect erbjuder att skicka en liten andel av live-trafiken, vanligtvis 5 %, till grenen medan
förslaget granskas (`set_traffic_split`). Detta ändrar live-trafiken, så det väntar på ditt
godkännande.
Validering sker i konversationen innan du ombeds att publicera eller granska något. När förslaget når en granskare är testerna som motiverade ändringen redan kopplade till agenten och har körts på grenen. Se [Förslag och validering](/docs/sv/eleven-agents/operate/architect/proposals) för vad granskaren ser.
> **Tip**
>
> Testkörningen före och efter är en bra praxis, men Architect kör den inte automatiskt vid
> varje ändring. För att säkerställa att den gör det ber du om det direkt, till exempel ”Visa mig de nya testerna
> som misslyckas på main och godkänns i grenen.”
## Snedstreckskommandon
Skriv `/` i skrivfältet för att se de kommandon som är tillgängliga på den aktuella sidan.
| Kommando | Vad det gör |
| ------------- | --------------------------------------------------------------------------------- |
| `/start` | Konfigurera agentens kontext (`agents.md`) så att Architect känner till dina mål. |
| `/generate` | Generera en ny agent från en beskrivning. |
| `/debug` | Felsök nyliga misslyckade konversationer. |
| `/test` | Kör tester och sammanfatta resultaten. |
| `/explain` | Förklara vad den här agenten gör på enkel svenska. |
| `/optimize` | Föreslå förbättringar av prompt och konfiguration. |
| `/review` | Granska agentens prestanda och hitta förbättringar. |
| `/branch` | Skapa en ny gren för den här agenten. |
| `/experiment` | Skapa en gren och driftsätt den som ett A/B-test. |
| `/rollback` | Granska nyliga konfigurationsändringar och ångra dem vid behov. |
| `/remember` | Spara ett faktum för agenten som ett kunskapsbasdokument. |
| `/dashboard` | Bygg en anpassad analysinstrumentpanel i chatten. |
| `/clear` | Rensa den här konversationen och börja om. |
| `/feedback` | Skicka privat feedback om den här sessionen till ElevenLabs. |
De flesta kommandon gäller bara när du är inne i en agent. `/clear` och `/feedback` är inte tillgängliga på Architect-flikens startsida.
## Instrumentpaneler i chatten
Architect kan bygga en instrumentpanel i konversationen för att besvara en fråga med data, till exempel ”Dela upp den här veckans eskaleringar efter orsak och visa trenden.” Använd `/dashboard` eller be om en direkt.
Architect samlar in data med sina verktyg, formar den med [kod](#running-code) och renderar en instrumentpanel med samma metrikkort, diagram, listor och textkort som Spotlight. En instrumentpanel kan innehålla:
* **Metrikkort** med ett rubrikvärde, förändring och minidiagram.
* **Diagram**: yta, linje, stapel, staplad yta, ringdiagram och rankade stapellistor för topp-N-uppdelningar.
* **Listor** med statusetiketter, datum och länkar till sidor i ElevenAgents, till exempel enskilda konversationer.
* **Textkort** för insikter och rekommendationer.
På Architect-fliken i helskärm renderas instrumentpaneler direkt i konversationen. I sidofältet öppnas de i en panel bredvid chatten.
Instrumentpanelsdata sparas bara i minnet i den webbläsarflik där den byggdes och sparas aldrig med chatten. När du laddar om sidan, öppnar chatten i en annan flik eller bygger flera stora instrumentpaneler visar en äldre instrumentpanel ett meddelande i stället för sin data. Be Architect att bygga om den. Instrumentpaneler är skrivskyddade ögonblicksbilder. De har inga filter och uppdateras inte live.
## Köra kod
Architect kan köra korta Python-program för att räkna, gruppera och jämföra data från sina verktyg, till exempel för att beräkna lösningsgrader per vecka över några hundra konversationer. Koden körs i en sandbox-miljö i din webbläsare med endast Pythons standardbibliotek. Den har ingen nätverksåtkomst, ingen åtkomst till ditt ElevenLabs-konto och en tidsgräns på 20 sekunder. Kodkörning rullas ut gradvis och kanske inte är tillgänglig i alla arbetsytor.
## Stora svar
När ett verktyg returnerar mer data än vad som ryms i konversationen, till exempel en lång lista med konversationer, behåller Architect hela svaret i minnet i din webbläsarflik och arbetar med en sammanfattning. Den kan söka i och läsa resten vid behov. Ett meddelande i verktygsanropet visar när detta har hänt. Dessa svar sparas eller laddas aldrig upp.