AI-agentutveckling som håller i produktion

AI-agentutveckling är att bygga programvara där en språkmodell avgör vilket steg som ska tas, anropar riktiga verktyg för att ta det, läser resultatet och beslutar igen — tills ett mål nås eller en gräns stoppar den. Produkten är inte modellen, utan loopen runt den. Det är där ingenjörsarbetet finns: vad agenten får anropa, hur fel kommer tillbaka till den, hur tillstånd bärs mellan steg, vad som händer när den kommer ur kurs och hur du efteråt vet om jobbet blev gjort. En chattbot svarar. En agent handlar — och det handlandet gör det till ett mjukvaruprojekt i stället för en prompt.

En fungerande prototyp för en smal uppgift tar oftast en till tre veckor. Att få prototypen till ett läge du skulle visa kunder tar betydligt längre — vanligen två till fyra månader — och nästan inget av den tiden går till prompter. Den går till integrationer som fallerar på sätt modellen måste hantera, till en utvärderingsmängd som fångar regressioner, till behörigheter, till loggar man kan felsöka ur, och till överlämningen till människa för de fall agenten inte bör avgöra ensam. Team som budgeterar demon men inte andra fasen är de vars agent aldrig lämnar piloten.

Börja med det lättaste som löser uppgiften. För en ensam agent med en handfull verktyg är modellleverantörens SDK plus en loop du skrivit själv ofta hela jobbet — och du kan felsöka varje steg. Gå till ett orkestreringsramverk när du verkligen behöver varaktigt tillstånd, förgrenat kontrollflöde, omförsök över långa steg eller flera samordnade agenter. Priset för ett ramverk är inte API:et, utan att just de delar du behöver granska en dålig dag ligger inne i någon annans abstraktion. Vad du än väljer: håll prompter, verktygsdefinitioner och utvärderingsmängd utanför ramverket, så blir ett byte en dags arbete och inte en omskrivning.

Det finns två kostnader och team planerar regelbundet för fel. Byggkostnad: en smal intern agent landar typiskt på 8 000–30 000 $ i ingenjörsarbete; en kundvänd agent med riktiga integrationer, utvärdering och övervakning oftare på 30 000–120 000 $. Driftkostnad: tokenutgiften är vanligen den mindre posten och lättast att sänka — dirigera enkla steg till en billigare modell, cacha och beskär kontexten så halveras den ofta. Posten som glöms är underhåll: modeller avvecklas, API:er ändras, utvärderingsmängden måste köras om. Räkna med ungefär 15–25 % av byggkostnaden per år.

Genom att begränsa vad den kan göra i stället för att hoppas att den sköter sig. I praktiken: förankra svar i hämtade dokument och låt agenten citera källan; ge verktyg strikta, typade argument och validera dem före körning; låt ett verktyg returnera ett ärligt ”hittades inte” och lär agenten att inget resultat är ett godtagbart utfall; sätt tak för antal steg och kostnad per körning; och lägg ett mänskligt godkännande framför allt oåterkalleligt — betalningar, raderingar, utgående meddelanden till kunder. Mät sedan. En utvärderingsmängd med femtio verkliga fall, även de obekväma, säger mer om tillförlitlighet än någon promptjustering.

Använd en no-code-plattform när uppgiften är standard, volymen måttlig och kostnaden för ett fel svar låg — intern FAQ-dirigering, triage av förfrågningar, utkast till första svar. De tar dig verkligen snabbare till ett resultat och lär dig vad uppgiften faktiskt kräver. Bygg eget när agenten ska röra era system med riktiga rättigheter, när latens eller styckkostnad spelar roll vid er volym, när ni behöver egen utvärdering och revisionsspår, eller när agenten ingår i produkten ni säljer. Den vanliga vägen är förnuftig: bevisa flödet på en plattform och bygg sedan om de delar som förtjänat det.