AI-agenter
AI-agenter og automatiseret workflow
Vi bygger AI-agenter der gør faktisk arbejde — booker, opretter, opdaterer, undersøger — i jeres egne systemer. Med struktureret tool-use, sandboxing og menneskelig godkendelse hvor noget kan gå skævt.
Tools-først
Sådan bygger vi agenter der holder
- Least-privilege på hver tool-kald
- Sandboxed
- Schema-tjek før hver eksekvering
- Validated
- Hver tool-kald logges med kontekst
- Audited
- Godkendelse på ikke-reversible handlinger
- Human-loop
Sådan vi bygger agenter
Tools-først, ikke prompts-først.
En AI-agent er en sprogmodel med tools — funktioner den kan kalde for at gøre faktisk arbejde i jeres systemer. Hente data, opdatere en sag, sende en e-mail, oprette en booking. Det er forskellen på en chatbot der svarer på spørgsmål og en kollega der løser opgaven mens du sover. Bygget rigtigt er agenter en af de mest værdifulde AI-investeringer; bygget forkert er de en sikkerhedsbrist med en regning bagpå.
Vi bygger agenter på tools-først-tankegangen: vi designer den lille, veldefinerede mængde af handlinger agenten må foretage, hver med tydelige input-/output-kontrakter, audit-log og — hvor det er nødvendigt — menneskelig godkendelse før de udføres. Modellen vælger hvilket tool den bruger; jeres system kontrollerer hvad de tools faktisk gør.
Vi har bygget agenter til back-office-automatisering, kundesupport, intern søgning og research. Mønstret er det samme: start med en snæver use-case, mål succes konkret, byg human-in-the-loop hvor handlingen er ikke-reversibel, og udvid scope kun når data viser at det er værd det.
Hvad I får leveret
Agenter der gør faktisk arbejde.
Med struktureret tool-use, sandboxing og menneske-i-loopet hvor det skal til.
Tool design og kontrakt
Vi designer agentens tools som almindelig software: tydelige input-/output-typer, validering på begge sider, idempotens hvor det giver mening, og audit-log på hver kald. Agenten ser tools som en liste; jeres backend kontrollerer hvad de gør.
Sandboxing og least-privilege
Agenten kalder tools via et begrænset sæt rettigheder — typisk en separat service-konto med kun de privilegier den behøver. Skal agenten kunne ændre data, gør den det via en API der validerer, ikke direkte mod databasen.
Menneske-i-loopet hvor det skal til
Ikke-reversible handlinger (sende e-mail, oprette betaling, slette data) godkendes af et menneske før de udføres. Vi designer godkendelses-flow så det føles som et naturligt step — ikke som en pop-up der spammer brugeren.
Evaluering og test-suite
Agenter er svære at teste — vi bygger en evalueringspipeline med scenarier (LangSmith, Braintrust eller egen) der kører ved hver prompt-ændring. I ved om en ændring forbedrede eller forværrede agentens adfærd, før den rammer produktion.
Observability og fejl-håndtering
Hver agent-trace logges: prompts, tool-kald, fejl, model-version, latens. Vi bruger LangSmith, Helicone eller egen stak — så I kan debugge hvorfor agenten gjorde det den gjorde, ikke bare se at noget gik galt.
Cost- og rate-limit-styring
Agenter kan koste mere end almindelige LLM-features fordi de tager flere tool-kald pr. opgave. Vi sætter forbrugs-budgetter pr. agent og pr. bruger, monitorerer trends og alarmerer før I rammer en uventet regning.
Inden I går i gang
Det her bør I overveje først.
Snævert scope slår bredt ambition
Den agent der "klarer alt" er sjældent god til noget. Vi anbefaler at starte med en snæver use-case (tager imod sager og rute dem rigtigt; samler research om en kunde før et møde) hvor succes kan måles. Når det virker, udvider vi — ikke før.
Frontier-model eller mindre
Tool-use kvalitet skalerer med modellens størrelse. Til komplekse multi-step-workflows er Claude Opus, GPT-5 eller Gemini Pro typisk bedre. Til simple klassifikations-agenter klarer Claude Haiku eller GPT-5 Mini sig fint. Vi måler kvalitet vs. omkostning og vælger pragmatisk.
Hallucinerede tool-kald
Modeller kan finde på at kalde tools der ikke findes, eller med argumenter der er mærkeligt formaterede. Vi validerer hver tool-kald mod et schema før det udføres, retry'er ved fejl med klar feedback til modellen, og fallback'er til human-in-the-loop hvis valideringen fejler tre gange.
Sikkerhed: prompt injection og data exfiltration
Agenter der læser brugerinput og kalder tools er en oplagt prompt-injection-vektor. Vi designer agenter med PII-redaktion på input, tydelig system-prompt-hierarki og output-validering der fanger forsøg på at eksfiltrere data via tool-kald. Det er produktionsdisciplin, ikke et nice-to-have.
FAQ
Det folk plejer at spørge om.
Hvad er en god first use-case for en agent?
En god first use-case har tre egenskaber: 1) Tydeligt output (vi ved hvad "rigtigt" er), 2) Begrænset blast radius (det er OK hvis agenten gør noget forkert i 5% af tilfældene), og 3) Repeterbar struktur (samme slags input gentages mange gange). Klassisk: ticket-routing, lead-research før et møde, automatisk svar på FAQ-spørgsmål med eskalering. Vi anbefaler IKKE at starte med agenter der bestiller noget eller sender noget der ikke kan trækkes tilbage.
Hvilke agent-frameworks bruger I?
Vi bygger oftest direkte mod model-leverandørens tool-use API (OpenAI function calling, Anthropic tool use, Gemini function calling) frem for at bruge et tungt framework. Det giver os fuld kontrol og minimal afhængighed. Til mere komplekse workflows bruger vi LangGraph eller egne state machines. Frameworks som CrewAI og AutoGen bruger vi sjældent i produktion.
Hvor lang tid tager det at bygge en agent?
En fokuseret single-purpose-agent (klassificering, routing, simple lookups) er typisk 4–6 uger til produktion. En agent med flere tools, human-in-the-loop og en ordentlig evalueringspipeline er typisk 8–12 uger. Vi går altid live tidligt med en afgrænset version og udvider efter hvordan agenten faktisk performer på rigtig brug.
Hvordan måler vi om agenten faktisk fungerer?
Vi definerer succeskriterier i discovery: gennemsnitlig opgaveløsningstid, andel der ikke kræver menneskelig overstyring, kvalitet via stikprøve-review. Vi sætter målingen op fra dag ét. Hvis tallene ikke flytter sig, finder vi ud af hvorfor — typisk er det enten tool-design (agenten har ikke det rigtige værktøj), prompt (modellen forstår ikke konteksten) eller use-case (det her var ikke et godt agent-problem fra start).
Hvad med GDPR og audit?
Hver tool-kald logges med: bruger, input, model-output, tool-output, timestamp og model-version. Vi designer for ret-til-sletning (logs kan filtreres pr. bruger) og for audit (en handling kan altid spores tilbage til hvilken agent-instans der gjorde hvad og hvorfor). Bruger I følsomme data, kører vi via EU-residente modeller eller selv-hostet.
Klar til at starte?
Lad os tage en uforpligtende snak.
Vi vender tilbage indenfor en arbejdsdag med konkret input — ikke et standardtilbud.