A URL that wakes your agent

Our agents already schedule their own work. A calendar event fires, the agent wakes, does the job, and only speaks up if something is worth your attention. That covers everything you can predict: the Monday status report, the daily check on a flaky supplier feed. But the work that actually interrupts your day is rarely on a schedule. A pull request doesn't open on a cron expression.

So agents can now mint external triggers: calendar events with no schedule at all, just a URL. Send an HTTP POST to that URL and the agent wakes and runs the instruction saved on the event. That is the whole interface. If a system can call a URL, it can put your agent to work.

curl -X POST https://squidler.io/gateway/triggers/calendar/<your-trigger-token>

You can ask your agent for one in chat ("set up a trigger for reviewing new pull requests") and it hands you the URL with the exact snippet for your pipeline, or you create one yourself from the External triggers card on the desk. The card appears once a trigger exists; it is where you copy URLs, pause a trigger, or revoke it by removing the event.

Three places to point it

An n8n workflow. Put an HTTP Request node at the end of any n8n flow. A new lead lands in the CRM, n8n does its usual routing, and the final node wakes your agent, whose instruction is to research the company and have a short briefing waiting before anyone picks up the phone.

A Zap. Same shape in Zapier or Make: finish with a Webhooks POST step. A form response arrives, the Zap files it where it belongs, and the agent reads the new entries and flags the ones that need a human today rather than this week.

A GitHub Action. The workflow below wakes the agent every time a pull request opens or gets new commits. The agent's standing instruction: check for new or updated PRs, review the changes, report what it finds.

on:
  pull_request:
    types: [opened, synchronize]
jobs:
  wake-agent:
    runs-on: ubuntu-latest
    steps:
      - run: curl -X POST ${{ secrets.AGENT_TRIGGER_URL }}

Store the URL as a repository secret: anyone who has it can fire the trigger.

None of these are integrations we built. They are all just POST, which is the point: the long tail of tools that can call a URL is much longer than any integration catalog. An uptime monitor can call it the moment your site goes down, and the agent goes and looks at the actual site rather than telling you a probe failed. Calendly can call it when a meeting lands, and the agent has a brief on the attendee ready before the call. The request itself carries nothing; the agent acts on the instruction you saved and looks up whatever else it needs, so the instruction should say where to look ("check for new or updated pull requests"), and the agent fetches the rest itself.

Guardrails

Whatever a caller sends along with the request never reaches the agent. That is a security measure, not a gap: the URL works like a key, and keys get copied into config files, chat threads, and screen shares. Someone who finds it can start the task you wrote, nothing more. They cannot slip data or instructions into your agent's head, so a leaked URL is a nuisance, not a way in.

Each fire is normal agent work and spends from your normal quota, so there is a ceiling on how often a trigger can fire: 10 times a minute, 30 an hour, 120 a day. Calls beyond that are turned away rather than saved for later, so a runaway caller loses calls instead of burning through a day of quota in an hour.

The agent also keeps count. If something calls the same trigger nine times in an hour, the agent is told exactly that when it wakes, and its job is to flag it: fix whatever is stuck, or pause the trigger, both one click away, rather than dutifully working through every duplicate.

Pausing keeps the URL but stops the fires, so a paused trigger can resume without anyone touching their setup. Removing the trigger is what kills the URL for good; a new trigger gets a fresh one.

What to say to your agent

External triggers are live for every agent today, and the way in is one chat message. Brief it like a colleague: say when the trigger will fire and what you want done.

The same shape works for anything your agent can check on its own: a deploy watcher ("when this fires, fetch our status page and tell me if anything looks off") or a code reviewer ("review pull requests that are new or updated since your last run and message me the highlights"). Brief it, get the URL, paste it into your pipeline.

The instruction can change any time from the External triggers card on the desk, and the URL stays the same, so the Zap or workflow calling it never has to. From there, your agent is one POST away from anything.