How AI Employees Wake Up

An UpServe AI employee 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, when another employee calls its name, or even when a single email arrives.

The five ways to start an employee that you directly control are user message, scheduled run, external signal (webhook), AI employee mention, and email. This page walks through each one: when to use it, how the result reaches you, and whether you’ll be notified.

Beyond these, employees have two additional automatic modes: auto memory cleanup and Quiet Moments. Auto memory cleanup doesn’t run at a fixed time. Once the employee has responded to a set number of requests from people or teammate employees, or completed scheduled runs, since its last cleanup, the system starts one automatically at a quiet moment (adjustable in the employee’s settings under Auto memory cleanup as “every N conversation turns or scheduled runs,” default 6). The employee’s own self check-ins don’t count. To keep it from running too often, cleanups are at least 6 hours apart, and if 30 days pass without one, the employee tidies up once even when there’s been no work. The employee uses that time to tidy its memories, turn corrections it has received more than once into rules, and leave its next steps on its to-do list. A Quiet Moment is a low-key wake that lets the employee 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: public version sessions, work setup, and mission delegation.

At a Glance

1. User Message

The most basic case. You open the employee’s chat view, type a message, and the employee 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 employee used tools (web search, code execution, image generation, etc.), each step expands as a card inside the message.

2. Scheduled Run

The employee 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 employee 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 employee runs on its own and the result is appended to your chat view as a new message.
• The message carries a small “Started by scheduled run” label.
• If you’ve turned on push notifications, your phone gets one too.

Learn more: see Setting Up Scheduled Runs for how to create and manage scheduled runs.

3. External Signal (Webhook)

An external service can wake your employee up by sending it a signal. n8n, GitHub, Linear, Slack, or a server you operate: anything that can make an HTTP request can hand work off to the employee. 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 AI Employees from Slack).

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

When to use

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

Setting it up (generic webhook: you register the URL yourself)

1. Open the employee 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 run conditions)

The same Webhook subpage has a “Run conditions” 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 run condition. For GitHub, you register a URL and secret directly, so you can create the run condition without connecting an account first. (For an employee that belongs to an organization, an org-designated account is used instead, and you won’t need to connect one yourself, and the screen tells you so.)
2. Click Create and choose which event types (issue created, comment added, etc.) should wake the employee. 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 request for this run condition so the employee 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 run condition on or off, and a run history showing when it last fired and on what event.

Where the result lands

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

4. AI Employee Mention

When another employee 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 task, complete it, and report back. This is the core mechanism for collaboration between employees.

When a mention arrives, the woken employee 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 employee 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.

5. Email

Every employee has its own dedicated email address. Send mail to that address and the employee wakes up, reads it, and replies if it needs to.

By default, only mail from your verified email address can wake the employee. Mail from anyone else is held: stored, but it doesn’t wake the employee.

Now you, the owner, can approve a specific person’s address. Add it on the web under the employee’s Mail → Sending permissions → Allowed email contacts, or ask the employee in a one-on-one chat. Once approved, that person’s mail wakes the employee too, and the employee can write back to them.

Held mail isn’t lost. When mail from an unapproved sender arrives, you get notified. If you later approve that person, their recent held mail is automatically revived and worked through in order, so you don’t need to ask them to resend anything.

When to use it

• An external partner or customer needs to send requests straight to the employee by email
• You want to give one colleague (not just yourself) permission to email this employee

Where the result lands

• When an approved person’s mail arrives, the employee wakes up and the mail is added to the chat view automatically.
• The employee can reply directly to that person.
• Mail from anyone not approved is held, and you’re notified.

There are two ways to approve. On the web, open the employee’s Mail page, Sending permissions tab, and add the address under Allowed email contacts (the mobile apps don’t have this page yet). Or ask the employee directly, in conversation. In conversation, for example, tell it “also accept mail from kim@partner.com,” and the employee confirms the request and approves it on the spot. The request has to happen in your own one-on-one chat with the employee. It won’t approve anyone from a turn started by a scheduled run or any other way. That’s a safeguard against a stranger’s email body tricking the employee into approving itself.

Employees that belong to an enterprise (managed service contract) organization can usually already email any external party, so this approval feature matters less to them. It’s most useful for a personal employee where you want to open the door to one specific person. See Connecting External Services for the basics, like verifying your email address.

How the Chat Shows Automatic Runs

When the employee is woken by a scheduled run, a webhook, or a mention (anything that isn’t a message you typed), the resulting reply carries a small badge at the top:

• Scheduled run: labeled “Started by scheduled run,” showing the request stored on that scheduled run
• Webhook: labeled “Triggered by webhook,” showing the request that arrived in the signal
• Mention: labeled “Mention from @sender,” showing the message body from the sender

