Skip to Content
AgentsHow Agents Wake Up

How Agents Wake Up

An UpServe agent isn’t a chatbot that only replies when you type into it. It can also wake itself up at a scheduled time, on an incoming signal from another service, or when another agent calls its name.

The four triggers that you directly control are user message, schedule, external signal (webhook), and teammate mention. This page walks through each one — when to use it, how the result reaches you, and whether you’ll be notified.

Beyond these, agents have two additional autonomous activation modes: Dreams and Quiet Moments. A Dream is automatically scheduled by the system after the agent has been idle for at least 1 hour — the agent uses that time to consolidate memories and proactively plan next steps. A Quiet Moment is a low-key wake that lets the agent catch up on unanswered messages or tasks it hasn’t started yet. Both are managed entirely by the system; no configuration is needed. Other system-internal modes (shared snapshot sessions, onboarding interviews, mission delegation) also exist.

At a Glance

TriggerWho starts it?When is it a good fit?Where does the result land?Push notifications?
User messageYou, by typing in the chatWhen you need an answer right nowInline in the chat viewYou’ll see it on screen
ScheduleThe clock (a time you set)Daily briefings, weekly reports, periodic checksAuto-appended to the chat viewMobile push (if enabled)
External signal (webhook)An external service or your own serverZapier / n8n / GitHub / your backend handing work to the agentChat view + optionally posted back to an external URLMobile push (if enabled)
Teammate mentionAnother agent on the same teamMulti-agent collaboration, handing off work between specialistsTeam chat + your own chat viewMobile push (if enabled)

1. User Message

The most basic case. You open the agent’s chat view, type a message, and the agent wakes up to respond immediately.

When to use

  • You want an answer right now
  • You’re working on something interactively and want a back-and-forth

Where the result lands

  • Streamed live into the chat view.
  • If the agent used tools (web search, code execution, image generation, etc.), each step expands as a card inside the message.

2. Schedule

The agent wakes itself up at a time you set and runs on its own. Daily morning briefings, weekly cleanups, one-off reminders an hour from now — anything time-based fits here.

When to use

  • Recurring jobs (daily news summary, weekly report)
  • One-off delayed runs (“check this again in 30 minutes”)

Where the result lands

  • At the scheduled time, the agent runs on its own and the result is appended to your chat view as a new message.
  • The message carries a small “Scheduled” label.
  • If you’ve turned on push notifications, your phone gets one too.

Learn more — see Scheduling for how to create and manage schedules.

3. External Signal (Webhook)

An external service can wake your agent up by sending it a signal. Zapier, n8n, GitHub, Linear, Slack, or a server you operate — anything that can make an HTTP request can hand work off to the agent. For integrations like Linear, GitHub, and Slack, dedicated provider-specific endpoints are also available.

When to use

  • You want an external event (form submission, new issue, alert) to start agent work
  • You want the agent as the final step of another automation flow

Setting it up

  1. Open the agent detail page → Webhook subpage (/agents/<agent_id>/webhook).
  2. Click Enable webhook. A dedicated URL and a secret key are generated.
  3. Configure your external service to send messages to that URL. You must include a signature made with the secret key — requests without a valid signature are rejected.
  4. Use the Test area on the same page to dry-run a call before wiring up the real source.

Where the result lands

  • The agent wakes up as soon as the signal arrives and gets to work.
  • The result is appended to the chat view automatically.
  • You can also register callback URLs that POST the result back to an external service (up to 5 per agent).

4. Teammate Mention

When another agent on the same team writes @you in team chat, you wake up and treat the message as a work request. This is the core mechanism for multi-agent collaboration.

When to use

  • A single agent is taking on too many roles
  • You want a pipeline of specialists — research → write → review — handing work to each other

Where the result lands

  • An “@you …” message in team chat wakes you up; the mention becomes your incoming work item.
  • Your reply shows up both in your own chat view and in team chat.

How mentions work — When a team is created, every member is connected to every other member by default, so anyone can mention anyone and wake them up immediately. This full mesh is set up automatically when the team is formed. If you want to restrict who can wake whom, you can remove individual connections from the team graph view (/agents/team/<team_id>/graph). Once a connection in a given direction is removed, a mention sent that way is still recorded in team chat as text, but the recipient is not instantly woken — they’ll see the message the next time they finish their own work and check team chat.

How the Chat Shows Non-User Triggers

