Dybdegående guide

Make AI Agents: praktisk guide

Make AI-agenter kombinerer agentisk valg med Makes visuelle scenario- og tool-model. Det er nyttigt, når agenten skal vælge mellem afgrænsede værktøjer, mens du stadig vil kunne se og kontrollere resten af dataflowet.

3 min.Opdateret 24. juli 2026
Illustration til guiden Make AI Agents: praktisk guide
Kort fortaltMake AI-agenter kombinerer agentisk valg med Makes visuelle scenario- og tool-model. Det er nyttigt, når agenten skal vælge mellem afgrænsede værktøjer, mens du stadig vil kunne se og kontrollere resten af dataflowet.
Læs først

Brug indholdsfortegnelsen til venstre, hvis du allerede kender grundprincipperne og vil direkte til implementeringen.

Kort svar: Make AI-agenter kombinerer agentisk valg med Makes visuelle scenario- og tool-model. Det er nyttigt, når agenten skal vælge mellem afgrænsede værktøjer, mens du stadig vil kunne se og kontrollere resten af dataflowet.

Hvad du får ud af guiden

En Make-agent bør arbejde gennem små, velafgrænsede værktøjer/scenarios. Behold forretningsregler i filters/routers og brug agenten til de dele, hvor den skal vælge mellem handlinger ud fra kontekst.

Når du er færdig, bør du kunne:

  • forklare hovedprincippet med udgangspunkt i din egen opgave
  • afprøve metoden og kontrollere, om kontrakten for hvert værktøj er tydelig
  • genkende og undgå fejlen: “give agenten scenarios med brede, skjulte sideeffekter”

Se det i en konkret situation

En serviceagent får værktøjer med læseadgang til CRM og dokumentation og et skrive-værktøj til at oprette en intern task. Write-værktøj ligger bag approval, mens lookup kan ske automatisk.

Sådan gør du – trin for trin

  1. 1. Definér agentens mål som én proces, ikke “hjælp med alt”.

    Agenten bør kun vælge mellem handlinger, der allerede er afgrænset og kan observeres bagefter.

  2. 2. Tilføj værktøjer med entydige navne og input.

    Relevant input reducerer gæt. Fjern samtidig oplysninger, der ikke kan ændre løsningen, så de ikke skaber støj.

  3. 3. Hold forretningsregler i scenarios/filters hvor de er deterministiske.

    Faste regler hører hjemme i deterministisk logik, hvor resultatet kan forklares og testes uden en model.

  4. 4. Brug agenten til tolkning og valg af værktøj.

    Jo smallere rettigheder og værktøjer er, desto mindre skade kan en forkert modelbeslutning skabe.

  5. 5. Placér godkendelse foran scenarier med skriveadgang med høj konsekvens.

    Placeringen af menneskelig kontrol bør følge konsekvensen ved fejl, ikke hvor “smart” systemet virker.

  6. 6. Test værktøjsvalg, manglende data og prompt injection.

    Testen gør fejl synlige på tværs af flere cases, så du ikke optimerer efter ét heldigt svar.

Her går det oftest galt

  • At give agenten scenarios med brede, skjulte sideeffekter.
  • At lade tool-beskrivelser være vage.
  • At mangle fallback når agenten ikke kan vælge sikkert.

Øvelse: gør det på din egen opgave

Lav en agent med ét read-værktøj og ét approval-beskyttet skrive-værktøj. Test 10 inputs hvor skrive-værktøj kun er korrekt i halvdelen.

Kvalitetstjek

Brug disse spørgsmål, før du gør metoden til en fast arbejdsgang:

  • Er tool-kontrakten tydelig?
  • Er skrive adskilt fra read?
  • Kan scenariet forklare hvorfor en handling kræver approval?

Hvad du kan lære bagefter

Gå videre med den del af emnet, du stadig mangler at kunne bruge i praksis:

Officielle kilder

Produktfunktioner og grænser ændrer sig. Brug de officielle kilder til at kontrollere aktuelle detaljer.

FAQ4 spørgsmål

Ofte stillede spørgsmål

Hvad er hovedpointen i “Make AI-agenter: praktisk guide”?

Make AI-agenter kombinerer agentisk valg med Makes visuelle scenario- og tool-model. Det er nyttigt, når agenten skal vælge mellem afgrænsede værktøjer, mens du stadig vil kunne se og kontrollere resten af dataflowet.

Hvordan kan jeg øve det?

Lav en agent med ét read-værktøj og ét approval-beskyttet skrive-værktøj. Test 10 inputs hvor skrive-værktøj kun er korrekt i halvdelen.

Hvilken fejl bør jeg især undgå?

At give agenten scenarios med brede, skjulte sideeffekter.

Hvornår er min løsning god nok til at bruge?

Brug disse kontrolspørgsmål: Er tool-kontrakten tydelig? Er skrive adskilt fra read? Kan scenariet forklare hvorfor en handling kræver approval?