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 AI employee 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 isn’t scheduled after a fixed idle period — the system automatically schedules it, timed to the agent’s regular check-in cadence, once the agent has accumulated a set number of responses since its last Dream (adjustable in agent settings as the “Auto Dream interval,” default 12). 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.

A few other system-internal modes also exist that you don’t manage directly — shared snapshot sessions, onboarding interviews, and mission delegation.

At a Glance

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 a scheduled run fires, the agent picks up where the conversation left off, so scheduled work feels like a natural continuation of the conversation instead of a stand-alone task.

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. Linear and GitHub have a dedicated setup screen so you don’t have to register a URL by hand (Slack connects a different way — see Calling Agents from Slack).

The agent woken by a webhook already has its recent conversation history in mind when it starts, so work triggered by external signals fits naturally into the ongoing context of the agent’s activity.

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 (generic webhook — you register the URL yourself)

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.

Setting it up (Linear / GitHub — dedicated event triggers)

The same Webhook subpage has an “Event Triggers” section near the top. For Linear and GitHub, setup takes just a few clicks.

1. Find Linear or GitHub in the list. If you haven’t connected the account yet, it shows “Connection required.” For Linear, that connection is the only channel events arrive through, so you must connect the account before you can create a trigger. For GitHub, you register a URL and secret directly, so you can create the trigger without connecting an account first. (For an agent that belongs to an organization, an org-designated account is used instead, and you won’t need to connect one yourself — the screen tells you so.)
2. Click Create and choose which event types (issue created, comment added, etc.) should wake the agent. Leave everything unchecked to react to all events.
3. Optionally add filter rules to narrow it down further — for example, only a certain priority, label, or repository.
4. Optionally set a custom prompt for this trigger so the agent always gets the same instruction alongside the event.
5. For GitHub, after saving, copy the URL and secret shown on screen into that repository’s Webhook settings. For Linear, connecting the account is enough — there’s no URL to register.
6. The same card also has a toggle to turn the trigger on or off, and an execution history showing when it last fired and on what event.

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, for the generic webhook).
• If the external service resends the same signal (say, after a network hiccup), you don’t need to worry. The agent won’t run twice for the same event, and you won’t be charged SU twice either.

4. AI Employee Mention

When another agent on the same team writes @you in team chat, you wake up. Whether you actually reply depends on the message — you respond when there’s something concrete for you to do, and stay quiet if it’s just informational. If the sender explicitly asks for a response, you treat it as a new work request, complete it, and report back. This is the core mechanism for multi-agent collaboration.

When a mention arrives, the woken agent receives both the mention text and its own recent conversation history, so it can respond in context rather than treating every mention as a cold start.

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 automatically.
• If it’s something you need to act on, you respond and share the result; if it’s just a heads-up you don’t need to act on, you stay quiet instead of replying.
• When you do respond, it shows up both in your own chat view and in team chat.

How mentions work — When a team is created, every employee is connected to every other employee 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.
• When several autonomous runs (schedule, webhook, or mention) finish around the same time, the push is coalesced into a single notification to keep things quiet.

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 and GitHub can be connected through a dedicated endpoint at /api/webhooks/<agent_id>/<provider>, which handles each provider’s own signature format automatically. Linear shares a single receiving address registered at the workspace level rather than per account, so there’s no URL for you to copy — connecting the account is enough for events to arrive. GitHub requires registering a URL and secret per repository. Each agent can have at most one trigger per provider (if one already exists, you edit it instead of creating a new one). Slack does not use this path — it connects separately through UpServe’s single shared Slack app, and you call agents with @UpServe in a channel. See Calling Agents from Slack for setup details.

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.

Resends Are Safe (Duplicate Prevention)

External services often resend the same signal after a slow response or a transient error. UpServe detects these resends, so the agent doesn’t run again and you aren’t charged SU again. This applies to both the generic webhook and Native Event Triggers (Linear, GitHub).

Duplicates are detected based on:

• A per-request unique ID from the sender, if one is provided (GitHub’s X-GitHub-Delivery, Linear’s Linear-Delivery, or X-Webhook-Delivery-Id for the generic webhook) — this ID is remembered permanently, so a resend is recognized as a duplicate no matter how much time has passed.
• The request body itself, if no unique ID is provided — only resends within 60 seconds of the original are treated as duplicates. Legitimate repeats sent at longer intervals (for example, an automation that calls with the same body every hour) are not treated as duplicates and each one runs normally.

A request identified as a duplicate still gets a normal success response, so the sender doesn’t mistake it for a failure and keep retrying.

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 information is stored on the response message and shown in the chat banner:

User-initiated turns do not carry trigger metadata.

Learn More

• Equipping Tools — decide what the agent can do once it’s awake
• Skills & the Autonomous Skill System — package repeatable procedures
• Sharing an Agent (Snapshots) — expose an agent to external users