AI-gründer som bygger en autonom virksomhet, deler hvordan man bygger agentiske arbeidsflyter for prosjektleveranser og kundestøtte
Amos Bar Joseph er en seriegründer som lærte av sine tidligere feil med tradisjonell prosjektledelse, GTM-strategier og forretningsmodeller. Som et resultat av dette blir hans nyeste virksomhet, Swan AI, fullt autonom. Det betyr at AI vil håndtere prosjektene — og omtrent alt annet.
Amos Bar Joseph
Administrerende direktør i Swanai
Fra planlegging til beslutningshastighet: Tradisjonell prosjektledelse legger stor vekt på planlegging, dokumentasjon og koordinering. Amos viser at gjennomføringen blir billig og rask i en AI-først-virksomhet, så den virkelige flaskehalsen er hvor raskt du gjenkjenner mønstre og tar beslutninger.
Autonome arbeidsflyter: Swan AI fjernet statusmøter, lange prosjektplaner, godkjenningskjeder og kvartalsvise gjennomganger — og erstattet dem med asynkrone oppdateringer, tydelige mål for resultater, klare beslutningsrettigheter og automatiserte tilbakemeldingssignaler. Denne endringen reduserte koordineringstiden fra 60 % til 10 %, slik at teamet kunne bruke mesteparten av tiden på faktisk arbeid, ikke på å snakke om arbeid.
Menneskelige roller må defineres: Menneskelige roller må defineres før man automatiserer med AI, fordi implementeringer mislykkes ikke på grunn av AIs begrensninger, men fordi teamene aldri avklarer hva mennesker skal eie. Amos forklarer at AI bør håndtere oppgaver med lav innvirkning og lav kompleksitet fullt ut, bistå på områder der kompleksiteten eller risikoen er høyere, og overlate beslutninger med stor innvirkning og høy kompleksitet til mennesker.
Vi satte oss ned med Amos for å forstå hva dette betyr i praksis. Her er det han hadde å si.
Slik forvandler en autonom forretningsmodell prosjektleveransen
Jeg er medgründer og administrerende direktør i Swan AI, en plattform for GTM-automatisering som integreres på tvers av kommunikasjonskanaler (e-post, Slack osv.), CRM-systemer og B2B-datakilder for å håndtere GTM-arbeidsflyter. Vi bruker den internt til prosjektleveranser og kundehåndtering.
Vi bygger den første autonome virksomheten, med et mål om å nå $10M ARR per ansatt med et lite team og en hær av AI-agenter. Den autonome virksomheten vår er utviklet for samarbeid mellom mennesker og AI, ikke koordinering mellom mennesker, og kan skaleres med intelligens – ikke antall ansatte.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Denne begrensningen ble til et utilsiktet laboratorium for prosjektleveranser. Når du ikke kan ansette deg ut av problemer, blir enhver prosjektbeslutning eksistensiell: Vil dette tidoble resultatene våre, eller er det bare aktivitet som føles som fremgang?
Dette brutale filteret avdekket mønstre jeg ikke kunne se da jeg hadde råd til å sette flere folk på problemer i de to tidligere oppstartsbedriftene mine, som jeg grunnla og skalerte basert på den gamle vekst-for-enhver-pris-modellen. Nå, etter å ha sett over 200 selskaper implementere AI gjennom Swans produkt, kan jeg oppdage feilmønstrene umiddelbart.
Hvorfor AI flytter prosjektleveranser fra planlegging til mønstergjenkjenning og beslutningshastighet
Den mest dramatiske endringen er hvordan jeg fordeler tiden min – og den er nesten omvendt av tradisjonell prosjektledelse. Jeg bruker svært lite tid på oppgavene som tidligere krevde oppmerksomheten min, som innledende planlegging, statusmøter og dokumentasjon som ingen leser. Mer om det om et øyeblikk.
Dette er det som får oppmerksomheten min nå:
- 60 % går til mønstergjenkjenning og beslutningstaking: Jeg analyserer i sanntid hva som fungerer på tvers av de over 200 implementeringene våre. Ikke månedlige gjennomganger – daglig identifisering av mønstre. Hvilke implementeringer gir stadig bedre resultater, og hvilke stagnerer? Hvor oppstår flaskehalsene faktisk, sammenlignet med hvor vi forventet at de skulle oppstå? Det handler om å ta raske beslutninger om hva som skal avsluttes, og hva vi skal satse dobbelt så mye på, og det kan du ikke gjøre ut fra en kvartalsvis virksomhetsgjennomgang. For å gjøre dette har vi et Retool-dashbord for kundehelse, og vi viser varsler i Slack. Jeg bruker også Metabase, der vi har mer detaljert produktanalyse for hver kunde.
- 30 % går til å utforme tilbakemeldingssløyfer: Hvordan vet vi innen 48 timer om en AI-implementering fungerer? Hvilke signaler forteller oss at vi bør endre kurs eller holde fast? Jeg bygger «systemer for å oppdage brudd» – måter å oppdage når AI avviker fra manus eller en arbeidsflyt ikke leverer, før det blir en krise. For å gjøre dette er det viktig å lage en tydelig plan som starter med små trinn som er enkle å måle. Tradisjonelle prosjektledere planla for suksess; jeg utformer systemer som avdekker feil umiddelbart, slik at vi kan rette dem mens de fortsatt er små.
- 10 % går til selve «prosjektlanseringen»: Dette var tidligere høydepunktet etter flere måneders planlegging. Nå er det bare tirsdag. Vi leverer stadig v1-versjoner og ser på lanseringen som begynnelsen på læringen, ikke slutten på planleggingen. Lansering er ikke lenger suksess – det er tillatelse til å begynne å få reelle tilbakemeldinger.
I en AI-først-verden er gjennomføring billig og rask. Flaskehalsen er beslutningshastighet. Rollen min har gått fra «å lage den perfekte planen» til «å ta raske beslutninger basert på reelle tilbakemeldinger». Derfor bruker jeg 90 % av tiden min på læringssystemer, ikke gjennomføringssystemer.
I en AI-først-verden er gjennomføring billig og rask. Flaskehalsen er beslutningshastighet.
Slik eliminerer du koordineringskostnaden i prosjektleveranser
Overgangen vår fra tradisjonell til lettvekts-prosjektledelse var ikke en endring av metodikk, men innebar å fjerne bestemte ritualer som bremset oss. Her er det som forsvant, og hva som erstattet det:
Statusmøter (40 % av kalenderen) → Asynkrone oppdateringer (nå 5 % av tiden)
- Fjernet: Ukentlige prosjektstatusmøter med presentasjoner
- Erstattet med: Korte Slack-oppdateringer når noe endres, ikke etter en fast plan
- Hvorfor det fungerer: Informasjonen flyter når den er viktig, ikke når kalenderen sier det
- Resultat: Hver grunnlegger fikk tilbake over 15 timer i uken
Detaljerte prosjektplaner (2–4 uker på forhånd) → Definisjoner av resultater (2–4 timer)
- Fjernet: Omfattende kravdokumentasjon, arbeidsflytkart og risikomatriser
- Erstattet med: Det tydelige resultatet vi ønsker, og det første eksperimentet som skal kjøres
- Hvorfor det fungerer: Planer blir umiddelbart utdaterte; resultater forblir relevante
- Resultat: Første versjoner levert på dager, ikke måneder
Godkjenningskjeder → Tydelige beslutningsrettigheter
- Fjernet: «Ta dette opp med ledelsen» for små beslutninger
- Erstattet med: Definerte terskler — under $X eller Y i påvirkning, er det bare å sette i gang
- Hvorfor det fungerer: Fart er viktigere enn å forhindre små feil
- Resultat: Tiden fra beslutning til handling falt fra dager til timer
Kvartalsvise gjennomganger → Daglige tilbakemeldingssignaler
- Fjernet: Planlagte møter for å «se hvordan dette prosjektet går»
- Erstattet med: Automatiserte måltall som varsler oss når noe er galt
- Hvorfor det fungerer: Oppdag problemer på dag 2, ikke måned 3
- Resultat: Problemer løses før de blir kriser
Vi gikk fra å bruke 60 % av tiden på å koordinere arbeid til å bruke 90 % av tiden på å utføre arbeid. Ikke fordi vi er mer disiplinerte, men fordi vi fjernet koordineringskostnaden som tradisjonell prosjektstyring skaper.
Hvordan AI endrer leveranseritualer ved å kreve mer kontekst
Tradisjonell tenkning antar at AI betyr mindre menneskelig kommunikasjon. Vår virkelighet er det motsatte: AI i teamet betyr at vi kommuniserer mer eksplisitt, fordi AI trenger kontekst for å være nyttig.
Dette er spesielt relevant for oss fordi vi bruker vårt eget produkt til å fjerne «kontekstkostnaden» — det vil si at det integreres på tvers av kommunikasjonskanalene våre for å samle inn og hente frem kontekst. Det lytter.
Dette har stor innvirkning på ritualene våre. Kundeprosjekter er et godt eksempel. Når en kunde rapporterer et problem eller ber om noe, kommuniserer grunnleggerne våre med vilje mer utførlig enn det som er nødvendig for hverandre — fordi vi vet at AI fanger det opp.
Slik ser det ut i praksis:
I stedet for: «Kunde X ønsker funksjon Y, la oss diskutere det i morgen»
Skriver vi: «Kunde X ba om funksjon Y. Kontekst: De får kapasitetsproblemer ved 200 potensielle kunder/dag, teamet deres på 3 SDR-er er overbelastet, og denne funksjonen vil gjøre det mulig for dem å håndtere 500/dag uten å ansette. Dette samsvarer med vår ICP for SMB-skalering. Haster: høyt — de vurderer konkurrenter denne uken.»
Senere, når hvem som helst i teamet — inkludert AI — samhandler med denne kunden, har vi tilgang til relevant kontekst.
Ja, dette tar 2–3 ekstra minutter per kommunikasjon. Men det sparer timer på:
- Samordningsmøter — AI holder alle oppdatert
- Innhenting av kontekst — AI kjenner allerede situasjonen
- Overleveringer — AI opprettholder kontekst på tvers av samhandlinger
Når du behandler AI som et teammedlem som trenger å holdes informert, endres kommunikasjons- og dokumentasjonsritualene dine grunnleggende — og det er da AI blir virkelig nyttig, ikke bare en funksjon.
Hvorfor det er avgjørende å definere menneskers roller først for å lykkes med AI-implementering
Mislykkede AI-implementeringer skjer nesten aldri fordi AI ikke er kapabel nok. De mislykkes fordi teamene aldri besvarte et mer grunnleggende spørsmål: «Hva skal mennesker faktisk ha eierskap til i denne arbeidsflyten?»
Her er mønsteret jeg stadig ser på tvers av våre mer enn 200 implementeringer:
Team bruker uker på å spørre «Kan AI håndtere denne oppgaven?» De kartlegger den nåværende prosessen, identifiserer hva AI kan automatisere, bygger systemet og lanserer det. AI fungerer. Den kan utføre 70–80 % av oppgaven pålitelig.
Så faller det fra hverandre. Ikke fordi AI slutter å fungere, men fordi ingen definerte hva mennesker skulle gjøre med de resterende 20–30 %. Da skjer én av to ting:
- Mennesker detaljstyrer alt. De stoler ikke på AI, så de gjennomgår hver eneste beslutning, og gjør i praksis en AI-implementering til $20K om til et dyrt forslagsverktøy. Teamet blir utbrent av å kontrollere AI-ens lekser.
- Mennesker frasier seg eierskapet fullstendig. De antar at «AI håndterer det» og slutter å følge med. Så går noe galt eller avviker fra planen, og ingen legger merke til det før det blir en kundekrise.
Dette skyldes at vi gikk baklengs frem i implementeringen av AI. Vi spurte «Hva kan vi automatisere?» i stedet for «Hvor er menneskelig dømmekraft uerstattelig, og hvordan bygger vi AI som forsterker denne dømmekraften?»
Start i stedet hvert AI-prosjekt med å definere den menneskelige rollen først. Hvilke beslutninger krever intuisjon? Hvor er kontekst avgjørende? Hvilke feilmåter krever menneskelig tilsyn? Bygg deretter AI for å håndtere alt annet og vise de riktige signalene til riktig tid, slik at mennesker kan ta beslutninger.
Det høres opplagt ut i ettertid. Men når du er begeistret for AIs muligheter, er det utrolig lett å hoppe over dette trinnet og fokusere utelukkende på hva AI kan gjøre – i stedet for å utforme samarbeidet mellom mennesker og AI på forhånd.
Et praktisk rammeverk for å avgjøre hva AI bør automatisere
Jeg vurderer automatiseringsbeslutninger langs to dimensjoner: konsekvensene av feil og hvor kompleks dømmekraft som kreves. Dette skaper fire tydelige kategorier, som jeg skal gå gjennom om litt.
Etter hvert som kompleksiteten eller konsekvensene øker, endres AIs rolle fra «eier» til «assistent». Men du må definere hvilken rolle AI skal ha for hver arbeidsflyt på forhånd – ikke etter lansering, når mennesker ikke vet om de skal stole på eller overstyre AIs beslutninger.
Rammeverket handler ikke om hva AI kan gjøre teknisk. Det handler om hva AI bør ha ansvar for, basert på risikoprofilen og dømmekraften som kreves.
Lav konsekvens + lav kompleksitet = full automatisering
Eksempel 1: Databerikelse og undersøkelser
- AI henter selskapsinformasjon, teknologistakk og sosiale profiler
- Hvis den gjør noe feil, oppdager mennesker det under gjennomgangen
- Ingen dømmekraft kreves – bare innsamling av data
- Implementering: API-integrasjoner, AI strukturerer resultatet, mennesker foretar en rask stikkprøvekontroll
Eksempel 2: Innledende poengsetting og ruting av potensielle kunder
- AI scorer mot definerte ICP-kriterier og ruter til riktig arbeidsflyt
- Feilruting er tydelig og enkelt å korrigere
- Logikken kan kodes (selskapsstørrelse, bransje, atferdssignaler)
- Implementering: Regelbasert scoring kombinert med AI-scoring, mennesker gjennomgår spesialtilfeller
Lav konsekvens + høy kompleksitet = AI-forberedelse, menneskelig beslutning
Eksempel: Svar til kundestøttehenvendelser
- AI utarbeider svar basert på lignende tidligere saker
- Det er komplekst fordi tone, kontekst og spesialtilfeller har betydning
- Men konsekvensen er lav hvis vi gjennomgår svaret før det sendes
- Implementering: AI utarbeider utkast, mennesker gjennomgår og redigerer, og vi lærer av redigeringene
Høy konsekvens + lav kompleksitet = automatisering med sikkerhetsnett
Eksempel: Utsending av utgående meldinger
- Konsekvensen er høy fordi merkevaren eller markedet kan ta skade hvis det gjøres dårlig
- Men det er relativt lite komplekst – og kvaliteten kan måles
- Implementering: AI genererer, strenge godkjenningsprosesser og automatiske nødstopp ved resultatsvikt
Høy konsekvens + høy kompleksitet = menneskestyrt
Eksempel: Strategiske prosjektomlegginger
- Å avgjøre om man skal avslutte eller satse ytterligere på en implementering
- Krever mønstergjenkjenning på tvers av flere kontekster
- En feil beslutning er kostbar på grunn av bortkastede ressurser eller tapte muligheter
- Implementering: AI synliggjør signaler (nedgang i bruk, mønstre i tilbakemeldinger), og et menneske tar beslutningen
Eksempel: Komplekse kundeforhandlinger
- Prisdiskusjoner, samtaler om utvidelse og risikoer knyttet til fornyelse
- Krever forståelse av relasjonsdynamikk, politisk kontekst og uutalte bekymringer
- Feil beslutning skader tillit som er vanskelig å gjenoppbygge
- Implementering: AI utfører undersøkelser og forberedelser, mens mennesket har ansvaret for samtalen
Slik gjorde agentiske arbeidsflyter det mulig å bygge et selvlærende støttesystem på 13 timer
Her er et eksempel på kompleksitet vi har navigert i ved hjelp av agentiske arbeidsflyter i arbeidet med å bygge en automatisert virksomhet.
Begrensningen: Å bygge mot 10 millioner dollar i ARR per ansatt med bare tre grunnleggere betydde at vi ikke kunne ansette oss ut av problemene. Da antallet supportsaker nådde over 200 i uken, var den tradisjonelle løsningen – å ansette 2 CSM-er – ikke tilgjengelig for oss. Hver sak krevde en grunnleggers fulle oppmerksomhet – å undersøke svaret, formulere responsen og dokumentere den et sted. Vi druknet.
V1 (uke 1): Svar på kjente spørsmål
Vi startet med det absolutte minimumet: en AI-agent i Slack som kunne svare på rundt 20 spørsmål vi allerede hadde dokumentert i Notion.
- Verktøy: Swan AI, Slack, Notion
- Oppsett: 6 timer
- Resultat: 15 % av supportsakene ble håndtert
- Nytt problem: Kundene ble frustrerte over å få svar som «jeg vet ikke». Vi besvarte fortsatt 85 % manuelt.
V2 (uke 2): Eskaler ukjente spørsmål
Vi la til en eskaleringsvei: AI-en blir værende i kundetråden, men varsler oss internt når den ikke vet noe. Vi svarer, og AI-en leverer svaret vårt.
- Oppsett: 3 timer
- Resultat: 35 % selvstendig problemløsning
- Nytt problem: Vi la merke til at vi svarte på de samme nye spørsmålene om og om igjen. Hver eskalering lærte ikke AI-en noe – det var bare et rutingssystem.
V3 (uke 4): Lær av eskaleringer
Vi bygde læringssløyfen. Nå fanger AI-en automatisk opp spørsmål og svar når vi svarer på et eskalert spørsmål, strukturerer dem og legger dem til i kunnskapsbasen.
- Oppsett: 4 timer
- Resultat: 70 % selvstendig problemløsning innen 2 uker
Hvorfor dette fungerte: Hver versjon tok under 6 timer å bygge fordi vi ikke planla for perfeksjon – vi reagerte på konkrete tilbakemeldinger. Evnen til «selvlæring» var ikke en del av den opprinnelige planen. Den oppsto naturlig da vi spurte: «Hvorfor svarer vi på de samme spørsmålene to ganger?»
Nå besvarer vi over 200 supportsaker i uken, 70 % av dem håndteres selvstendig, og kunnskapsbasen vår vokser organisk ut fra reelle kundespørsmål.
Så her er mitt råd: Lever minimumet som løser det umiddelbare problemet. Følg med på hvor det bryter sammen. Legg til minimumsfunksjonen som løser dette bruddet. Gjenta. Vi kom frem til et sofistikert selvlærende system uten noen gang å planlegge det på forhånd.
Lever minimumet som løser det umiddelbare problemet. Følg med på hvor det bryter sammen. Legg til minimumsfunksjonen som løser dette bruddet. Gjenta.
Andre områder som egner seg godt for agentiske arbeidsflyter
Vi bruker også agentiske arbeidsflyter innen:
- Onboarding: Ny kunde → Swan veileder gjennom oppsettet på en samtalebasert måte, stiller ICP-spørsmål og konfigurerer arbeidsflyter basert på svarene
- Kundesuksess: Overvåker bruksmønstre → identifiserer muligheter for utvidelse eller risikoer → presenterer dem for grunnleggerne med anbefalinger
Hvorfor tilbakemeldingssløyfer er viktigere enn valg av AI-verktøy, og hvordan du bygger dem
Alle spør: «Hvilket AI-verktøy bør vi bruke?» Feil spørsmål.
Det mest verdifulle som sparer oss for tid, er ikke et verktøy – det er at vi vet innen 48 timer når noe går galt.
Vi bygger inn tilbakemeldingssløyfer i alle implementeringer. Vi følger med på:
- Eskaleringsmønstre: Når AI-en sender saken videre til mennesker, viser det at den trenger hjelp
- Overstyringsgrad: Når mennesker endrer AI-resultater, viser det at vurderingsevnen var svak.
- Resultatmålinger: Bestilte møter, løste supportsaker og så videre – ikke bare aktivitet.
- Utløsere for feil: Automatiske varsler når ytelsen synker.
Uten tilbakemeldingssløyfer lanserer du AI og håper at det fungerer. Innen du innser at det ikke gjør det – vanligvis gjennom klager eller kvartalsgjennomganger – har du kastet bort flere måneder.
Med tilbakemeldingssløyfer oppdager du problemer på dager og løser dem mens de fortsatt er små.
Vi har sett reell effekt:
- Support-AI: Fra 35 % til 70 % selvstendig håndtering på 2 uker ved å se hvilke spørsmål som trengte bedre svar
- Kvalifiserings-AI: 40 % bedre treffsikkerhet på 30 dager ved å følge med på menneskelige overstyringer
Valget av AI-verktøy betyr langt mindre enn evnen din til å oppdage hva som er ødelagt og iterere raskt. «Verktøyet» som sparer mest tid, er systemet som forteller deg hva som må fikses før det blir en krise.
En AI-basert teknologistakk som driver autonom prosjektleveranse
Når det er sagt, har jeg noen faste favoritter:
- Claude-prosjekter (AI-produktivitetsverktøy): Jeg oppretter og videreutvikler alle prosjektrelaterte dokumenter i et Claude-prosjekt. På denne måten bygger konteksten til KI-en seg opp, og den blir smartere for hver samtale.
- Shortwave (AI-kommunikasjonsverktøy): Det er en ny AI-basert e-postklient med en AI-agent som hjelper meg med å finne den riktige konteksten fra alt rotet i innboksen. Den hjelper meg også med å skrive gode e-poster og holde interessenter oppdatert uten å måtte bytte kontekst eller drukne i søk etter tidligere tråder.
- N8N (programvare for automatisering av AI-arbeidsflyter): Jeg bruker dette til å bygge AI-agenter som er koblet til Retool og Metabase, slik at vi kan få prosjektoppdateringer direkte i Slack.
Hvorfor prosjektledelse utvikler seg til styring av utviklingstempo
KI i prosjektledelse vil utvikle seg fra avgrenset prosjektleveranse til styring av utviklingstempo med kontinuerlig tilpasning.
Jeg tror at KI vil gjøre det så raskt å bygge og endre ting at prosjekter med en definert start og slutt blir utdatert. Innen et prosjekt på tre måneder er ferdig, har kravene endret seg, KI-funksjonene har utviklet seg, og den «ferdige» løsningen er allerede utdatert.
Det som vil erstatte dette, er sykluser med kontinuerlig forbedring og raske tilbakemeldingssløyfer. I stedet for «lanser kundeportalen i tredje kvartal» blir det «utvikle kundeinteraksjonene kontinuerlig og levere endringer daglig basert på reelle tilbakemeldinger».
«Tempoledere» vil optimalisere for:
- Hastighet fra tilbakemelding til løsning — ikke leveringsdatoer
- Iterasjonsfrekvens — ikke prosjektgjennomføring
- Læringstempo — ikke omfangsstyring
Suksess vil defineres av hvor raskt du oppdager problemer og leverer løsninger, ikke av om du når forhåndsdefinerte milepæler.
Prosjektlederne som overlever, bygger allerede opp denne ferdigheten — de leverer uperfekte versjon 1-er, videreutvikler basert på reell bruk og optimaliserer for hastighet fremfor perfeksjon. De som fortsatt perfeksjonerer Gantt-diagrammene sine, vil ikke kjenne igjen jobben om fem år.
Hvorfor iterasjonshastighet slår planlegging — og hvordan ledere kan levere raskere med KI
Her er mitt råd: Bygg for høy iterasjonshastighet, ikke perfekt implementering.
Slutt med: Planlegging over flere uker, perfekte lanseringer og å unngå alle feil.
Begynn med: Lever minimale, nyttige versjoner på noen dager, bygg tilbakemeldingssløyfer først og lær av raske iterasjoner.
Og gjør det praktisk: Kutt planleggingsfasen i det neste prosjektet ditt med 75 %. Lever noe uperfekt denne uken som lærer deg hva som faktisk betyr noe. Mål suksess etter hvor raskt du går fra «det gikk galt» til «her er versjon 2».
Læringshastighet slår planleggingens dybde hver gang.
Læringshastighet slår planleggingens dybde hver gang.
Følg med
Du kan følge Amos' arbeid med å automatisere GTM-arbeidsflyter på LinkedIn og i Swan-nyhetsbrevet. Du kan også se nærmere på Swan og Autonamos, Amos' digitale klon.
Det kommer flere ekspertintervjuer hos The Digital Project Manager!
