# Invocations Source: https://www.hyperagent.com/docs/concepts/agents/invocations How a run starts across threads, Slack, schedules, and other triggers, and what changes when nobody is watching. An **invocation** is how an agent starts a run when you are not already chatting in a thread. Someone mentions it in Slack. A schedule fires on Monday morning. A webhook arrives from your CRM. The [thread](/docs/concepts/threads) is still where the work lives. Invocations decide how the run starts and where people interact with the agent. You do not need every invocation on day one. Most agents ship with thread chat plus one external trigger once the job is stable. ## Where you can use an agent [#where-you-can-use-an-agent] Triggers you configure on the agent so work can begin without opening Hyperagent every time. Each tab covers **why** you would use it, **what it unlocks**, and **what to set up**. Open Hyperagent and message the agent when you are still shaping the job. You can watch tools run, correct mistakes, and save what you learn before you automate anything. Threads keep the full workspace in front of you: assets, browsing, @mentioned skills, and the output as you refine the process. Put the agent where your team already works when requests, escalations, and decisions already live in channels. **Why teams add Slack** * People should not context-switch into another app just to kick off work they already discuss in-channel * Each agent can have its own **Slack identity** (for example @PipelineLead or @RevOps) so the channel knows which role is answering * You control what wakes the agent (@mention, topic listening, thread follow-ups) and where it may listen without posting Slack is both an **invocation** and an **[integration](/docs/concepts/tools-and-integrations)**. The invocation decides what wakes the agent. The integration decides whether it can read history or post a reply. For channel agents other people can talk to, start with locked-down [knowledge access](/docs/concepts/agents/knowledge-access) so random chat does not quietly rewrite what the agent knows. Use Telegram when the people who need the agent live on mobile or in a Telegram group more than in the Hyperagent UI. **What it unlocks:** quick personal workflows from a phone, or a shared bot in a group. **Setup:** pair the agent with a Telegram bot, then message it directly or add it to a group. Configure identity and who can talk to it. Use a schedule when the job is a predictable deliverable on a calendar. *Every Monday at 7am, draft the pipeline brief and post it to #revops.* **What it unlocks:** recurring reports, digests, and checks that should not wait for someone to remember. **Setup:** standing prompt, cadence and timezone, and whether each run starts a **new thread** or continues one you choose. Use [Live Mode](/docs/concepts/agents/invocations/live-mode) when the agent should watch a changing situation, keep continuity across checks, and only bother you when something needs attention. **What it unlocks:** proactive monitoring without calendar spam. Quiet "all clear" ticks can stay quiet. **Setup:** checklist, interval (minimum 30 minutes), heartbeat model, where runs land, notification channel, and whether unattended runs may write externally. Use email when intake already lives in an inbox: forwards, partner updates, or "send this to the research agent." **What it unlocks:** a dedicated address that turns mail into a run. Hyperagent does **not** email the sender back unless you turn on reply behavior and put reply instructions in the prompt template. ``` If the email needs a response, draft a concise reply to the original sender. Confirm facts from connected systems before you send. Sign as Pipeline Lead. ``` Use a webhook when another product owns the event: a CRM stage change, a form submit, a CI failure. **What it unlocks:** server-side kicks with a payload and secret. Hosted MCP is for driving Hyperagent **from another client** (for example Claude Desktop or Claude Code). It is not the everyday Slack or schedule path. Hyperagent can expose a **hosted MCP server** so an external MCP client starts threads and sends work into your agents. **What it unlocks:** use Hyperagent as a tool from an IDE or desktop client you already live in. **What it is not:** a replacement for Slack, schedules, or webhooks for most teams. It does not create or update skills. Full setup and auth: [MCP server](/docs/concepts/agents/mcp-server). ## Invoking agents with continued context [#invoking-agents-with-continued-context] Whether later runs should see what already happened in the conversation. Some work needs continuity. A [Live Mode](/docs/concepts/agents/invocations/live-mode) watch should know what it flagged yesterday. A Slack thread should keep the back-and-forth. Other work should start clean. A Monday pipeline brief usually should not inherit last Monday's draft and side comments. Later runs see prior messages and artifacts. Natural fit for Live Mode, long investigations, and Slack conversations that unfold over time. Clean workspace with the schedule or webhook prompt as the main input. Natural fit for many daily reports and stateless automations. When a thread grows large, Hyperagent **compacts** older context so the run can continue. Built-in context tools try to preserve what matters, but compaction is real: a very long continued thread is not an infinite verbatim transcript. Prefer a fresh thread for clean recurring deliverables when you do not need yesterday's chatter. ## Automatic invocations and unattended writes [#automatic-invocations-and-unattended-writes] Schedules, Live Mode, webhooks, and email often run without you in the seat. Nobody is present to answer a clarifying question. Include the goal, inputs, destination, and definition of done. Decide whether the unattended run stays read-only, asks outside the run, or may change a connected app. If a schedule researched correctly but never posted to Slack, check integration allow list, channel scope, unattended write setting, and the run's tool trail before rewriting the model prompt. ## Setting up an external invocation on your agent [#setting-up-an-external-invocation-on-your-agent] Prove the job is stable in a thread, then add one invocation. ### Shape the agent in a thread [#shape-the-agent-in-a-thread] Get the prompt, tools, [skills](/docs/concepts/skills), and [memories](/docs/concepts/memories) right while you can still correct the agent in real time. ### Connect integrations, then allow them on the agent [#connect-integrations-then-allow-them-on-the-agent] Connect [integrations](/docs/concepts/tools-and-integrations) at the account level, then allow them on this agent. ### Set knowledge access [#set-knowledge-access] Before other people can talk to the agent in Slack or a [team](/docs/concepts/teams), set [knowledge access](/docs/concepts/agents/knowledge-access). ### Add one invocation [#add-one-invocation] Pick Slack, schedule, email, webhook, Live Mode, or (advanced) MCP. Decide whether unattended runs may write externally. ### Watch the first real runs [#watch-the-first-real-runs] Open Activity and the threads those runs create. Fix scope, permissions, and prompt shape before you add more triggers. ## FAQs [#faqs] No. Start in a thread until the agent is good. Add one external invocation that matches where the work already happens: often Slack or a schedule. No. A schedule usually produces a deliverable on a calendar. [Live Mode](/docs/concepts/agents/invocations/live-mode) watches a situation on an interval, keeps continuity, and can stay quiet when nothing changed. Yes, when you set the schedule that way. Many recurring reports still use a new thread each run so each deliverable stays clean. Check unattended write policy, integration allow list, and channel scope. Open the run thread and read the tool trail before assuming the model forgot. No. Hosted [MCP](/docs/concepts/agents/mcp-server) is advanced: other clients drive Hyperagent. Most teams start with thread, Slack, or schedule.