En URL, der vækker din agent
31. juli 2026 · 4 min læsning
Agenter vågner, når du skriver til dem, eller når deres kalender siger, at det er tid. Nu kan alt, der kan sende en HTTP POST, også vække dem: et n8n-workflow, en Zap, en GitHub Action.

Vores agenter planlægger allerede deres eget arbejde. En kalenderbegivenhed går i gang, agenten vågner, gør arbejdet og siger kun noget, hvis der er noget, der fortjener din opmærksomhed. Det dækker alt, hvad du kan forudse: statusrapporten om mandagen, det daglige tjek af en ustabil leverandørfeed. Men det arbejde, der faktisk afbryder din dag, følger sjældent en tidsplan. En pull request bliver ikke åbnet efter et cron-udtryk.
Så agenter kan nu oprette eksterne triggere: kalenderbegivenheder helt uden tidsplan, bare en URL. Send en HTTP POST til den URL, så vågner agenten og udfører den instruktion, der er gemt på begivenheden. Det er hele grænsefladen. Hvis et system kan kalde en URL, kan det sætte din agent i gang.
curl -X POST https://squidler.io/gateway/triggers/calendar/<your-trigger-token>
Du kan bede din agent om en i chatten ("sæt en trigger op til at gennemgå nye pull requests"), så giver den dig URL'en med det præcise kodestykke til din pipeline, eller du kan selv oprette en fra kortet Eksterne triggere på skrivebordet. Kortet dukker op, når der findes en trigger; det er dér, du kopierer URL'er, sætter en trigger på pause eller tilbagekalder den ved at fjerne begivenheden.
Tre steder at pege den hen
Et n8n-workflow. Sæt en HTTP Request-node i slutningen af et hvilket som helst n8n-flow. Et nyt lead lander i CRM'et, n8n gør sin sædvanlige fordeling, og den sidste node vækker din agent, hvis instruktion er at researche virksomheden og have en kort briefing klar, før nogen tager telefonen.
En Zap. Samme form i Zapier eller Make: Afslut med et Webhooks POST-trin. Et formularsvar kommer ind, Zap'en arkiverer det, hvor det hører hjemme, og agenten læser de nye svar og markerer dem, der kræver et menneske i dag frem for i denne uge.
En GitHub Action. Workflowet nedenfor vækker agenten, hver gang en pull request bliver åbnet eller får nye commits. Agentens faste instruktion: Tjek for nye eller opdaterede PR'er, gennemgå ændringerne, og rapportér, hvad den finder.
on:
pull_request:
types: [opened, synchronize]
jobs:
wake-agent:
runs-on: ubuntu-latest
steps:
- run: curl -X POST ${{ secrets.AGENT_TRIGGER_URL }}
Gem URL'en som et repository-secret: Alle, der har den, kan udløse triggeren.
Ingen af disse er integrationer, vi har bygget. De er alle bare POST, og det er netop pointen: Den lange hale af værktøjer, der kan kalde en URL, er meget længere end noget integrationskatalog. En oppetidsmonitor kan kalde den, i samme øjeblik dit site går ned, og agenten går ind og kigger på det faktiske site i stedet for at fortælle dig, at en probe fejlede. Calendly kan kalde den, når et møde bliver booket, og agenten har en briefing om deltageren klar før opkaldet. Selve anmodningen bærer ingenting; agenten handler ud fra den instruktion, du har gemt, og slår selv det andet op, den har brug for, så instruktionen bør sige, hvor den skal kigge ("tjek for nye eller opdaterede pull requests"), og agenten henter selv resten.
Sikkerhedsrækværk
Det, en afsender sender med anmodningen, når aldrig frem til agenten. Det er en sikkerhedsforanstaltning, ikke et hul: URL'en fungerer som en nøgle, og nøgler bliver kopieret ind i konfigurationsfiler, chattråde og skærmdelinger. En, der finder den, kan starte den opgave, du har skrevet, intet andet. De kan ikke smugle data eller instruktioner ind i din agents hoved, så en lækket URL er til gene, ikke en vej ind.
Hver udløsning er almindeligt agentarbejde og trækker på din almindelige kvote, så der er et loft over, hvor ofte en trigger kan udløses: 10 gange i minuttet, 30 i timen, 120 om dagen. Kald ud over det bliver afvist i stedet for at blive gemt til senere, så en afsender, der er løbet løbsk, mister kald i stedet for at brænde en hel dags kvote af på en time.
Agenten holder også tal på det. Hvis noget kalder den samme trigger ni gange på en time, får agenten præcis det at vide, når den vågner, og dens opgave er at gøre opmærksom på det: få rettet det, der hænger, eller sætte triggeren på pause, begge dele ét klik væk, i stedet for pligtskyldigt at arbejde sig igennem hver eneste dublet.
En pause beholder URL'en, men stopper udløsningerne, så en trigger på pause kan genoptages, uden at nogen behøver røre deres opsætning. At fjerne triggeren er det, der slår URL'en ihjel for altid; en ny trigger får en ny.
Hvad du skal sige til din agent
Eksterne triggere er live for alle agenter i dag, og vejen ind er én chatbesked. Brief den som en kollega: Sig, hvornår triggeren vil blive udløst, og hvad du vil have gjort.
Den samme form virker til alt, din agent kan tjekke på egen hånd: en deploy-vagt ("når den her udløses, så hent vores statusside og sig til, hvis noget ser forkert ud") eller en kodegennemgang ("gennemgå pull requests, der er nye eller opdaterede siden din sidste kørsel, og send mig højdepunkterne"). Brief den, få URL'en, sæt den ind i din pipeline.
Instruktionen kan ændres når som helst fra kortet Eksterne triggere på skrivebordet, og URL'en forbliver den samme, så den Zap eller det workflow, der kalder den, aldrig behøver at blive ændret. Derfra er din agent én POST fra hvad som helst.