Forretning
Hva en konsulent leverer når agenter gjør arbeidet
En konsulent som lar agenter gjøre arbeidet, selger et utfall, ansvaret for at utfallet inntreffer og retten til å stoppe systemet. Timene måler arbeidet som er billigst å fjerne.
En konsulent som lar agenter gjøre arbeidet, selger ansvaret for et utfall og retten til å stoppe det. Timen er ikke lenger en god enhet, fordi timene måler arbeidet som er billigst å fjerne. Det kunden fortsatt må betale for, er hvem som svarer når systemet tar feil.
Apps AS har levert konsulentoppdrag siden 2008 og bygget egne produkter ved siden av. Denne artikkelen bygger på endringer vi har gjort i vår egen virksomhet, ikke på anslag om hva bransjen kommer til å gjøre.
Hva selger en konsulent når agenter gjør arbeidet?
En konsulent selger tre ting når agenter gjør arbeidet: et utfall som er definert på forhånd, et ansvar for at utfallet inntreffer, og en navngitt person som kan stoppe systemet. Ingen av de tre måles i timer.
Et utfall er et resultat kunden kjenner igjen uten å se inn i systemet: saken er lukket, fakturaen er kreditert, møtet er booket. En agent i produksjon er ikke et utfall. En rapport er det heller ikke.
Ansvar betyr at leverandøren betaler når utfallet uteblir. Er det ingen konsekvens for leverandøren, er ansvaret en formulering i et tilbud og ingen garanti.
Retten til å stoppe er den delen kunder oftest glemmer å kjøpe. Et agentisk system som ingen har myndighet til å slå av, er en risiko kunden har overtatt uten å få den priset.
Hva forsvant først i vårt eget fag?
Forprosjektet forsvant først. Kravinnsamling, brukerhistorier, funksjonell spesifikasjon og et estimat er den delen av konsulentarbeidet som er lettest å beskrive, og dermed den delen en agent gjør først.
Apps AS bygget Adviseful.ai for nettopp den jobben. Verktøyet tar en kunde fra idé til ferdig spesifisert appkonsept på minutter: AI-genererte konsepter, brukerhistorier, et sammendrag med estimat på utviklingstid og ressursbruk, og en PowerPoint kunden kan ta med videre.
To sider ved den beslutningen er verdt å legge merke til. Apps AS automatiserte sin egen fakturerbare fase, ikke kundens. Og Apps AS selger verktøyet videre til IT-konsulenter og digitale byråer, altså til selskaper som lever av den samme fasen.
Apps AS gjorde et beslektet grep én gang før, med AppCloud. Kunden sluttet å betale for skreddersøm og abonnerte i stedet på design, utvikling og drift til en fast månedspris. Prisen flyttet seg fra timer til leveranse før agentene kom.
Hva står igjen for mennesket?
Det som står igjen for mennesket, er beslutningene som ikke har et felt i noe skjema. Tre av dem har en plass i leveransen og en pris, og de er verdt å skrive inn i avtalen hver for seg.
- Før leveransen
Listen over handlinger som ikke skal automatiseres. Noen går gjennom hva systemet har lov til å gjøre selv, og hva som krever en godkjenning. Listen er kort, den er kjent på forhånd, og den er dyr å lage etterpå.
Listen bestemmer prisen. Kan handlingen rulles tilbake, kan leverandøren garantere et utfall, fordi feilen kan rettes. Kan handlingen ikke rulles tilbake, selger leverandøren en godkjenningsflate og et ansvar, og prisen bør si det. Koblingen mellom det tekniske valget og prislappen er gjennomgått i Arkitektur, design og pris er samme valg.
- Under leveransen
Vurderingen som ikke har et felt. Et agentisk system leverer arbeid som består alle maskinelle kontroller og likevel er feil av grunner ingen har laget et felt for. Noen må lese resultatet og kjenne igjen den feilen.
Publiseringsagenten på apps.no er vårt eget eksempel. Den 21. september 2026 leverte agenten to komplette artikkelutkast som bestod skjemavalideringen i CMS-et. Et menneske forkastet begge: det ene fordi belegget var andrehånds, det andre fordi tallene tilhørte et annet selskap enn bloggen tilhører. Ingen av de to grunnene har et felt. Hva det betyr for driften av agentiske systemer, står i Hva endrer seg når programvaren handler på egen hånd.
Den vurderingen er det konsulenten faktisk får betalt for, og den tar minutter. Prising per time straffer den som bruker fem minutter i stedet for fem timer på å ta den.
- Etter overleveringen
Eierskapet til prosessen. Når systemet kjører videre uten leverandøren, må én navngitt person hos kunden eie måltallet og ha myndighet til å stoppe. Uten det navnet er overleveringen en avslutning av oppdraget.
Hvem som eier prosessen etter automatisering, er den samme problemstillingen sett fra virksomhetens side, og den står i Personalisering er en driftsoppgave, ikke en kampanje.
Hva kan vi love, og hva kan vi ikke love?
Vi kan love et utfall der handlingen kan rulles tilbake, og vi kan love en responstid på å rette den. Vi kan ikke love at et agentisk system aldri tar feil. Et tilbud som lover det, er skrevet av noen som ikke har hatt et slikt system i drift.
Bemanningen endrer seg deretter. Et team som leverer utfall trenger færre som produserer førsteutkast og flere som kan avgjøre om et utkast holder. Den kompetansen er vanskeligere å ansette enn kompetansen den erstatter, fordi den forutsetter at personen har gjort arbeidet selv lenge nok til å kjenne igjen når det er feil.
Kravene til logg og sporbarhet peker samme vei. Loggen er både feilsøkingen og dokumentasjonen en offentlig innkjøper kommer til å be om, og hvorfor den kommer uavhengig av norsk regelverk, står i Agentisk AI i et land uten KI-lov.
Skriv ned hva dere tar ansvar for
Skal dere selge et agentisk system til en kunde i år, skriv ned tre linjer før tilbudet går ut: utfallet dere garanterer, handlingene dere ikke automatiserer, og navnet på den hos kunden som kan stoppe systemet. Send de tre linjene til hello@apps.no. Vi svarer med hvilken av dem vi ville priset høyest, og hvilken vi ville strøket.
Kilder
Om denne artikkelen. Skrevet av Kjell Rune Monsø, medgrunnlegger og partner i Apps. Ankerartikkel for pilaren Fremtidens konsulenter. Opplysningene om Adviseful.ai og AppCloud er hentet fra Apps AS' egne produktsider, lest 24. september 2026. Eksempelet med publiseringsagenten bygger på kjøringene 21. september 2026. Hvor mange konsulentvirksomheter som bruker Adviseful.ai, står ikke på produktsiden og er ikke anslått her. Artikkelen bruker ingen kundetall.
FAQ
- Hvordan priser vi et utfall når vi ikke vet hvor mange saker som kommer?
- Sett en pris per utfall og et tak på antall i perioden, slik at volumrisikoen deles. Kunden betaler for det som faktisk ble levert, og dere er beskyttet mot en topp dere ikke har kapasitet til. Første periode bør være kort nok til at begge parter kan justere prisen når det reelle volumet er kjent, gjerne tre måneder.
- Hva gjør vi med de ansatte som i dag fakturerer på forprosjekt?
- De fleste av dem kan gjøre den vurderingen verktøyet ikke gjør, altså avgjøre om et utkast holder og hva som mangler. Overgangen er reell og ubehagelig, fordi den samme personen leverer færre fakturerbare timer og mer verdi per time. Det er en prismodelljobb før det er en bemanningsjobb, og selskaper som tar den i motsatt rekkefølge mister folk de trengte.
- Kan vi ta betalt for å drifte et system vi ikke har bygget selv?
- Ja, og det er ofte enklere å selge enn å bygge det. Forutsetningen er at dere har tilgang til loggen og myndighet til å stoppe systemet. Uten begge deler tar dere ansvar for noe dere ikke kan påvirke, og da er prisen for lav uansett hva den er.
- Hvor stort må ansvaret være før kunden tror på det?
- Stort nok til at det merkes i regnskapet deres, og lite nok til at ett dårlig kvartal ikke velter selskapet. I praksis lander mange på å sette en andel av honoraret i spill per periode. Det avgjørende er ikke størrelsen, men at konsekvensen er skrevet ned og at kunden slipper å forhandle om den når den inntreffer.
- Hva skjer med prisen hvis kunden selv kjøper modellen?
- Prisen på modellen faller mot null, og det er ikke der marginen ligger uansett. Dere selger integrasjonen mot kundens egne systemer, listen over handlinger som ikke skal automatiseres, og ansvaret for utfallet. Ingen av de tre følger med når kunden kjøper tilgang til en modell.