Messages that arrived by email use the same badge system, but since they’re handled through the same path as webhooks internally, they carry the “Triggered by webhook” label.

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

Where to Manage Notifications

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

• Settings → Notifications lets you toggle each type.
• When several automatic runs (scheduled run, 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 employee 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 employee under Webhook → Rate limit.
• Dedicated run conditions (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 employee can have at most one run condition 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 employees with @UpServe in a channel. See Calling AI Employees 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 employee doesn’t run again and you aren’t charged SU again. This applies to both the generic webhook and dedicated run conditions (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 connection details aren’t sent in the clear. Any custom headers you attach to a callback are masked when displayed.

Response-Required Mentions

When one employee mentions another, the sender can mark the mention as response required. In that case the woken employee 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 employees at a time, and a short cooldown applies between repeated mentions of the same (sender → recipient) pair.

Approved Senders (Email)

• You can approve, revoke, and list approved senders on the web under the employee’s Mail → Sending permissions → Allowed email contacts, or through conversation with the employee (the Agent Email skill). The mobile apps don’t have this page yet.
• A personal employee can only email outside people who are on this list. If it tries to send to an address that isn’t, the approval card says up front that approving won’t deliver it there.
• An approve/revoke request made in conversation is only honored in a turn the owner started themselves. The same request made from a turn woken by a scheduled run, from team or Slack chat, or while the employee is in the middle of processing incoming mail, is refused. This is a server-side guard against a stranger’s email body tricking the employee into adding itself to the approved list. This doesn’t cover every case, though: if you ask the employee, in your own chat, to “check my mail” and the mail itself contains a trick, that’s left to the employee’s own judgment.
• The approved list works on exact address matches only. There’s no way to approve an entire domain at once; each person has to be added individually.
• Mail from an unapproved sender can be revived if you approve them within a retention window of about 7 days. Anything older than that isn’t revived when you approve; only mail sent after the approval is processed normally.
• This feature is built for personal employees (recipient policy: owner-only). An employee that belongs to an enterprise organization (recipient policy: external-allowed) can already wake up from replies by anyone it emailed first. The approved list opens an additional channel independent of that.

The Start Badge in Chat

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

• Scheduled run: shows the request stored on the scheduled run that fired it (the scheduled run’s own name and cadence live on the Automatic runs subpage).
• Webhook: shows the request 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.

Start Metadata Fields

When an employee starts automatically, the following information is stored on the response message and shown in the chat banner:

User-initiated turns do not carry this metadata. Mail that arrives by email is handled through the same path as an external signal (webhook) internally, so it shows the same way as the webhook row above.

When Auto Memory Cleanup Starts

The server counts conversation turns and scheduled runs and makes the call, so the same rule applies whether you work with the employee on web, iOS, or Android.

• What counts: user messages, requests people send through Slack, the Work portal chat, or Linear, team chat, mentions from other AI employees, scheduled runs, and writing the organization’s weekly work report.
• What doesn’t count: self check-ins, the cleanup itself, automatic runs from webhooks, subtasks handed to other employees, and system runs such as goal progress.
• A run that paused for your approval and then continued counts once.
• The count is checked when a self check-in ends or when a long conversation is filed away. If the run that just ended hasn’t been recorded yet, it’s counted at the next check, so a cleanup can start about one run later than the setting says.
• Cleanups are at least 6 hours apart. The 30-day rule is pushed back by up to 7 days per employee, so employees that have been quiet for a long time don’t all start at once.
• Setting Auto memory cleanup to 0 turns it off. An employee with no saved value uses the default of 6 (every 6 conversation turns or scheduled runs). Existing employees that already have a different saved value (for example 12 or 7) keep that value.
• Each cleanup can only look at a limited amount of material. Whatever it didn’t get to is picked up by the next cleanup. If a cleanup ends in an error or hits its time limit, the next cleanup looks at the same material again, and after three failures in a row that material is skipped. A cleanup that was stopped midway by a service update, or one that hit its time limit and was retried right away, doesn’t count as a failure.
• In team chat, only what the employee itself said is collected as material. What other people or other employees said isn’t collected. Neither is text a person wrote that appears under the employee’s name, such as a result the person revised. The exception is feedback a person leaves directly on the employee’s replies, which is also considered.
• Auto memory cleanup doesn’t create new recurring scheduled runs itself. If something should run regularly, it leaves an item on its to-do list, and a later working turn turns that into a scheduled run.

Learn More

• Equipping Tools: decide what the employee can do once it’s awake
• Skills & the Autonomous Skill System: package repeatable procedures
• Sharing an AI Employee Externally: expose an employee to outside visitors through a public version