Definere en agent

name er en stabil identifikator. I et system med flere agenter og hub-og-eiker ruter koordinatoren arbeid til subagenter, og navnet brukes til å adressere en bestemt agent.

Hold navnene korte, med små bokstaver og basert på rollen: research_agent, code_reviewer, refund_specialist.

Men husk et viktig eksamensfaktum: navn er IKKE den primære mekanismen for valg. Når modellen avgjør om den skal bruke et verktøy eller en agent, støtter den seg på beskrivelsen, ikke navnet. Et tydelig navn hjelper derfor mennesker, men det er beskrivelsen som står for den faktiske rutingen.

description er feltet en koordinator leser for å avgjøre når arbeid skal overleveres til denne agenten. Det er det viktigste enkeltfeltet for korrekt ruting.

En god beskrivelse angir:

• Formål – hva agenten gjør
• Grenser for bruksområde – når den skal brukes, og når den IKKE skal brukes

Vage eller overlappende beskrivelser på tvers av agenter fører til feilruting: Koordinatoren velger feil spesialist. Gjør beskrivelsen av hver agent særpreget, slik at det ikke er tvil om hvem som har ansvar for hvilken oppgave.

system_prompt angir agentens vedvarende identitet og regler. Den gjelder gjennom hver omgang i den agentiske løkken, så legg de stabile atferdsgarantiene dine her.

Skriv eksplisitte kriterier, ikke vage oppfordringer. Sammenlign:

• Vagt: "Vær forsiktig med refusjoner."
• Eksplisitt: "Kall aldri process_refund før get_customer har returnert en bekreftet kunde-ID."

Eksplisitte instruksjoner gir gjennomgående bedre resultater enn vage formuleringer. Modellen kan handle ut fra en konkret regel, men den kan ikke pålitelig handle ut fra «vær mer forsiktig».

Her er et subtilt, men eksamenskritisk poeng. system_prompt veileder atferden – men veiledning er omtrent 90 % pålitelig, ikke 100 %.

Hvis en regel har økonomiske, juridiske eller sikkerhetsmessige konsekvenser, må du IKKE stole på instruksjonen alene. Håndhev den deterministisk med en hook.

• Instruksjon: "Ikke refunder mer enn 500 dollar" – fungerer det meste av tiden (~90 %).
• Hook: en PostToolUse- eller utgående-anrop-hook som blokkerer enhver refusjon over 500 dollar – fungerer 100 % av tiden.

Derfor: Legg atferd i system_prompt, men legg harde garantier i hooks. Å definere en agent godt innebærer å vite hvilke regler som hører hjemme hvor.

Feltet allowed_tools avgrenser nøyaktig hvilke verktøy agenten har tilgang til. Dette er den primære sikkerhetsgrensen din: En agent kan ganske enkelt ikke kalle et verktøy som ikke står på listen.

Tilpass verktøyene til rollen. En refusjonsagent trenger ikke WebSearch, og en research-agent trenger ikke process_refund. Ekstra verktøy er ikke en bekvemmelighet – de utgjør en risiko og gjør valget mindre presist.

Flere verktøy er ikke bedre. Påliteligheten ved valg av verktøy har et optimalt nivå:

• 4–5 verktøy per agent er optimalt.
• 18 eller flere verktøy svekker valget merkbart – modellen ruter feil mellom for mange lignende alternativer.

Hvis agentens allowed_tools-liste begynner å bli lang, er det et tegn på et designproblem. Del arbeidet mellom fokuserte subagenter, som hver har et begrenset verktøysett og en særpreget beskrivelse. Det er det avgrensede ansvarsområdet som gjør hver agent pålitelig.

Å definere agentens verktøy er halve jobben; å definere beskrivelsen av hvert verktøy er den andre halvdelen. Verktøybeskrivelser – ikke verktøynavn – er det modellen bruker til å avgjøre hvilket verktøy som skal kalles.

En god verktøybeskrivelse inneholder:

• formål
• returverdier
• inndataformater med eksempler
• kanttilfeller og grenser for bruksområdet

Overlappende eller tvetydige verktøybeskrivelser fører til det samme problemet med feilruting som tvetydige agentbeskrivelser, bare ett nivå lenger ned.

Når du definerer en koordinator i et hub-og-eiker-system, delegerer den arbeid til subagenter. For at dette skal fungere, må koordinatorens allowed_tools inneholde "Task" – det er verktøyet den bruker til å starte subagenter.

Én annen kritisk opplysning: Subagenter arver IKKE koordinatorens samtalehistorikk. Hver subagent starter på nytt, så all nødvendig kontekst må sendes eksplisitt i instruksjonen til subagenten. Definisjonen styrer kapasitet; instruksjonen ved delegeringstidspunktet styrer kontekst.

En godt definert agent leses nesten som en stillingsannonse:

• name: en stabil referanse for ruting
• description: en presis angivelse av formål og grenser, slik at en koordinator delegerer riktig
• system_prompt: eksplisitte, varige atferdsregler (probabilistiske – kombiner med hooks for harde garantier)
• allowed_tools: et begrenset sett med minste privilegium, helst 4–5 verktøy, hvert med en utførlig beskrivelse

Når alle fire er tydelige og ikke overlapper, gjør agenten én jobb godt. Det er grunnlaget som all arkitektur med flere agenter bygger på.

Det viktigste å ta med seg:

• En AgentDefinition = name, description, system_prompt, allowed_tools.
• description (ikke name) styrer delegering og valg av verktøy/agent – hold den presis og uten overlapp.
• system_prompt angir varig, eksplisitt atferd, men er bare ~90 % pålitelig; håndhev regler for økonomi, juss og sikkerhet med hooks (100 % deterministisk).
• allowed_tools = minste privilegium; sikt mot 4–5 verktøy, siden 18 eller flere svekker valget. Hvert verktøy trenger en utførlig beskrivelse.
• En koordinator må inkludere "Task" i allowed_tools, og subagenter arver INGEN historikk – send konteksten eksplisitt.

Definer smalt og tydelig, så blir hver agent du bygger forutsigbar.