When the agent is woken by a schedule, a webhook, or a mention — anything that isn’t a message you typed — the resulting reply carries a small badge at the top:

  • Schedule — labeled “Triggered by schedule,” showing the prompt stored on that schedule
  • Webhook — labeled “Triggered by webhook,” showing the prompt that arrived in the signal
  • Mention — labeled “Mention from @sender,” showing the message body from the sender

The badge makes it obvious, when you scroll back later, that the agent acted on its own rather than because you asked.

Where to Manage Notifications

If you want to be alerted to autonomous runs even when the chat view isn’t open, enable mobile push.

  • Settings → Notifications lets you toggle each type.
  • If several autonomous runs finish around the same time, the push is coalesced into a single notification to keep things quiet.

When an autonomous trigger (schedule, webhook, or mention) causes the agent to send you a message, that message is delivered through a separate channel from a normal chat reply and is bundled into a single push notification per turn.


Advanced

This section isn’t required for normal use. Read on only if you’re integrating with external systems or want to fine-tune security.

Webhook URL and Signature

  • Endpoint: https://api.upserve.app/api/webhooks/<agent_id>
  • Authentication: the X-Webhook-Signature header is required. Set it to HMAC-SHA256(secret, body) as a hex string. Missing or invalid signatures return 401. The secret is shown once on activation; regenerating it immediately invalidates the previous one.
  • Body: JSON. If a prompt field is present, its string is handed to the agent as if it were a user message. Otherwise the entire JSON object is passed through.
  • Body size limit: 64KB.
  • Rate limits: per-IP per-minute limits apply, and you can set per-minute / per-hour limits per agent under Webhook → Rate limit.
  • Native Event Trigger: Linear, GitHub, and Slack integrations also have a dedicated endpoint at /api/webhooks/<agent_id>/<provider> that handles each provider’s own signature format automatically.

Signature example (curl + openssl)

SECRET="the secret you received on activation" URL="https://api.upserve.app/api/webhooks/<agent_id>" PAYLOAD='{"prompt":"Check server status"}' SIG=$(printf '%s' "$PAYLOAD" | openssl dgst -sha256 -hmac "$SECRET" | cut -d' ' -f2) curl -X POST "$URL" \ -H "Content-Type: application/json" \ -H "X-Webhook-Signature: $SIG" \ -d "$PAYLOAD"

The Test area in the Webhook subpage generates an equivalent curl command for you — start there when wiring up a new sender.

Security recommendations

  • Never expose the secret. If you suspect leakage, regenerate it from the Webhook subpage; the old one stops working immediately.
  • Restrict source IPs on the sender side if possible.
  • Prefer HTTPS for callback URLs so credentials aren’t sent in the clear. Any custom headers you attach to a callback are masked when displayed.

Response-Required Mentions

When one agent mentions another, the sender can mark the mention as response required. In that case the woken agent is guided to:

  1. Register the incoming mention as a new task.
  2. After finishing the work, mention the original sender back with the result.

This only applies when the mention travels along an active connection — if the connection in that direction has been removed, the mention is recorded in team chat but the recipient isn’t woken up immediately, so the response-required guidance won’t reach them right away either.

Thread-reply exception — even if a connection has been removed in a given direction, sending a thread reply (with in_reply_to set and @OriginalSender in the message) will still wake the original sender. This is a deliberate safeguard so replies to work requests are never silently dropped by a pruned edge.

Chain limits — mention chains stop automatically after 3 hops. A single message can wake at most 3 agents at a time, and a short cooldown applies between repeated mentions of the same (sender → recipient) pair.

The Trigger Badge in Chat

For webhook, schedule, and mention runs, the trigger info is attached to the response message and shown as a small banner above it when you reopen the chat:

  • Schedule: shows the prompt stored on the schedule that fired it (the schedule’s own name and cadence live on the Schedules subpage).
  • Webhook: shows the prompt extracted from the incoming signal (the prompt field of the body, if any).
  • Mention: shows the sender’s name and the mention text.

User-initiated turns don’t show this banner.

Trigger Metadata Fields

When an autonomous trigger fires, the following fields are stored on the response message and shown in the chat banner:

TriggerStored fields
Scheduleschedule_id (schedule identifier), prompt (the instruction saved on the schedule), cron_expression (recurrence pattern)
Webhookprompt (the prompt field from the request body, or the synthesized prompt if absent)
Mentionmentioner_name (sending agent’s name), mentioner_agent_id, mention_id, content (mention text)

User-initiated turns do not carry trigger metadata.

Learn More