# Backupmodeller til AI-agenter: Sådan holder du din agent kørende, når en model fejler

> Sådan fungerer backupmodeller til AI-agenter, hvilke fejl der bør udløse en fallback, hvorfor backupmodellen opfører sig anderledes, og hvordan du tester den, før et nedbrud sker.

Last updated: 2026-09-28T14:00:00

Canonical URL: https://crevio.co/da/blog/ai-agent-backup-models

*Senest opdateret: september 2026. Statussider, hændelsesrapporter og dokumentation kontrolleret den 28. september 2026.*

**Din agents model kommer til at fejle, og den backupmodel, du har sat op til at overtage, kommer ikke til at opføre sig som den model, du testede med.** Den 28. september 2026 viste Claude API's statusside 99,52 % oppetid de foregående 90 dage. Det lyder næsten perfekt, indtil du regner efter: 0,48 % af 90 dage svarer til cirka 10 timers forringet eller utilgængelig service i løbet af et kvartal. En backupmodel til AI-agenter er det, der holder din agent kørende i de timer. Sætter du den skødesløst op, er det også sådan, en opgave stille og roligt bliver halvt færdig på en model, ingen nogensinde har prøvet.

Denne guide er til virksomhedsejere og operatører, der kører agenter efter en tidsplan eller bruger dem over for kunder. Den gennemgår, hvad der går galt, hvilke fejl der bør udløse et skift, hvordan de vigtigste routingværktøjer håndterer det, og hvordan du beviser, at din fallback virker, før du får brug for den.

- **Tre forskellige fejl ser ens ud udefra:** nedbrud, rate limits og udgåede modeller. Kun nogle af dem kræver en backupmodel
- **Prøv igen først, skift derefter.** Mange fejl forsvinder efter et kort retry eller på en anden host, der kører den samme model
- **En backupmodel er ikke en kopi, du bare kan sætte ind.** Nyere modeller afviser parametre, som ældre modeller accepterede, tool calling fungerer anderledes, og den opvarmede prompt-cache er væk
- **Fallbacks koster mere pr. trin, end du forventer,** fordi backupmodellen starter med en kold cache
- **En fallback, der ikke er testet, er et gæt.** Fremprovokér en fejl, kør rigtige opgaver på backupmodellen, og log, hvilken model der svarede

## Hvad er en backupmodel til en AI-agent?

En backupmodel til en AI-agent, ofte kaldet en LLM-fallback, er en anden model, der er sat op på forhånd til at overtage, når agentens primære model ikke kan svare. Skiftet sker normalt automatisk: En router eller gateway registrerer fejlen, sender den samme forespørgsel til den næste model på en liste og leverer svaret tilbage, som om intet var hændt.

Det er ét af fire beskyttelseslag, og det bør være det tredje, du tager i brug – ikke det første:

| Lag | Hvad det gør | Løser | Skifter modellen? |
|---|---|---|---|
| **Retry** | Sender den samme forespørgsel igen efter en kort ventetid | Korte spidsbelastninger, enkeltstående timeouts | Nej |
| **Host-failover** | Sender forespørgslen til en anden udbyder, der kører den samme model | Fejl på ét datacenter eller én host | Nej |
| **Model-fallback** | Sender forespørgslen til en anden model | Større nedbrud, opbrugte kvoter | Ja |
| **Planlagt migrering** | Flytter agenten til en ny model med vilje | Udgående modeller og udfasninger | Ja, permanent |

Rækkefølgen betyder noget, fordi hvert trin ned gennem tabellen ændrer mere af den måde, din agent opfører sig på. Et retry ændrer ingenting. En anden model ændrer næsten alt, som de næste afsnit viser.

## Tre måder, din primære model kan fejle på

### Nedbrud

