Slik bygde jeg 7 AI-agenter uten å kunne kode: Metoden, verktøyene og feilene

Dette er del 2 av 4 i serien “7 agenter på 7 dager”. I del 1 beskrev jeg hva jeg bygde og hva det faktisk endret i hverdagen min. Her går jeg inn på hvordan. Ikke hvordan i teorien, men hvordan i praksis med de feilene, frustrasjonene og overraskelsene som dukket opp. En liten reise i det å bygge AI-agenter uten koding.

Hvorfor OpenClaw?

Jeg hadde ikke hørt om OpenClaw før jeg så det nevnt i en YouTube-video av en ikke-utvikler som hadde bygd en komplett arbeidsflyt. Det som fanget meg var ikke teknologien i seg selv, men premisset: et åpent kildekode-rammeverk designet for å la AI-modeller faktisk gjøre ting, ikke bare svare på spørsmål.

De fleste AI-verktøy jeg hadde prøvd var konversasjonelle. Du spør, du får svar, du gjør jobben selv. OpenClaw er bygd rundt en annen ide: at modellen skal kunne ta instruksjoner, bruke verktøy, koble til tjenester og fullføre oppgaver autonomt.

For meg som ikke er utvikler var det avgjørende at OpenClaw har ett grensesnitt jeg allerede brukte: Telegram. Ingen egne apper. Ingen dashboards å lære seg. Bare en melding, og systemet gjør jobben.

Det er ikke det eneste rammeverket som kan dette. Men det var det som passet min arbeidsflyt.

Arbeidsmetoden: Én agent om gangen

Den største feilen man kan gjøre er å prøve å designe hele systemet på forhånd.

Jeg vet dette fordi jeg prøvde det. Den første dagen brukte jeg to timer på å tegne opp arkitektur og tenke på hvordan de syv agentene skulle snakke sammen. Det var bortkastet tid. Ikke fordi planlegging er feil, men fordi jeg ikke visste nok til å planlegge godt ennå.

Det som faktisk fungerte var å stille ett spørsmål: Hva er den ene oppgaven jeg gjør manuelt i dag som kan kjøres på autopilot?

Svaret ble dag 1. Så stilte jeg spørsmålet igjen. Det ble dag 2. Og slik fortsatte det.

Denne tilnærmingen har tre fordeler som ikke er åpenbare med det første. For det første er det lettere å feilsøke noe enkelt enn noe komplekst. For det andre gir hver agent du fullfører energi til å fortsette. Og for det tredje tvinger det deg til å faktisk bruke det du bygger — og oppdage hva som mangler — før du bygger videre.

Claude som sparringspartner

Jeg er ikke utvikler. Men jeg vet hvordan jeg tenker rundt problemer, og jeg vet hva jeg vil at et system skal gjøre. Det viste seg å være nok.

Gjennom hele prosessen brukte jeg Claude som en kombinasjon av teknisk rådgiver, kodeassistent og debugger. Ikke ved å gi presise tekniske instruksjoner — jeg hadde ikke det vokabularet — men ved å beskrive problemet i vanlig språk.

“Jeg vil ha en bot som leser Gmail, finner e-postene som krever svar i dag, og sender meg en liste i Telegram sortert etter viktighet. Hvordan gjør jeg det?”

Derfra tok samtalen over. Claude foreslo tilnærming, forklarte avveininger, og leverte kode jeg kunne teste. Når noe ikke fungerte — og det skjedde ofte — beskrev jeg feilen, og vi løste den sammen.

Det som overrasket meg mest var ikke at Claude kunne kode. Det var at den kunne forklare på en måte som faktisk ga mening for meg. Jeg forstår ikke Python. Men jeg begynte å forstå hva koden gjorde — og det gjorde meg i stand til å stille bedre spørsmål.

Claude Code i praksis

Claude Code er et verktøy fra Anthropic som lar deg jobbe med kode direkte i terminalen — med Claude som aktiv samarbeidspartner, ikke bare et tekstvindu du copy-paster fra.

I praksis betydde det at jeg kunne åpne en fil på serveren, beskrive hva jeg ville endre, og få endringen gjort uten å forlate terminalen. Ingen manuell copy-paste. Ingen risiko for å miste kontekst mellom et chatvindu og en editor.

For Investor Bot — den mest komplekse bygget i hele serien — var Claude Code avgjørende. Jeg skulle ikke bare skrive et script. Jeg skulle bygge en fullverdig web-applikasjon med innlogging, søkefunksjonalitet og en ryddig brukerflate. Det er et annet ambisjonsnivå.

