Ampersend: pay-per-intelligence med Bedrock

De fleste agent-opsætninger i dag kører på en fast model, valgt én gang ved opsætningen og aldrig genovervejet. Det er simpelt, men det er også dyrt, fordi en opgave, der kunne løses af en billig, hurtig model, ofte sendes til den samme dyre model som en kompleks analyse. Ampersends routing-lag ændrer den logik: hver forespørgsel bliver vurderet for kompleksitet, før den sendes videre, og agenten vælger dynamisk mellem flere modeller efter, hvad opgaven faktisk kræver. En simpel klassificering går til en billig model, en flertrinsanalyse går til en kraftigere, og prisen følger med, ikke omvendt.

Det, der gør arkitekturen interessant rent teknisk, er selve betalingsmønstret i AgentCore Payments. Det fungerer i to hop: først en autorisation, der reserverer det maksimale beløb, en given forespørgsel kan koste, og derefter en afregning, når svaret rent faktisk er leveret og token-forbruget er kendt. Det betyder, at systemet aldrig behøver at gætte på prisen på forhånd. Det sætter et loft, lader modellen arbejde, og afregner præcis det, der blev brugt. For virksomheder, der har prøvet at estimere AI-omkostninger ud fra gennemsnit og bagefter fået en regning, der ikke stemte, er den forskel ikke kosmetisk.

Den autonome del af routingen er det, der adskiller Ampersends tilgang fra almindelig lastbalancering mellem modeller. Systemet forsøger ikke bare at fordele trafik jævnt, det forsøger at finde det billigste svar, der stadig er godt nok til opgaven. Det kræver en vurdering af, hvad opgaven kræver af ræsonnement, kontekstlængde og præcision, og den vurdering foretages løbende, forespørgsel for forespørgsel, ikke én gang i en konfigurationsfil. I praksis betyder det, at en virksomhed med tusindvis af daglige agent-kald kan se en markant lavere gennemsnitspris per kald, uden at nogen manuelt har siddet og omfordelt trafikken.

Det, der gør arkitekturen brugbar i en virksomhedskontekst, er de konfigurérbare udgiftsbudgetter, der ligger oven på routingen. Man kan sætte et loft per agent, per afdeling eller per opgavetype, og systemet håndhæver det i selve autorisationstrinnet, før pengene bruges, ikke efter. Det er en anden model end den klassiske "tjek forbruget i en dashboard bagefter"-tilgang, som de fleste AI-platforme stadig bygger på. Her er budgettet en aktiv del af beslutningen om, hvilken model der overhovedet får lov at svare på en given forespørgsel.

Jeg har set det samme mønster hos en global virksomhed, jeg har bygget agentinfrastruktur til: betaling, routing og budgetstyring bliver klistret på, efter agenten allerede kører. Det virker fint i starten, men regningen fanger en ikke i modelvalget, den fanger en i alle de steder, hvor ingen satte et loft. At lægge det lag ind fra starten, som Ampersends arkitektur lægger op til, kræver, at man tænker kompleksitetsvurdering og prisstyring ind i selve agent-designet, ikke som et tillæg bagefter. Det er en investering i arkitektur, der betaler sig tilbage, når volumen stiger, men den skal planlægges, før agenten sættes i produktion, ikke efter.

For virksomheder, der allerede har AI-agenter kørende, eller er ved at skalere fra pilot til drift, peger den her type arkitektur på et skifte i, hvordan man bør tænke på AI-omkostninger. I stedet for en fast licensudgift eller en flad pris per bruger bevæger markedet sig mod finkornet, forbrugsbaseret prissætning, hvor hver eneste agent-beslutning har en pris og en øvre grænse. Det giver bedre kontrol, men det stiller også nye krav til, hvordan man overvåger og governer sine agenter internt. Virksomheder, der vil undgå, at agent-omkostninger vokser ukontrolleret, bør begynde at stille de samme spørgsmål til deres egen AI-drift: hvem sætter budgetterne, hvem godkender modelvalget, og hvor i arkitekturen bliver den beslutning faktisk håndhævet.