Alle større udbydere har oplevet dem, og hændelsesrapporterne er offentlige. Den 11. december 2024 var [alle OpenAI-tjenester betydeligt forringede eller nede](https://status.openai.com/incidents/ctrsv3lwd797) fra kl. 15.16 til 19.38 Pacific Time: 4 timer og 22 minutter på tværs af ChatGPT, API'et og Sora. Årsagen var en ny telemetritjeneste, der overbelastede OpenAI's Kubernetes-kontrolplan. Fejlen viste sig kun i store klynger, så den blev ikke opdaget under test.

![OpenAI-statusside for hændelsen den 11. december 2024, markeret som Resolved og Full outage, med 9 berørte API-komponenter og 5 berørte ChatGPT-komponenter vist med røde og gule statusbjælker](https://crevio.co/vite/assets/openai-status-december-2024-incident-gqiohlkd.png)

Kortere hændelser er langt mere almindelige. Den 4. marts 2026 rapporterede OpenAI [30 minutter med forhøjet antal API-fejl](https://status.openai.com/incidents/01KJXQDJ6P1CG5YNXKZRY2H6RX/write-up), efter at en række forsinkede kapacitetsændringer blev gennemført på én gang og tog inferensmotorer ud af drift. Anthropics statusside viser det samme mønster: lange perioder med grønt afbrudt af en jævn spredning af korte røde og gule dage.

![Claude-statusside, der viser All Systems Operational med oppetid for de seneste 90 dage: claude.ai på 99,43 %, Claude Console på 99,95 % og Claude API på 99,52 %](https://crevio.co/vite/assets/claude-status-page-eal06oie.png)

Et nedbrud på 30 minutter bemærkes knap, når du chatter. Det betyder meget, når en planlagt opgave kører i det tidsrum, fordi der ikke sidder nogen klar til at trykke på retry.

### Rate limits og 429-fejl

En 429-fejl betyder, at udbyderen er tilgængelig, men ikke vil betjene dig lige nu. Det meste af tiden skyldes det en grænse pr. minut: Anthropics API bruger en [token bucket, der fyldes løbende op](https://platform.claude.com/docs/en/api/rate-limits), og sender en `retry-after`-header, der fortæller, hvor mange sekunder du skal vente. Det rigtige er at vente så længe og derefter prøve den samme model igen.

Det er dog ikke alle 429-fejl, der er midlertidige. Når en Anthropic-organisation når sit månedlige forbrugsloft, returnerer API'et en 429-fejl **uden** en `retry-after`-header, og dokumentationen er kontant: "Retrying, including the SDKs' automatic retries, fails until access resumes." Adgangen kommer tilbage i begyndelsen af den næste måned. En agent, der behandler alle 429-fejl som "vent og prøv igen", vil kunne prøve hele natten mod en grænse, der måske ikke nulstilles i flere uger.

### Udfasninger og udgåede modeller

Modeller bliver udfaset efter en tidsplan, og en udgået model forringes ikke gradvist. [Anthropics udfasningspolitik](https://platform.claude.com/docs/en/about-claude/model-deprecations) lover mindst 60 dages varsel for offentligt udgivne modeller og fastslår, at "requests to models past the retirement date will fail." Claude Opus 4.1 er et nyere eksempel: Udviklere blev underrettet den 5. juni 2026, og modellen blev udfaset den 5. august 2026.

![Claude Platform Docs-side om udfasning af modeller, der forklarer livscyklusstadierne Active, Legacy, Deprecated og Retired samt advarer om, at udfasede modeller sandsynligvis er mindre pålidelige end aktive modeller](https://crevio.co/vite/assets/claude-model-deprecations-gt44ujck.png)

[OpenAI's side om udfasninger](https://developers.openai.com/api/docs/deprecations) giver generelt tilgængelige modeller mindst seks måneders varsel, men preview-modeller "may be retired with much shorter notice, such as 2 weeks." I juni 2026 annoncerede virksomheden, at GPT-5- og o3-snapshots blev lukket den 11. december 2026. En backupmodel løser ikke en udfasning. Den skjuler den kun, indtil backupmodellens egen udfasningsdato indtræffer.

### Fejlen, ingen fallback fanger

Den dyreste fejl udløser aldrig en fejlmeddelelse. I 2025 offentliggjorde Anthropic [en postmortem om tre infrastrukturfejl](https://www.anthropic.com/engineering/a-postmortem-of-three-recent-issues), der forringede Claudes svar i ugevis. I den værste time var 16 % af Sonnet 4-forespørgslerne berørt af én af dem. En del af forklaringen på, at det tog så lang tid at finde problemet, var: "Claude often recovers well from isolated mistakes," hvilket skjulte problemet.

Ingen fallback-kæde aktiveres på grund af et dårligere svar, fordi et dårligere svar stadig returnerer en 200-status. Det er en opgave for [stikprøver af det, agenten producerer](/da/blog/human-in-the-loop-ai-agents), ikke for routing.

## Hvilke fejl bør udløse en backupmodel til en AI-agent?

Læs fejlen, før du reagerer på den. Det samme "modellen fejlede" kan betyde, at du skal vente fem sekunder, skifte med det samme eller rette din egen forespørgsel.

![Fem udbyderfejl og det rigtige svar på hver: vent og prøv igen ved en 429 med retry-after, skift til backupmodellen ved en 429 uden retry-after, prøv igen, skift host og skift derefter model ved 5xx-fejl eller timeouts, ret forespørgslen ved en 400, og gør erstatningsmodellen til primær model før en udfasningsdato](https://crevio.co/vite/assets/which-failures-need-a-backup-model-mvzdhotu.svg)

To rækker fortjener et nærmere kig:

- **5xx-, overbelastnings- og timeoutfejl.** Anthropics [fejlreference](https://platform.claude.com/docs/en/api/errors) angiver en 529 `overloaded_error` ved høj trafik på tværs af alle brugere, og deres SDK'er prøver allerede to gange igen ved midlertidige fejl med eksponentiel backoff. Ét ekstra retry er fint. Fem er sådan, et 30 sekunders problem bliver til et 10 minutters stop
- **400-fejl.** En forkert parameter eller en fejlformateret forespørgsel fejler også på backupmodellen, ofte af samme årsag. Undtagelsen er en prompt, der er for lang: Nogle routere sender den i stedet til en model med et større kontekstvindue, hvilket er en nyttig fallback

## Sådan fungerer fallback-kæder og routing

Du bygger sjældent selv fallback-logikken. Et routinglag mellem din agent og udbyderne gør det, og fire løsninger er almindelige:

| Værktøj | Sådan indstiller du backupmodellen | Hvad udløser den | Sådan ser du, hvilken model der svarede |
|---|---|---|---|
| **OpenRouter** | Et `models`-array i prioriteret rækkefølge | Nedetid, rate limits, fejl i kontekstlængde, moderationsflag | Feltet `model` i svaret |
| **LiteLLM** | `fallbacks` samt separate fallbacks for kontekstvindue og indholdspolitik | Rate limits og serverfejl med cooldowns efter gentagne fejl | Proxylogs og callbacks |
| **Vercel AI Gateway** | Et `models`-array kombineret med en provider `order` | Enhver fejl hos alle udbydere for en model | En `modelAttempts`-liste i udbydermetadataene |
| **Cloudflare AI Gateway** | En liste over trin på Universal-endpointet | Fejl og timeouts for forespørgsler | `cf-aig-step`-responseheaderen |

[OpenRouters modelfallbacks](https://openrouter.ai/docs/guides/routing/model-fallbacks) er de nemmeste at forestille sig: Du sender en liste med model-id'er, og "if the first model returns an error, OpenRouter will automatically try the next model in the list." Du bliver faktureret efter prisen på den model, der til sidst svarede. Separat håndterer deres [provider routing](https://openrouter.ai/docs/guides/routing/provider-selection) host-failover for den samme model. Som standard foretrækker den udbydere, der "have not seen significant outages in the last 30 seconds," og `allow_fallbacks` er aktiveret, medmindre du slår den fra.

![OpenRouter-dokumentationsside om Model Fallbacks, der forklarer, at parameteren models automatisk prøver andre modeller, hvis den primære models udbydere er nede, har rate limits eller nægter at svare](https://crevio.co/vite/assets/openrouter-model-fallbacks-docs-k3qy0sqx.png)

[LiteLLM's pålidelighedsindstillinger](https://docs.litellm.ai/docs/proxy/reliability) opdeler problemet mere detaljeret. Almindelige `fallbacks` håndterer rate limits og serverfejl, `context_window_fallbacks` sender en for stor prompt til en større model, og `content_policy_fallbacks` fanger fejl i indholdspolitikken. `allowed_fails` og `cooldown_time` tager en model med fejl ud af rotation i en periode, så en presset udbyder ikke bliver bombarderet ved hver forespørgsel.

[Vercel AI Gateways modelfallbacks](https://vercel.com/docs/ai-gateway/models-and-providers/model-fallbacks) kombinerer begge lag: Den prøver alle tilladte udbydere for den primære model, går derefter videre til den næste model i `models`-arrayet og registrerer hvert forsøg. [Cloudflare AI Gateways fallbacks](https://developers.cloudflare.com/ai-gateway/configuration/fallbacks/) fungerer på deres Universal-endpoint og fortæller via en header, hvor svaret kom fra: `cf-aig-step: 0` betyder, at den primære model svarede, mens `1` betyder, at den første fallback gjorde det.

Én advarsel gælder for alle fire. **Gatewayen er også en afhængighed.** Cloudflares eget netværk havde et større nedbrud [den 18. november 2025](https://blog.cloudflare.com/18-november-2025-outage/) fra kl. 11.20 til 17.06 UTC, efter at en forkert konfigurationsfil spredte sig i netværket. En fallback-kæde beskytter dig mod fejl hos en modeludbyder. Den kan ikke beskytte dig mod det lag, der kører kæden.

## Hvorfor en backupmodel til en AI-agent opfører sig anderledes

En fallback, der returnerer et svar, har ikke nødvendigvis løst opgaven. Agenter er mere skrøbelige end chatbots på dette punkt, fordi en agent befinder sig midt i en opgave i flere trin, når skiftet sker, og har en lang historik med tool calls, som den nye model skal overtage.

![Hvad der ændrer sig, når en agent skifter model: Skift til den samme model på en anden host bevarer promptadfærd, formatet for tool calls, parametre og kontekstvindue, mens en nyere model fra samme leverandør eller en model fra en anden leverandør ændrer det meste, og hvert skift mister den opvarmede prompt-cache](https://crevio.co/vite/assets/what-changes-when-an-agent-switches-models-nxjdqm6x.svg)

### Parametre, som én model accepterer, men en anden afviser

Det kan også ske hos den samme udbyder. Ifølge Anthropics [noter om udfasninger](https://platform.claude.com/docs/en/about-claude/model-deprecations) og [fejlreference](https://platform.claude.com/docs/en/api/errors):

- Hvis `temperature`, `top_p` eller `top_k` sættes til en værdi, der ikke er standardværdien, returneres en 400 på Claude Opus 4.7 og nyere
- Hvis et bestemt værktøj gennemtvinges med `tool_choice`, returneres en 400 på Claude Opus 5.5, Sonnet 5.5 og Fable 5.1
- Hvis begyndelsen på assistentens svar udfyldes på forhånd, returneres en 400 på Claude 4.6 og nyere modeller

En kæde, der skifter fra en ældre model til en nyere og "bedre" model, kan altså fejle øjeblikkeligt med en fejl, som den primære model aldrig genererede. [OpenRouters `require_parameters`-indstilling](https://openrouter.ai/docs/guides/routing/provider-selection) findes blandt andet af denne grund: Den router kun til udbydere, der understøtter alle de parametre, du har sendt.

### Tool calls og prompts

Forskellige udbydere forventer værktøjer, resultater og ræsonnementer i forskellige formater, så en fallback på tværs af udbydere afhænger af, at gatewayen oversætter samtalen korrekt. Selv når formatet overlever, var backupmodellen ikke den model, du finjusterede dine instruktioner til. Den kan kalde værktøjer i en anden rækkefølge, stoppe tidligere eller læse "vær kortfattet" som "spring kontrollen over". Nogle ræsonnementsdata overføres slet ikke: Anthropic bemærker, at en thinking-blok "from a model the target model can't read is dropped."

### Kontekstvinduer

Hvis backupmodellen kan læse mindre end den primære model, kan en lang agentkørsel være for stor til den, så snart den overtager. Derfor angiver OpenRouter fejl i kontekstlængden som en fallback-udløser, og LiteLLM giver dem deres egen fallback-liste. Sæt en backupmodel med mindst samme kontekstvindue som den primære model i kæden, eller få agenten til at komprimere ældre historik, før den skifter.

## Hvad koster fallbacks?

En backupmodel ændrer din regning på tre måder, og ingen af dem fremgår af en pristabel.

**Den opvarmede cache er væk.** Prompt-caching er en stor del af det, der holder agenter økonomisk overkommelige: Instruktioner, værktøjsdefinitioner og historik sendes igen ved hvert trin og faktureres for det meste til cacheprisen. Caches er knyttet til en bestemt model hos en bestemt udbyder, og derfor bruger OpenRouter [sticky routing](https://openrouter.ai/docs/guides/best-practices/prompt-caching) "to route your subsequent requests to the same provider endpoint after a cached request." Skift, og det næste trin koster fuld pris. Med [Claude Sonnet 5.5's listepris](https://platform.claude.com/docs/en/about-claude/pricing) på 2,00 $ pr. million inputtokens og 0,20 $ fra cache koster en agenthistorik på 50.000 tokens cirka 0,01 $ at sende igen fra cachen og cirka 0,10 $ uden den. Det er ti gange mere pr. trin, indtil backupmodellens egen cache er varmet op.

**Du betaler for den model, der svarede, i dens egne tokens.** OpenRouter fakturerer den model, der til sidst svarede, så en fallback til en dyrere model koster mere, og en billigere backupmodel, der har brug for flere trin for at afslutte, kan også koste mere. Tokenoptællinger kan heller ikke overføres direkte: Anthropics [prisside](https://platform.claude.com/docs/en/about-claude/pricing) bemærker, at deres Claude 4.7-modeller og nyere bruger en ny tokenizer, der genererer cirka 30 % flere tokens for den samme tekst.

**Retries koster også.** En forespørgsel, der fejler midt i en stream, har ofte allerede genereret tokens, der skal betales for, og hvert retry sender hele konteksten igen. Vi har gennemgået, hvordan det løber op, i [Driftsomkostninger for AI-agenter](/da/blog/ai-agent-running-costs): Mislykkede kørsler og loops udgør en hale, der kan overstige gennemsnittet.

Intet af dette taler imod backupmodeller. Det taler for at behandle dem som backupmodeller, mens retries og host-failover håndterer de daglige fejl, så det dyre skift kun sker ved reelle nedbrud.

## Test din fallback, før du får brug for den

De fleste fallback-kæder bliver først afprøvet under en hændelse, hvilket er det værst tænkelige tidspunkt at opdage, at backupmodellen ikke kan kalde dine værktøjer. En kort øvelse én gang i kvartalet og efter hver modelændring fanger det meste:

1. **Fremprovokér fejlen.** Peg den primære model på et model-id, der ikke findes, eller brug routerens testfunktion. LiteLLM tilbyder `mock_testing_fallbacks=True` i deres SDK og anbefaler at udløse en reel udbyderfejl i et ikke-produktionsmiljø for deres proxy
2. **Kør rigtige opgaver – ikke en hello-world-prompt.** Vælg tre eller fire af agentens faktiske opgaver, herunder en lang kørsel med mange værktøjer, og lad dem blive helt færdige på backupmodellen
3. **Sammenlign resultaterne.** Kaldte den de samme værktøjer, stoppede den samme sted, og fulgte den dine formateringsregler? Læs transskriptionerne, ikke kun det endelige svar
4. **Bekræft, hvilken model der svarede.** Kontrollér feltet `model` i svaret, `modelAttempts` eller `cf-aig-step`-headeren. En øvelse, hvor den primære model i stilhed svarede, beviser ingenting
5. **Opret alarmer for fallbacks.** En backup, der aktiveres hver dag, er ikke længere en backup. Den er din reelle model, uprøvet ved den belastning, og det vil du gerne vide
6. **Sæt udfasningsdatoer i kalenderen.** Kontrollér udfasningssiderne for både den primære model og backupmodellen, og skift til erstatningen i god tid før en af datoerne

Ved planlagte opgaver bør du kombinere dette med en plan for den kørsel, der alligevel fejler. Vores guide til [planlægning af tilbagevendende AI-agentopgaver](/da/blog/schedule-recurring-ai-agent-tasks) gennemgår, hvordan en god fejl ser ud: Et delvist resultat, en tydelig besked og en opgave, der stopper sig selv i stedet for at prøve igen for evigt.

## Sådan håndterer Crevios agent model-fejl

[Crevio](https://crevio.co/) er en AI-platform til at bygge virksomheder: Du beskriver, hvad du vil sælge, og agenten bygger, lancerer og driver arbejdet omkring det. Crevio vælger og kører modellerne bag agenten, så du ikke selv skal håndtere udbyderkonti, nøgler eller modelversioner. Her er, hvad der sker, når en model opfører sig forkert – beskrevet enkelt og også med, hvad systemet ikke gør.

**Det gør systemet i dag:**

- **Prøver automatisk den samme model igen.** Når et modelkald fejler på grund af overbelastning, en rate limit, en serverfejl, en timeout eller et svar, der afbrydes midt i en stream, prøver agenten igen op til tre gange og venter lidt længere hver gang (op til cirka 2, 4 og 8 sekunder). Fejl, som retries ikke kan løse, f.eks. en fejlformateret forespørgsel, bliver ikke prøvet igen
- **Undgår en host, der netop har fejlet.** For modeller, der kan leveres fra mere end én host, springer et retry efter en host-fejl den host over, der netop genererede fejlen
- **Komprimerer lange samtaler.** Hvis en samtale bliver længere, end modellen kan læse, opsummerer agenten den ældre historik og prøver én gang til i stedet for at stoppe
- **Kontrollerer modellisten ved hver udgivelse.** Hver gang Crevio udgiver en opdatering, bekræfter systemet, at alle modeller, agenten afhænger af, stadig tilbydes. Udgivelsen markeres som mislykket, hvis en model er forsvundet

![Crevios formular til en ny opgave for en daglig Morning sales summary med instruktioner om at angive, hvilken datakilde der ikke kunne nås, indstillet til at gentage hver dag og med Notify via sat til notifikation i appen og e-mail](https://crevio.co/vite/assets/crevio-task-failure-notifications-cq6okyoe.png)

**Det sker, når den stadig fejler:** En mislykket kørsel af en planlagt opgave rapporteres via de kanaler, der er angivet under indstillingen **Notify via**, sammen med oplysninger om, hvad den nåede at gøre, og hvad der gik galt. En tilbagevendende opgave slår som standard sig selv fra efter tre mislykkede kørsler i træk og fortæller dig det, så den ikke fejler ubemærket hver morgen. I en livechat stopper et svar, der har opbrugt sine retries, ganske enkelt, og du sender beskeden igen.

**Det gør systemet ikke endnu:** Crevios agent skifter ikke automatisk til en anden model midt i en opgave, når hovedmodellen er nede. I dag er beskyttelsen retries og host-failover på den samme model. Du kan heller ikke vælge agentens model eller tilslutte din egen udbydernøgle. Hvis du har brug for en håndtilpasset fallback-kæde på tværs af udbydere, giver et routingværktøj fra tabellen ovenfor, i din egen stack, dig den kontrol.

[Crevio](https://crevio.co/) kan startes gratis, og Starter-abonnementet inkluderer 20 AI-kreditter om måneden.

## Ofte stillede spørgsmål

### Har jeg brug for en backupmodel, hvis jeg allerede bruger en AI-gateway?

Gatewayen er stedet, hvor du konfigurerer backupmodellen – den er ikke selv en backup. Nogle gateways prøver automatisk igen eller skifter mellem hosts for den samme model, men et modelfallback sker kun, hvis du angiver en. Gatewayen tilføjer også selv en afhængighed, så undersøg, hvordan den håndterede tidligere hændelser.

### Bør en backupmodel til en AI-agent komme fra en anden udbyder?

Ved nedbrud: Ja. En backupmodel fra den samme udbyder går ofte ned under den samme hændelse. Ved rate limits kan en anden model fra den samme udbyder være nok, eftersom grænserne normalt sættes pr. model. Ulempen er kompatibiliteten: Jo længere backupmodellen er fra den primære model, jo mere skal du teste prompts, tool calls og parametre på den.

### Hvor ofte bør jeg teste min LLM-fallback?

Kør en øvelse efter hver ændring af den primære model, backupmodellen eller agentens instruktioner og værktøjer – og ellers mindst én gang i kvartalet. Kontrollér også begge modellers udfasningsdatoer hver gang, eftersom en backupmodel, der er udgået, fejler præcis, når du har brug for den.

## En backup, du aldrig har kørt, er et gæt

Nedbrud, rate limits og udfasninger er blevet rutine, og en god backupmodel til en AI-agent kan forvandle en manglende morgenrapport til en lidt langsommere rapport. Men værdien ligger i den rækkefølge, du bruger dem i: retry, derefter en anden host, derefter en anden model – og kun med en backupmodel, som du allerede har set færdiggøre rigtigt arbejde. Hvis du ikke har testet den, har du ingen fallback. Du har bare endnu en ting, der kan fejle.

## Relaterede blogindlæg

- [Driftsomkostninger for AI-agenter: Hvad koster én agent egentlig om måneden?](/da/blog/ai-agent-running-costs)
- [Sådan planlægger du tilbagevendende AI-agentopgaver, der kører uden dig](/da/blog/schedule-recurring-ai-agent-tasks)
- [AI-agenter med mennesket i løkken: Hvad skal godkendes, og hvad kan køre selv?](/da/blog/human-in-the-loop-ai-agents)
- [AI-agenter til virksomheder: Hvad skal du implementere først – afdeling for afdeling](/da/blog/ai-agents-for-business)