Med Claude Code kunne jeg iterere raskt: endre, teste, justere, teste igjen. Feilmeldinger ble forklart i kontekst. Løsninger ble implementert der og da. Det føltes mindre som å lære programmering og mer som å ha en utvikler sittende ved siden av meg.

Git Bash og VPS — hva du faktisk trenger?

La meg være ærlig om den tekniske terskelen, for den er reell, men den er lavere enn du tror.

VPS står for Virtual Private Server. Tenk på det som en datamaskin som alltid er på, alltid er koblet til internett, og alltid kjører agentene dine — uten at du trenger å ha egen laptop åpen. Jeg bruker Hostinger, som koster noen hundre kroner i måneden. Det er nok.

Git Bash er terminalen jeg bruker på Windows for å kommunisere med serveren. Du skriver kommandoer, serveren gjør ting. Det høres mer skremmende ut enn det er. De kommandoene jeg faktisk bruker til daglig er omtrent åtte stykker og Claude lærte meg disse.

Det du ikke trenger er en dyp forståelse av Linux, nettverk eller serverarkitektur. Du trenger nok til å komme deg inn på serveren, kopiere filer og starte agenter. Det tok meg én dag å lære.

Test, feil, juster er den virkelige prosessen

Ingen av agentene fungerte perfekt første gang. Jeg sier det eksplisitt fordi det er lett å lese en slik artikkel og tro at det gikk smidig.

Det gikk ikke smidig.

Gmail-integrasjonen krevde tre forsøk før autentiseringen fungerte. Triage-agenten kategoriserte feil de første dagene fordi prompten var for vag. Investor Bot hadde en periode der den returnerte tomme rapporter uten feilmelding. Egentlig det verste scenarioet, fordi du ikke vet hva som er galt.

Prosessen var alltid den samme: kjør, se hva som skjer, forstå hvorfor det gikk galt, prøve fikse det. Claude var med gjennom alle stegene. Ikke som en orakel som alltid hadde svaret, men som en samtalepartner som hjalp meg tenke gjennom problemet. Her brukte jeg også ChatGTP som samtalepartner når ting stoppet litt opp.

Det som overrasket meg var ikke at det tok tid. Det var at hver feil lærte meg noe som gjorde neste agent enklere å bygge.

Verktøyene bak systemet

Infrastruktur

• VPS Server — der alt kjører, 24/7
• OpenClaw — rammeverket som binder agentene sammen og håndterer kommunikasjon med Telegram og AI-modeller
• Systemd — holder agentene i live og starter dem automatisk ved restart
• GitHub — versjonskontroll; reddet meg flere ganger da noe gikk galt
• Git Bash — terminalen jeg bruker på Windows for å kommunisere med serveren
• Termius — når jeg skulle jobbe i terminal på mobilen (seng, sofa og T-banen)

Kommunikasjon og grensesnitt

• Telegram Bot API — brukergrensesnittet mot hele systemet
• Python — språket alle agentene er skrevet i

Integrasjoner

• Google Calendar API — agenda-agenten
• Gmail API — triage og digest
• LinkedIn — varsler inn i triage-agenten via Gmail
• Google Sheets — prospects-oversikt

AI

• Claude (Anthropic) — sparringspartner og kodeassistent gjennom hele prosessen
• Claude Code — brukt til å skrive og deployere Investor Bot direkte i terminalen
• GPT-4o — brukt i e-postskriving-funksjonen
• Brave Search API — gir agentene tilgang til nett-søk i sanntid

Hva dette egentlig krever av deg?

Null kodekunnskap, eller teknisk bakgrunn men…

Det krever evnen til å beskrive et problem klart. Tålmodighet til å iterere når noe ikke fungerer. Og vilje til å akseptere at du ikke trenger å forstå alt. Du trenger bare å forstå nok til å komme videre!

Det er en annen type kompetanse enn den vi vanligvis snakker om når vi snakker om AI. Men det er den som faktisk avgjør om du får noe ut av det.

Del 3 av 4 kommer snart: Investor Bot — fra idé til intern web-app. Den mest ambisiøse bygget i serien — en fullverdig applikasjon med innlogging som hele teamet bruker. Hvordan ble det til, hva koster det å drifte, og hva ville jeg gjort annerledes?

Klikk her hvis du gikk glipp av del 1. Bygger du AI-agenter uten koding? Kommentere gjerne og knytt kontakt.