# Learn Hyperagent Source: https://www.hyperagent.com/docs > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Core concepts and reference for working with Hyperagent. Hyperagent is a platform for building AI agents that do real work. Not chatbots that answer questions and forget you. Agents with names, instructions, tools, knowledge, and multiple ways to start a run. You configure an agent once. Then you use it across threads, trigger it from Slack, Telegram, email, a webhook, or an MCP client, schedule it on a timer, or let it watch for changes on its own. Everything it creates (documents, tables, webpages, images, videos, maps) lives in your Library and is searchable forever. The platform learns with you. Skills let you teach reusable methods that any agent can pick up. Memories (global or agent-scoped) let agents remember what matters across every conversation. Rubrics measure whether your agents are actually getting better over time. Teams let you share everything with colleagues. *** ## Where do you want to start? [#where-do-you-want-to-start] *** ## Working with AI tools [#working-with-ai-tools] Your agents and these docs are both built to be used by other AI tools, not just by people in a browser. For AI readers: the documentation index is at [/llms.txt](https://www.hyperagent.com/llms.txt) and the complete documentation as one file is at [/llms-full.txt](https://www.hyperagent.com/llms-full.txt). *** ## Browse by topic [#browse-by-topic] The core of Hyperagent. An agent has an identity (name, icon, system prompt), configuration tabs, multiple ways to start a run, and the ability to delegate to other agents. * [What is an Agent?](https://www.hyperagent.com/docs/concepts/agents) : The mental model. Not a chatbot, a colleague. * [Agent configuration](https://www.hyperagent.com/docs/concepts/agents/configuration) : Identity, tools, skills, knowledge, model, invocations, and autonomy. * [Other agents](https://www.hyperagent.com/docs/concepts/agents/invocations/other-agents) : When one named agent hands work to another. * [Knowledge and learning](https://www.hyperagent.com/docs/concepts/agents/knowledge-access) : What an agent knows, how it learns, and the controls for both. The conversation where work happens. @mention skills, memories, documents, and tables to bring context in. Use the Actions menu to suggest learnings, build skills, and run evaluations. * [What is a Thread?](https://www.hyperagent.com/docs/concepts/threads) : A persistent conversation with its own context, tools, and outputs. Portable methods you teach once. Process, context, and integration skills. Pin, attach, or discover them. Fix a skill and every agent using it improves. * [What is a Skill?](https://www.hyperagent.com/docs/concepts/skills) : Teach a method once and every agent can use it. * [Knowledge and learning](https://www.hyperagent.com/docs/concepts/agents/knowledge-access) : What an agent can see, and how skills load: pinned, preloaded, discovered. * [Edit and import skills](https://www.hyperagent.com/docs/concepts/skills/skills-edit-and-import) : Day-2 operations and import rules. Facts and preferences that persist across conversations. Memories can be global (visible to all agents) or agent-scoped. Importance 4+ loads automatically. Lower-importance memories surface when relevant. * [What are Memories?](https://www.hyperagent.com/docs/concepts/memories) : Scoped facts. Global or agent-specific. Auto-surfacing. * [Knowledge and learning](https://www.hyperagent.com/docs/concepts/agents/knowledge-access) : What a shared agent can see and learn. Shared workspaces for agents and skills. Three roles (Owner, Editor, Member). Share a resource so the team can run it, or transfer ownership to the team. Knowledge access controls what shared-agent users can see and change. * [What are Teams?](https://www.hyperagent.com/docs/concepts/teams) : Share agents and skills without starting from scratch. * [Knowledge and learning](https://www.hyperagent.com/docs/concepts/agents/knowledge-access) : The boundary between an agent and your wider library. The gallery of everything your agents create across all threads. Images, webpages, tables, documents, maps, videos, slides, apps. Searchable, filterable, publishable. * [What is the Library?](https://www.hyperagent.com/docs/concepts/library) : Your artifact gallery across all threads. Tools are built-in capabilities. Integrations are connected external services. Custom MCP attaches your tool server. * [Tools & Integrations](https://www.hyperagent.com/docs/tools) : Choose between built-in tools, integrations, MCP, and skills. * [Tools](https://www.hyperagent.com/docs/tools) : Every built-in tool, grouped, with defaults. * [Integrations](https://www.hyperagent.com/docs/integrations) : Connect apps. * [Custom MCP](https://www.hyperagent.com/docs/integrations/custom-mcp) : Attach an external MCP server. *** ## FAQs [#faqs] Hyperagent supports the following models. See [Models and compute](https://www.hyperagent.com/docs/concepts/agents/models) for selection and configuration guidance. **Anthropic:** Claude Fable 5, Opus 5, Opus 4.8, Opus 4.7, Opus 4.6, Sonnet 5, Sonnet 4.6, Haiku 4.5 **OpenAI:** GPT 5.6 Sol, GPT 5.6 Terra, GPT 5.6 Luna, GPT 5.5 **Google:** Gemini 3.6 Flash, Gemini 3.5 Flash **Moonshot AI (Kimi):** Kimi K3, Kimi K3 Fast, Kimi K2.6 **Z.ai:** GLM 5.2, GLM 5.2 Fast **Alibaba:** Qwen 3.8 Max, Qwen 3.7 Plus **DeepSeek:** DeepSeek V4 Flash, DeepSeek V4 Pro **MiniMax:** MiniMax M3 **Sakana AI:** Fugu Ultra **xAI:** Grok 4.6, Grok 4.5 **Meta:** Muse Spark 1.1 **Thinking Machines:** Inkling See also: [Models and compute](https://www.hyperagent.com/docs/concepts/agents/models) for how to choose effort, runtime, timeouts, compaction, and Live Mode defaults. A thread is a persistent record of the work, not a disposable conversation. Everything the agent creates (images, tables, webpages, documents) stays in the thread and is searchable later. You can @mention skills, memories, and documents to bring them into context, and use the Actions menu to extract learnings afterward. [Read more: What is a Thread?](https://www.hyperagent.com/docs/concepts/threads) Skills are methods (how to write a report, how to call an API). Memories are facts (your fiscal year starts in August, your CEO goes by her first name). Skills are always portable across agents. Memories can be global (all agents) or scoped to specific agents. Both have scope settings and both build up over time. [Read more: What is a Skill?](https://www.hyperagent.com/docs/concepts/skills) Knowledge access profiles control the boundary between creator and user. * **Curated** (a safe choice for shared and Slack-deployed agents): the agent sees only the knowledge you selected, and it does not learn or write from its runs. * **Synced self-learning**: for agents you use yourself. Sees your memories, learns from runs, and saves into your memories. * **Standalone self-learning**: sees selected memories and saves what it learns to its own memories, without touching yours. * **Custom**: tune the individual controls one by one. Team-owned agents expose the underlying memory, skill, and learning controls directly instead of these profile cards. [Read more: Knowledge and learning](https://www.hyperagent.com/docs/concepts/agents/knowledge-access) and [Teams](https://www.hyperagent.com/docs/concepts/teams) Yes. A memory saved to your memories can serve any of your agents, while a memory that belongs to one agent stays with it. You can also link a specific memory to the agents that should have it. Each agent's read scope decides which it draws on: **All memories** sees everything you've saved, **Only curated memories** sees just what you linked to it. [Read more: What are Memories?](https://www.hyperagent.com/docs/concepts/memories) A run can start from a thread, Slack, Telegram, a schedule, Live Mode, email, a webhook, an MCP client, or another agent through delegation. Live Mode is watch-and-alert on an interval. MCP lets an external AI client start a thread with one of your agents. * [Invocations and deployment](https://www.hyperagent.com/docs/concepts/agents/invocations) * [Live Mode](https://www.hyperagent.com/docs/concepts/agents/invocations/live-mode) * [MCP server](https://www.hyperagent.com/docs/concepts/agents/invocations/mcp-server) * [Other agents](https://www.hyperagent.com/docs/concepts/agents/invocations/other-agents) Tools are built-in platform capabilities (web search, code execution, image generation, maps). They toggle on instantly per agent. Integrations are connected external services (Slack, Gmail, GitHub, Airtable) that require a connect flow first. Custom MCP attaches an external tool server. Skills teach methods. [Read more: Tools & Integrations](https://www.hyperagent.com/docs/tools) Rubrics. Define weighted quality criteria for the type of output your agent produces. Evaluate outputs to get per-criterion scores. Analyze patterns across evaluations to find consistent weak spots. Then A/B test a fix (new skill, updated memory, revised prompt) against the baseline before committing it. The Library. Every artifact your agents create across all threads (images, webpages, tables, documents, maps, videos, slides, apps) is collected in one gallery at /library. You can search, filter by type, publish publicly with one click, and track version history on documents and webpages. [Read more: What is the Library?](https://www.hyperagent.com/docs/concepts/library) Start with the [Troubleshooting FAQ](https://www.hyperagent.com/docs/reference/troubleshooting-faq), then [Troubleshoot a stuck run](https://www.hyperagent.com/docs/reference/runtime-limits). Open the thread tool trail before rewriting the whole prompt. --- # Account Source: https://www.hyperagent.com/docs/account > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Administering your Hyperagent account: troubleshooting, run limits, and data. This section is for the moments you're administering rather than building. --- # Recover your Hyperagent account Source: https://www.hyperagent.com/docs/account/sign-in-with-apple-account-recovery > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. If you sign in with Apple and your account looks empty, find our email with your personal reconnect link and sign in once. If you signed in with Apple and your account looks empty, your account needs a one-time reconnect. Your data is safe. This takes one sign-in. ## 1. Find our email [#1-find-our-email] Search your inbox for the subject **"Update to Sign in with Apple with your Hyperagent account"**. It contains your personal **Recover my account** link. Check the inbox for the email address on your Apple account. Apple forwards Hide My Email messages there. Check spam if it isn't there. ## 2. Sign in once [#2-sign-in-once] Open the **Recover my account** link, sign in with Apple, and confirm on the consent screen. Nothing changes until you confirm. After that, your account and your things are back. Keep the email. The link is valid for 12 months. ## Can't find the email? [#cant-find-the-email] Email [support@hyperagent.com](mailto:support@hyperagent.com) and we'll help you reconnect your account. --- # Billing and credits Source: https://www.hyperagent.com/docs/billing > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. How credits, billing periods, plan changes, and shared billing work, and where to find every live number in the product. Hyperagent billing is built around credits: a dollar-denominated balance that pays for your usage. You pick a monthly plan and pay its price at the start of each billing period. That money comes back as credit to spend, plus a bonus that grows with your plan, and your usage spends the balance down. These pages answer the questions that come up most, and point you to the exact place in the product that shows each live number. Pay As You Go and annual plans are no longer offered, and the early-user bonus subsidy has been replaced by a progressive bonus. If you received the migration email, [Pricing changes (August 2026\)](https://www.hyperagent.com/docs/billing/pricing-changes) explains what moves and when. ## Manage billing and usage [#manage-billing-and-usage] ## FAQs [#faqs] Open **Settings → Billing** to see your current plan, remaining credits, current-period usage, and awarded bonus credits. [Usage and invoices](https://www.hyperagent.com/docs/billing/invoices) maps each figure to its exact product surface. Each kind has its own clock. Plan credit expires at the end of the billing period and does not carry over. Credit you buy, on its own or through auto-recharge, lasts 90 days from purchase. Awarded bonus and promotional credits show their own expiry dates on the Credits card in Settings → Billing. See [Credits](https://www.hyperagent.com/docs/billing/credits#when-credits-expire) for the full breakdown. New runs pause until the next billing period, and nothing extra is billed unless you opt in. To keep going, [buy more credit](https://www.hyperagent.com/docs/billing/credits#buy-a-credit-block) or [turn on auto-recharge](https://www.hyperagent.com/docs/billing/credits#turn-on-auto-recharge). Your credit balance already bounds what you can spend in a period. Beyond that, choose a lighter model for each job. See [Control your costs](https://www.hyperagent.com/docs/billing/control-costs). Yes. An eligible Owner can enable Shared Billing to move invited members onto one organization payment method. See [Shared Billing](https://www.hyperagent.com/docs/billing/shared-billing) before making the one-way change. Yes. Open **Settings → Billing → Invoices** to view past invoices and download a PDF. Invoices are also emailed when they are issued. Apple-billed receipts stay in your App Store subscription history. See [Usage and invoices](https://www.hyperagent.com/docs/billing/invoices). Yes. Connect it through OAuth in **Settings → AI providers**. Supported GPT model usage can run against ChatGPT instead of your Hyperagent credits. API keys and other AI providers are not currently supported. See [Connect your ChatGPT subscription](https://www.hyperagent.com/docs/billing/plans/connect-chatgpt-subscription). --- # Control your costs Source: https://www.hyperagent.com/docs/billing/control-costs > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. The two levers that shape what you spend in Hyperagent, which plan you pick and which model does the work. Two levers shape what you spend in Hyperagent: which plan you pick, and which model does the work. The first sets the ceiling on a period. The second sets what your work costs run to run. This page covers both. ## Pick the plan that fits your usage [#pick-the-plan-that-fits-your-usage] Your spending is bounded by the credit you hold. You pay your plan price each month, it is charged up front and becomes credit plus a progressive bonus, and your agents spend that balance as they run. There is no separate cost cap to configure: with [credit top-ups and auto-recharge](https://www.hyperagent.com/docs/billing/credits#buy-a-credit-block) left off, your plan price is the ceiling for the period. A higher monthly plan earns a larger bonus, up to 45 percent, so more of your usage is covered by credit. Pick the tier that matches how much work you expect to run. See [Plans](https://www.hyperagent.com/docs/billing/plans) for the full ladder. When credit runs low, add a credit block in **Settings → Billing**, or turn on auto-recharge so a new block is added automatically when your balance falls below the threshold you set. Because usage spends a balance you already hold, your plan price is itself the guardrail. Leaving auto-recharge off keeps the period capped at what you paid up front. Turning it on trades that hard stop for continuity when a run needs more than the balance left. See [Credits](https://www.hyperagent.com/docs/billing/credits) for how the balance is spent and [Usage and invoices](https://www.hyperagent.com/docs/billing/invoices) for how to track it. ## Choose the right model for the work [#choose-the-right-model-for-the-work] Model cost and capability vary widely for the same job, so the model you pick is the biggest lever on what a run costs. The model picker in the agent editor is the source of truth for what each model costs in your workspace right now. The roster changes as models are added and prices are adjusted, so read the picker rather than memorizing a list, and let it guide the tradeoff between price and capability. The general principle is to start lighter and escalate on purpose. Many jobs do not need the strongest model, and a lighter model that finishes the work well costs less per token. Reach for a stronger model when the task's judgment is high-stakes, or when the cost of reviewing and correcting a weaker answer would exceed the price difference. ### Name the job [#name-the-job] A specific task, such as preparing a weekly report, is easier to staff than a general one. ### Start where the job seems to fit [#start-where-the-job-seems-to-fit] Weigh the job's judgment and frequency before reaching for the strongest option in the picker. ### Test one class lighter [#test-one-class-lighter] Run a few real runs on a lighter model with the same instructions and skills, then compare the finished quality and the bill. ### Escalate when needed [#escalate-when-needed] Move up when the review burden or the cost of a wrong answer exceeds the price difference. Model choice does not require rebuilding an agent. You can run the same agent on two models with the same instructions, tools, and inputs, then compare quality and spend in [Usage and invoices](https://www.hyperagent.com/docs/billing/invoices). A cheaper run stops being cheaper when someone has to redo the work, so test the finished output, not just the price. Many models also expose an effort control and a per-run budget on the agent. Effort trades latency and cost for more reasoning room; the per-run budget caps what a single query can spend. Both sit below the model choice in impact. See [Supported models](https://www.hyperagent.com/docs/concepts/agents/models). ## How the two levers work together [#how-the-two-levers-work-together] Your plan sets how much you can spend in a period, and your model choice sets what each run costs against that balance. A well-matched model stretches a given plan further, and a plan sized to your usage keeps the period predictable. The two are complementary, and neither replaces the other. ## FAQs [#faqs] Your monthly plan price is the ceiling by default. Usage spends the credit you hold, and nothing bills beyond it unless you opt in, so leaving [auto-recharge](https://www.hyperagent.com/docs/billing/credits#turn-on-auto-recharge) off keeps the period capped at what you paid up front. No. Your plan replaces the old cost-cap and extra-billing settings with a credit balance. When it runs low you add a credit block or turn on auto-recharge. See [Credits](https://www.hyperagent.com/docs/billing/credits) and [Pricing changes](https://www.hyperagent.com/docs/billing/pricing-changes). Add a credit block in **Settings → Billing**, or turn on auto-recharge so a new block is added automatically when your balance falls below the threshold you set. Start lighter and escalate on purpose. Open the model picker in the agent editor, which shows what each model costs in your workspace now, and test a lighter model on real runs. Move up when the job's judgment is high-stakes. The model picker in the agent editor is the source of truth for current pricing. Usage broken down by provider and model is on the Usage card in **Settings → Billing** and on a thread's **Usage** tab. See [Usage and invoices](https://www.hyperagent.com/docs/billing/invoices). --- # Credits Source: https://www.hyperagent.com/docs/billing/credits > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. How credits work, what they pay for, when they expire, and what to do when your balance runs low. Credits are a USD balance that pays for metered work in Hyperagent. Your plan price is charged up front and becomes credit that agents spend as they run models, generate media, search the web, drive browsers, and take actions through integrations. ## Your plan price becomes credit [#your-plan-price-becomes-credit] Pick a monthly plan and you pay its price at the start of each billing period. Every dollar comes back as credit to spend, plus a bonus on top: up to 45 percent extra on bigger plans. On Hyperagent 100, for example, $100 becomes $115 of credit. Your agents spend that credit as they work. Every run deducts the cost of the models, media, and tools it used, and whatever is left is yours to spend for the rest of the period. ## What credits pay for [#what-credits-pay-for] A run's cost is the sum of the metered work behind it. Each line below is a charge type you will see itemized on the Usage card in Settings → Billing: Input, output, and cache tokens used by supported models. Images generated during a run. Video seconds generated during a run. Spoken audio generated from text. Searches an agent runs to find current information. Interactive browser time used to complete a run. Actions an agent takes through connected services. Presenter videos created with avatar tools. ## What a run costs [#what-a-run-costs] No two runs cost the same, because you pay for what the agent actually does rather than a fixed price per message. A quick question that needs one model reply costs little. A deep research task that reads dozens of pages, calls several tools, and generates images costs more. The Usage card itemizes every charge in a period by provider and model, so you can see exactly what a run spent. Ask an agent to triage an inbox of support requests and the card shows the model tokens for each reply, the web searches behind any escalation research, and the browser sessions used to open linked tickets, each as its own line. ## Why costs vary [#why-costs-vary] Three things push a run's cost up or down: * **The model you pick.** Faster, smaller models cost less per token than frontier models. * **How much context the run carries.** Every message includes the earlier conversation, so longer threads cost more per reply. * **How many tools and media the run uses.** Each search, browser session, image, and connected-service action adds its own charge. To lower spend, pick a lighter model for routine work, start a fresh thread instead of extending a long one, and connect only the tools the task needs. See [Control your costs](https://www.hyperagent.com/docs/billing/control-costs) for the full approach. ## When credits expire [#when-credits-expire] Each kind of credit follows its own clock. The credit from your plan plus its bonus is spent within the billing period it was granted for. Whatever is unused expires when the period ends, and a fresh grant arrives when the next period begins. See [Manage your plan](https://www.hyperagent.com/docs/billing/plans/manage-plan) for when a period starts and ends. Credit you [buy as a block](#buy-a-credit-block) or receive through [auto-recharge](#turn-on-auto-recharge) lasts 90 days from the purchase date, so it carries across billing periods until spent. Promotional and referral credits are issued as separate blocks. Each block shows its remaining balance and its own expiry date in Settings → Billing. An unused block is forfeited when that date passes. When you hold more than one kind of credit, Hyperagent always spends the block with the nearest expiry date first, whether that is a promotional block, a bonus block, or your plan credit. Spending down the soonest-to-expire credit first is what keeps a block from expiring unused while a later one sits idle. ## What happens when your balance runs low [#what-happens-when-your-balance-runs-low] By default, your plan price is all you ever pay. When your credit for the period is spent, new runs pause until the next period begins. Nothing extra is billed unless you choose it. There are two ways to add more, and both are opt-in. Both live on the Prepaid credit card in **Settings → Billing**: ### Buy a credit block [#buy-a-credit-block] A credit block is a one-time top-up you buy in **Settings → Billing**. You choose a whole-dollar amount between $10 and $25,000, and every dollar buys exactly one dollar of credit. Top-ups do not earn the plan bonus. The charge goes to your saved card right away, and the credit becomes spendable as soon as the payment settles, usually within moments. If the payment fails, the block waits as pending rather than granting credit, and you get a link to the invoice so you can pay it directly. A purchased block lasts 90 days from the day you buy it, so unlike your plan credit it carries across billing periods until it is spent or expires. ### Turn on auto-recharge [#turn-on-auto-recharge] Auto-recharge keeps your agents running without manual top-ups, and it is the one setting that lets Hyperagent charge your card beyond your plan price, so turn it on deliberately. You set two numbers in **Settings → Billing**: * **Threshold**: when your balance falls to this amount, a recharge triggers. * **Recharge amount**: how much credit is bought each time, charged to your saved card. It must be more than the threshold, so one recharge lifts you clearly out of the trigger zone. Each recharge buys credit at the same one-to-one rate as a manual block, and each recharged block also lasts 90 days. You have one auto-recharge setting at a time: saving new numbers replaces it, and turning it off removes it. If you turn it on while your balance is already at or below the threshold, the first recharge happens immediately. Auto-recharge is the right tool for agents that must not stop, like scheduled runs and Live Mode watches. If an agent misbehaves while auto-recharge is on, it can keep buying credit until you intervene, so pair it with a sensible **Budget limit per query** on expensive agents. ### On Shared Billing [#on-shared-billing] Members of a Shared Billing organization cannot buy credit or set up auto-recharge themselves. The organization's Owner manages billing, so ask them to top up or configure auto-recharge. See [Shared Billing](https://www.hyperagent.com/docs/billing/shared-billing). The earlier included-usage, cost-cap, and extra-billing behavior belonged to Pay As You Go and the older subscription plans, which are being retired. If you are moving off one of those plans, see [Pricing changes](https://www.hyperagent.com/docs/billing/pricing-changes) for what changes and when. ## Sharing credits through Shared Billing [#sharing-credits-through-shared-billing] Credits belong to a billing account. Separate personal accounts do not combine balances, so each person's usage is paid from their own plan and credits. Shared Billing is the exception. An eligible Owner can move invited members onto one organization balance that covers their usage. See [Shared Billing](https://www.hyperagent.com/docs/billing/shared-billing) before enabling it. ## Check your balance and usage [#check-your-balance-and-usage] Open Settings → Billing to see your current balance, account-level usage for the current billing period, your plan and promotional credit blocks, and their expiry dates. Use Command Center to compare total cost across agents. To inspect one agent's usage for the billing period by model, service, thread, or run, open **Observability → Usage** on that agent's configuration page. For one thread's metered costs and ChatGPT-subscription usage, open the thread's **Usage** tab. See [Usage and invoices](https://www.hyperagent.com/docs/billing/invoices). ## FAQs [#faqs] Open **Settings → Billing**. Your current balance, the split between plan and promotional credit, and each block's expiry date are all there. Credit from your plan and its bonus is spent within the billing period it was granted for and expires at the end of that period. A fresh grant arrives when the next period begins. Promotional and bonus blocks carry their own expiry dates, shown in **Settings → Billing**. By default, runs pause until the next period and nothing extra is billed. To keep going, [buy a credit block](#buy-a-credit-block) in **Settings → Billing**, or [turn on auto-recharge](#turn-on-auto-recharge) to add credit automatically when your balance falls to the threshold you set. Both are opt-in charges to your card. Only if you choose it. Buying a credit block is a one-time charge, and auto-recharge charges your card automatically each time your balance falls to your threshold. With both off, your plan price is the most you pay in a period. Yes. Promotional and bonus credits you already received are not affected by the pricing change. Each block keeps its own expiry date in **Settings → Billing**. See [Pricing changes](https://www.hyperagent.com/docs/billing/pricing-changes) for the details. Whichever block expires soonest. Hyperagent spends the credit with the nearest expiry date first, across promotional, bonus, and plan credit alike, so nothing expires unused while a later block still has balance. Promotional and referral credits carry their own terms, so eligibility can vary by the specific offer or code, and some apply only while you are on a paid plan. Open **Settings → Billing** to check whether the block is active and what its terms and expiry are. If it should be active and is not, contact Support. Not by default. Credits belong to a billing account. The exception is Shared Billing, where an eligible Owner moves invited members onto one organization balance. See [Shared Billing](https://www.hyperagent.com/docs/billing/shared-billing). --- # Usage and invoices Source: https://www.hyperagent.com/docs/billing/invoices > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Choose the right view for account-level usage, costs across agents, detailed agent and thread spend, and billing history. Hyperagent reports spend at different levels, from the whole account down to a single run, and keeps billing history separately. Pick the view that matches what you need to understand. ## Your account this period [#your-account-this-period] Open **Settings → Billing** to review usage for the current billing period. The Usage report shows the selected account member's total usage and breaks it down by model or service. Use **Filter by** to switch between members when more than one is available. Usage figures are estimated from usage records, so they may differ slightly from the final invoice. The report covers your current billing period, the same window that governs when plan changes take effect; see [Manage your plan](https://www.hyperagent.com/docs/billing/plans/manage-plan) for when that window starts and ends. ## Cap a single run [#cap-a-single-run] Reading spend tells you where it went; a per-run budget decides in advance how much any one task can cost. Open an agent's editor and set **Budget limit per query** under model settings to the most one run can spend. Use it on agents that can trigger expensive work so a single task cannot run away. To lower what work normally costs rather than cap it, see [Control your costs](https://www.hyperagent.com/docs/billing/control-costs). ## Which agents drive your spend [#which-agents-drive-your-spend] Open **[Command Center](https://hyperagent.com/command-center)** to see total cost across your agents. The Agent Roster lists the total cost for each agent, while Cost Breakdown makes it easier to compare the agents driving the most spend. Use Command Center for an operational view of agent costs. It is not an invoice record. ## What one agent spent [#what-one-agent-spent] To understand one agent's costs for the billing period, open that agent's configuration page, expand **Observability**, and select **Usage**. The Usage view covers that billing period. It shows total cost per day, total usage, and a breakdown by model or service. Switch between **Total**, **Per thread**, and **Per run** to investigate where the cost came from. ## What one thread cost [#what-one-thread-cost] To see what one thread cost, open the thread and select **Usage**. Usage Breakdown shows the thread's metered costs by provider and model. Switch from **Total** to **Tools** when you want to isolate tool usage. If the thread used a connected ChatGPT subscription, **Tokens on your key** shows its input, output, and cached token counts. Despite the label, the connection uses OAuth and does not involve a pasted API key. These tokens are not included in the Hyperagent cost above. ## Invoices and billing history [#invoices-and-billing-history] Open **Settings → Billing → Invoices** to see your past invoices. Each entry shows the issue date, invoice number, status, and total amount. Select **View** when it is available to open an invoice, or select **PDF** to download a copy. Invoices are also emailed to you when they are issued. If you are billed through Apple, your receipts and subscription history live in your Apple account. Open your App Store subscription history to download them. ## FAQs [#faqs] Open **Settings → Billing** for the account-level Usage report. It shows the selected member's total usage for the current billing period, broken down by model or service. Use **Filter by** to switch between members. Open the agent's editor and set **Budget limit per query** under model settings to the most one run can spend. On a monthly plan, your total spend for the period is already bounded by your credit balance. Open **[Command Center](https://hyperagent.com/command-center)**. The summary shows total cost, while Agent Roster and Cost Breakdown show the amount attributed to each agent. For an agent, open its configuration page and select **Observability → Usage**. For one thread, open the thread and select **Usage**. The thread view separates total metered costs, tool costs, and tokens routed through a connected ChatGPT subscription. Usage views are estimated from usage records, so totals may differ slightly from the final invoice. Tokens routed through a connected ChatGPT subscription are not included in Hyperagent's metered cost. Open **Settings → Billing**. The Usage card shows your current balance and current-period usage. The Credits card shows bonus balances and expiry dates. Current plan shows your credit, price, and next billing date. Yes. Open **Settings → Billing → Invoices** and select **PDF** beside an invoice. Invoices are also emailed when they are issued. If you are billed through Apple, download receipts from your App Store subscription history. --- # Plans Source: https://www.hyperagent.com/docs/billing/plans > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. How Hyperagent's monthly plans work, what each plan grants, and how to connect a ChatGPT subscription. You pick a plan, Hyperagent charges its price up front, and you receive that amount as credit plus a progressive bonus that grows with your plan, up to 45%. ## How a plan works [#how-a-plan-works] Hyperagent charges your monthly price at the start of each billing period. By default that is all you pay. Every dollar returns as credit, with a bonus on top that grows with your plan. Your agents spend it as they run. Unused credit expires when the period ends. If it runs out early, runs pause until the next period unless you [buy a credit block](https://www.hyperagent.com/docs/billing/credits#buy-a-credit-block) or [turn on auto-recharge](https://www.hyperagent.com/docs/billing/credits#turn-on-auto-recharge). | Plan | Monthly price | Total credits | Bonus | | ---------------- | ------------- | ------------- | ----- | | Hyperagent 20 | $20 | $20 | 0% | | Hyperagent 50 | $50 | $55 | 10% | | Hyperagent 100 | $100 | $115 | 15% | | Hyperagent 200 | $200 | $240 | 20% | | Hyperagent 500 | $500 | $625 | 25% | | Hyperagent 1000 | $1,000 | $1,300 | 30% | | Hyperagent 2000 | $2,000 | $2,700 | 35% | | Hyperagent 5000 | $5,000 | $7,000 | 40% | | Hyperagent 10000 | $10,000 | $14,500 | 45% | Your current plan, its credit, and your remaining balance show in **Settings → Billing**, and your billing date is anchored to the day you first subscribed. As of August 26, 2026, Pay As You Go and Annual plans are discontinued. If you are migrating from one of them, see [Pricing changes (August 2026\)](https://www.hyperagent.com/docs/billing/pricing-changes) for exactly what happens to your account. ## How spending is controlled [#how-spending-is-controlled] There is no cost cap to configure: your spending is bounded by the credit you hold, and you control the pace two ways. [Buy a credit block](https://www.hyperagent.com/docs/billing/credits#buy-a-credit-block) or [turn on auto-recharge](https://www.hyperagent.com/docs/billing/credits#turn-on-auto-recharge) in **Settings → Billing** so runs keep going without waiting for the next period. Both are opt-in charges. Set **Budget limit per query** on an agent to cap what one run can spend. Use it on agents that can trigger expensive work so a single task cannot run away. Model choice sets how fast credit goes: see [Control your costs](https://www.hyperagent.com/docs/billing/control-costs) for pacing spend and [Usage and invoices](https://www.hyperagent.com/docs/billing/invoices) for tracking it. ## Connect a ChatGPT subscription [#connect-a-chatgpt-subscription] ## Change your plan [#change-your-plan] ## FAQs [#faqs] Credit equal to your monthly plan price plus a progressive bonus that grows with your plan, up to 45%. See the ladder table above. Both are discontinued as of August 26, 2026. See [Pricing changes (August 2026\)](https://www.hyperagent.com/docs/billing/pricing-changes) for what happens to existing accounts. By default runs pause until the next period and nothing extra is billed. To keep going, [buy a credit block](https://www.hyperagent.com/docs/billing/credits#buy-a-credit-block) or [turn on auto-recharge](https://www.hyperagent.com/docs/billing/credits#turn-on-auto-recharge) in **Settings → Billing**. Both are opt-in charges. Yes. Set **Budget limit per query** on an agent to cap one run. Account-wide spending is bounded by your credit balance rather than a cost cap. Open **Settings → Billing** to see your current plan, credit, and next billing date. No. A connected ChatGPT subscription can cover supported GPT model usage, but other models, tools, and media still bill through Hyperagent. See [Connect your ChatGPT subscription](https://www.hyperagent.com/docs/billing/plans/connect-chatgpt-subscription). --- # Connect your ChatGPT subscription Source: https://www.hyperagent.com/docs/billing/plans/connect-chatgpt-subscription > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Connect ChatGPT to Hyperagent with OAuth, choose fallback behavior, and see which usage is covered by ChatGPT or billed through Hyperagent. Connect your ChatGPT subscription to run supported GPT model usage through ChatGPT instead of your Hyperagent credits. Hyperagent currently supports ChatGPT subscriptions only, and the connection uses OAuth. ## Set up your connection [#set-up-your-connection] In your ChatGPT settings, turn on **Enable device code authorization for Codex**. The Hyperagent sign-in flow will not appear until this setting is on. ### Start the connection in Hyperagent [#start-the-connection-in-hyperagent] Open **Settings → AI providers** and choose **Connect a ChatGPT subscription**. Hyperagent displays a device code and a link to the verification page. ### Authenticate with ChatGPT [#authenticate-with-chatgpt] Select **Open verification page** and sign in to the ChatGPT account whose subscription you want your agents to use. ### Enter the verification code [#enter-the-verification-code] Enter the code shown in Hyperagent to approve the connection. Hyperagent waits for approval and marks the subscription active when verification is complete. ## What the connection covers [#what-the-connection-covers] When the connection is active, supported GPT model usage runs against your ChatGPT subscription instead of drawing from your Hyperagent credits. The connection applies only to usage supported by your ChatGPT subscription. Other models, image generation, search, browser sessions, and connected-service actions continue billing through Hyperagent. ## When you reach a ChatGPT usage limit [#when-you-reach-a-chatgpt-usage-limit] ChatGPT subscriptions can have hourly or weekly usage limits. **Use Hyperagent subscription when usage is limited** controls what happens when you reach one: * When the setting is off, work using the limited ChatGPT connection may be interrupted. * When the setting is on, Hyperagent can cover the excess usage and bill it to your Hyperagent subscription. ## How charges appear in a thread [#how-charges-appear-in-a-thread] Open a thread's **Usage** tab to see where its usage was covered. **Usage Breakdown** shows metered charges billed through Hyperagent, grouped by provider and model. Switch to **Tools** to isolate tool charges. The current thread view labels ChatGPT-subscription usage as **Tokens on your key**. This refers to tokens routed through the OAuth connection. It does not mean an API key was pasted. These tokens are not included in the Hyperagent cost above. ## If ChatGPT usage was billed through Hyperagent [#if-chatgpt-usage-was-billed-through-hyperagent] When **Use Hyperagent subscription when usage is limited** is on, Hyperagent covers usage after you reach a ChatGPT limit and bills that usage to your Hyperagent subscription. The OAuth connection covers supported GPT model usage. Other models, tools, browser sessions, search, and media generation continue billing through Hyperagent. Open **Settings → AI providers** and reconnect the subscription. Usage cannot run against ChatGPT while the OAuth connection is inactive. No. Hyperagent currently supports ChatGPT subscriptions through OAuth. There is no API-key entry or pasted-key billing path. Not currently. ChatGPT subscriptions are the only supported AI provider connection. --- # Manage your plan Source: https://www.hyperagent.com/docs/billing/plans/manage-plan > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. How to upgrade, downgrade, or cancel, when each change takes effect, how to manage your card, and what happens to the rest of a paid period. Upgrades apply immediately for a prorated charge. Downgrades and cancellations take effect at the end of your current billing period, so you keep what you paid for until then. You change your plan and manage your payment method from **Settings → Billing**. Each change takes effect at a different point in your paid period, and card actions follow their own rules. ## Upgrade [#upgrade] Upgrading to a higher plan takes effect immediately. Hyperagent charges the prorated difference for the rest of the current period, and your new plan's larger credit becomes available right away. ### Open Settings → Billing [#open-settings--billing] Go to the Billing section of Settings. ### Choose the higher plan [#choose-the-higher-plan] Select the plan you want to move to. ### Confirm the change [#confirm-the-change] You keep your existing billing date. The only immediate charge is the prorated difference between your old plan and the new one for the days remaining in the period. ## Downgrade [#downgrade] Downgrading to a lower plan is scheduled for the end of your current billing period. You keep your current plan and its full credit until the period ends. Nothing is taken back mid-period. When the period rolls, you move to the lower plan and its smaller credit. If you change your mind before the period ends, you can move back to the higher plan and the scheduled downgrade does not take effect. ## Cancel [#cancel] Cancelling always takes effect at the end of the current billing period. You keep full access until the period ends, and no further charge is taken after the period closes. ## When changes take effect [#when-changes-take-effect] Whether a change happens now or later comes down to your billing period, the window your current plan is billing for. Your period is anchored to the day you first subscribed, so it renews on that same date each cycle rather than on the first of the calendar month. That anchor is why a downgrade or cancellation lands on a specific day: it takes effect when the current period ends, whenever that falls for you. An upgrade is the exception. Because you pay the prorated difference for it, an upgrade changes your plan mid-period while the period itself keeps the same anchor date. The remainder of a paid period is never cut short. Whether you downgrade or cancel, you keep your current plan and credits until the period ends. There is no self-serve refund for unused time; contact Support if you believe you are owed one. If an agent errored or looped and consumed credits unexpectedly, share the thread link and roughly how many credits were used so Support can review it. Annual plans have been retired. If you are still on one, you keep your current annual terms through the end of your already-paid term, and your credits still refresh each period. At the end of the term the subscription moves to the matching monthly plan. See [Pricing changes (August 2026\)](https://www.hyperagent.com/docs/billing/pricing-changes) for the full migration. This same period is also the window your usage and invoices describe. See [Usage and invoices](https://www.hyperagent.com/docs/billing/invoices) for reading the numbers. ## Add or replace a card [#add-or-replace-a-card] You add a payment method when you subscribe to a paid plan, and Hyperagent saves it for future billing through the secure payment flow. To use a different card later, replace it from Settings → Billing: open your current plan's Manage menu, choose Update payment method, and save the new card. Updating your card does not change your plan or your billing date. ## Remove a card [#remove-a-card] There is no way to remove a card while a subscription is active, and that is intentional: an active paid plan always needs a valid card on file so the next charge can go through. The supported action is to replace the card, not remove it. To stop the card from being charged again, cancel the plan instead. Use this path for each goal: * Want to use a different card: replace it from Settings → Billing. * Want to stop being charged: cancel the plan and keep access until the period ends. * Want the card deleted because the subscription is already cancelled: the card stops being charged at the end of the paid period; contact Support to remove it from the payment record. If you still have an active subscription, cancel it first. ## FAQs [#faqs] Immediately. Hyperagent charges the prorated difference for the rest of the period, and the larger credit is available right away. At the end of your current billing period, which is anchored to the day you first subscribed. You keep your current plan and credits until then, and no further charge is taken after the period closes. Your period is anchored to your signup date, so it renews on that same date each cycle rather than on the first of the month. Annual plans are no longer offered. You keep your current annual terms through the end of your already-paid term, your credits still refresh each period, and at the end of the term the subscription moves to the matching monthly plan. See [Pricing changes (August 2026\)](https://www.hyperagent.com/docs/billing/pricing-changes). No. An active paid plan always needs a valid card on file. Replace the card instead, or cancel the plan to stop future charges. See the remove-a-card section above. There is no self-serve refund for unused time. Contact Support if you believe you are owed one. --- # Pricing changes (August 2026) Source: https://www.hyperagent.com/docs/billing/pricing-changes > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. What happens to your account after the August 2026 pricing change, what action to take, and which billing options remain available. Nothing changes mid-period. Pay As You Go customers choose a monthly plan before their current period ends; monthly and annual subscribers transition automatically. [See what happens to your account](#what-happens-to-your-account). Hyperagent announced these changes on August 25, 2026, and began moving eligible accounts to the new plans on August 26, 2026. ## What happens to your account [#what-happens-to-your-account] Choose the billing option you want to understand. Pay As You Go is the only group that must take action. If you do nothing, agents stop running when your current monthly period ends. **Action required.** Choose a monthly plan in **Settings → Billing** before your current monthly period ends. There is no automatic plan assignment. **When it changes.** Usage-based billing ends at the close of your current monthly period. **Final billing.** Hyperagent issues a final true-up bill for any unpaid usage at the end of that period. The change took effect immediately and started a new billing period that day. Future renewals follow that date. See [Manage your plan](https://www.hyperagent.com/docs/billing/plans/manage-plan) for standard plan-change timing. Choose a monthly plan Your subscription moves automatically at the first billing cycle starting on or after August 26, 2026. **What stays the same.** Your monthly payment stays the same, and you don't need to choose a new plan to keep agents running. **What changes.** The early-user subscription bonus expires when the current period ends. The total credits included with your plan then change to reflect the new progressive bonus. **Your option.** Choose a different monthly amount in **Settings → Billing** before the cycle renews if the corresponding plan isn't right for you. Review your monthly plan No action is required during the term you have already paid for. **What stays the same.** Your annual terms remain in place, and credits continue refreshing each period until the paid term ends. **When it changes.** The annual plan doesn't renew. At the end of the term, your subscription moves automatically to the matching monthly plan. **Your option.** Choose a different monthly amount in **Settings → Billing** before the annual term ends. Choose your next monthly plan Supported GPT model usage can continue running against your ChatGPT subscription after the pricing change. **What it covers.** Supported GPT model usage runs against ChatGPT instead of using Hyperagent credits. **What still uses Hyperagent credits.** Other models, tools, media, search, and browser sessions continue billing through Hyperagent. **What you need.** Keep an active monthly Hyperagent plan, then [connect your ChatGPT subscription](https://www.hyperagent.com/docs/billing/plans/connect-chatgpt-subscription) through OAuth in **Settings → AI providers**. Connect your ChatGPT subscription Promotional, referral, incentive, and bonus credits aren't removed by this change. See [Credits already awarded to you](#credits-already-awarded-to-you). ## Choose a monthly plan [#choose-a-monthly-plan] You pay the plan price at the start of each billing period and receive that amount back as credit, plus a progressive bonus that grows with the plan. | Monthly price | Total credits | Bonus | | ------------- | ------------- | ----- | | $20 | $20 | 0% | | $50 | $55 | 10% | | $100 | $115 | 15% | | $200 | $240 | 20% | | $500 | $625 | 25% | | $1,000 | $1,300 | 30% | | $2,000 | $2,700 | 35% | | $5,000 | $7,000 | 40% | | $10,000 | $14,500 | 45% | ## How monthly plan credit works [#how-monthly-plan-credit-works] Credit from your monthly plan doesn't roll over. Any amount left expires when the period ends, and the next period starts with a new credit grant. New runs wait until the next billing period. Hyperagent doesn't charge anything beyond your plan price unless you opt in. Both options are opt-in. See [what happens when your balance runs low](https://www.hyperagent.com/docs/billing/credits#what-happens-when-your-balance-runs-low) for amounts, expiration, and controls. ## Credits already awarded to you [#credits-already-awarded-to-you] The pricing change doesn't remove promotional, referral, incentive, or bonus credits already awarded to your account. * Awarded credits remain until you use them or their individual expiry dates pass. * Their balances and expiry dates appear in **Settings → Billing**. * Hyperagent spends the credit with the nearest expiry date first. See [Credits](https://www.hyperagent.com/docs/billing/credits#when-credits-expire) for the complete expiration and spending-order rules. ## Special billing situations [#special-billing-situations] ## FAQs [#faqs] No. Pay As You Go ended with your current monthly period. Choose a monthly plan in **Settings → Billing** to keep agents running. No. Hyperagent honors the annual term you have already paid for, but it doesn't renew. At term end, the subscription moves to the matching monthly plan unless you choose a different monthly amount first. A plan change made during the migration took effect immediately and started a new billing period on that date. Future renewals follow the new date. There is no self-serve refund for unused time. Contact Support if you believe you are owed one. If an agent failed or looped and consumed credits, include the thread link and an estimate of the credits used. No. Awarded credits remain on your account until they expire, but agents can't run without an active monthly plan. --- # Shared Billing Source: https://www.hyperagent.com/docs/billing/shared-billing > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Put multiple members on one organization payment method, manage membership, and understand how existing credits move. Shared Billing puts multiple people on one billing organization. Every member's Hyperagent usage bills to the organization's payment method, and the Owner can manage membership and review combined usage. [Teams](https://www.hyperagent.com/docs/concepts/teams) are for organizing and sharing agents. They do not create a shared balance or change who pays. Shared Billing is a separate organization-level billing setup. ## How Shared Billing works [#how-shared-billing-works] An eligible Owner enables Shared Billing from **Settings → Billing**. Their billing account moves into a shared organization, and invited members begin billing usage to the organization's payment method after they join. The Owner can rename the billing organization, invite members, review pending invitations, and remove members. Once Shared Billing is active, workspace settings name the paying organization, so every member can see which organization their usage bills to. ## Requirements and limits [#requirements-and-limits] * Only the Owner can enable and manage Shared Billing. * The Owner must have a paid web plan. Apple-billed plans cannot enable it. * A person can belong to only one Shared Billing organization at a time. * Members cannot keep a separate personal plan while they belong to the organization. Their usage bills to the shared payment method. * Someone with an active Apple-billed subscription must cancel it in the App Store before joining. ## Enabling Shared Billing is one-way [#enabling-shared-billing-is-one-way] Enabling Shared Billing permanently moves the Owner's billing account into the organization. There is no self-serve action that returns the Owner to individual billing. Members can leave or be removed, which returns future usage to their own billing. The Owner cannot undo the shared setup themselves. Contact Support if Shared Billing was enabled by mistake. ## What happens to existing credits [#what-happens-to-existing-credits] Credits stay attached to the billing account where they were issued. * Credits on the Owner's account move into the Shared Billing organization and can cover member usage. * Credits on a member's personal account stay on that account after the member joins. They are not transferred to the organization and cannot be used while the personal account is dormant. ## Manage Shared Billing [#manage-shared-billing] Open **Settings → Billing** to manage the organization, invite or remove members, and review usage billed to the shared payment method. ## FAQs [#faqs] No. A member's usage moves to the organization's payment method while they belong to the Shared Billing organization. No. Enabling it is a one-way move for the Owner's billing account. Contact Support if it was enabled by mistake. No. Credits on a member's personal account stay there. Only credits already attached to the Owner's billing account move into the organization. When Shared Billing is active, workspace settings name the paying organization, so you can see which organization your usage bills to. --- # Changelog Source: https://www.hyperagent.com/docs/changelog > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Product and documentation updates for Hyperagent. --- # New models, cleaner threads, and consolidated billing for teams Source: https://www.hyperagent.com/docs/changelog/2026-07-22-weekly-updates > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Gemini 3.6 Flash, Inkling, thread status favicons, Cmd+K search, and shared team billing. Gemini 3.6 Flash and Inkling are now available across all Hyperagent threads: * **Gemini 3.6 Flash:** Fast, high-volume structured execution, monitoring, triage, research loops, coding, and a 1M-token context window. * **Inkling by Thinking Machines:** Multimodal knowledge work drawing across text, images, audio, and video with direct control over reasoning depth. You can now switch AI models directly from the header of any active thread, or configure a default model for your agent. Try different models on the task in front of you to see which one performs best. Every open thread now reports its live execution state directly through its browser favicon, letting you monitor agent progress across open tabs: * **Progress ring:** fills in the agent's colors while a turn is active * **Green checkmark:** indicates a finished turn ready for review * **Amber question mark:** flags an agent waiting on your response * **Red exclamation mark:** alerts you when an action requires explicit approval Command search received a major upgrade. Pressing **Cmd + K** now performs full-text search across thread titles, chat message content, document bodies, and tables. You can also start a thread with any agent, open a project, or jump directly to Library, Learnings, Command Center, or Integrations. Teams can now consolidate all Hyperagent usage onto a single organization bill. Instead of managing individual credit cards across team members, Organization Owners can set up a unified plan in **Settings → Billing** to manage seats, member usage, and spend in one place. Delegated child threads now nest neatly under their parent conversation on Home and in activity feeds. Parent agents can inspect subagent output while a child thread is actively running. ## Additional Improvements [#additional-improvements] ### Agent Workflows & Control [#agent-workflows--control] * **Nested Child Threads:** Subagent conversations nest under the main thread rather than cluttering your inbox. * **Live Subagent Inspection:** Agents can inspect intermediate progress and output while a subagent is running. ### Live Mode & Scheduled Monitoring [#live-mode--scheduled-monitoring] * **Clear Error Alerts:** Scheduled checks display visible error alerts in the thread header if a run encounters an issue. * **Automatic Pausing:** Background checks on live threads automatically pause after repeated errors to prevent runaway runs. * **Advanced Scheduling for Live Threads:** Jump directly from Live mode to full schedule settings when you need custom timing. ### Team Workspaces & Knowledge [#team-workspaces--knowledge] * **Team Agent Sharing:** Share agents across your team so team members can run them autonomously. * **Team Memories:** Memories stay securely attached to your team agents when sharing them across teams. * **Simpler Knowledge Setup:** Clearer steps to discover, link, and pin skills and memories on agents. * **Cleaner Memory Suggestions:** Duplicate learning suggestions are automatically filtered out. ### Search & Publishing [#search--publishing] * **Search Inside Documents:** Cmd + K now searches the text inside your documents, not just document titles. * **Smoother Message Streaming:** Chat messages stream faster and more reliably across all threads. * **Social Previews for Web Pages:** Shared links to published web pages automatically display rich title and preview cards. ### Mobile Improvements [#mobile-improvements] * **Smart Push Suppression:** Notifications are paused for the thread you are currently looking at on your phone. * **Notification Diagnostics:** Check whether push notifications are working properly on your device in settings. *** ## Fixes & Reliability [#fixes--reliability] * **Faster Large Workflows:** Improved performance when viewing complex threads. * **Auto-Recovery:** Chat automatically recovers if your browser connection drops or an extension disconnects. * **Better Browser Tool Errors:** Friendly error messages if a browser automation step encounters an issue. * **File Download Alerts:** Clear alert toasts appear if a file download fails. --- # Follow handoffs across your agent team Source: https://www.hyperagent.com/docs/changelog/2026-07-29-weekly-updates > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Trace your agent's handoffs, notifications when an agent needs you, and Kimi K3 and Claude Opus 5. When an [agent delegates](https://www.hyperagent.com/docs/concepts/agents/invocations/other-agents) work to another, the job stays under the original thread. You can see which agent is working, whether the run is still going, and what came back. Finished output stays with the agent that started it, so you do not have to search through separate chats to reconstruct the team’s work. Agents can keep moving without you watching every thread. When one needs an answer, access, or approval, the request surfaces in Agent Command Center. You get a clear place to handle the moments that need a person, then let the rest of the team keep going. Kimi K3 and Claude Opus 5 are the [lastest models available in Hyperagent](https://www.hyperagent.com/docs/concepts/agents/models) for agents that break complex jobs apart, hand work to specialists, and make the harder calls along the way. Both models offer fast mode for when you want more speed for a specific task. ## Additional improvements [#additional-improvements] * **Clearer model controls** Change your model right within your thread from the thread header. * **Smoother Slack setup for agents.** Deploy your agent to Slack with a single click. * **Find tables from Cmd+K.** Tables show up in product search with the rest of your work. * **Queued messages survive refresh.** A message waiting behind an active run stays attached after you reload. * **Retry failed sends.** If a send fails, you can retry from the error bubble instead of retyping. * **Only the schedule owner** can change Live write-access settings for that work. --- # Agents and autonomy updates Source: https://www.hyperagent.com/docs/changelog/2026-07-agents-and-autonomy > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Delegation, smarter setup, model controls, and clearer autonomy settings for agents. These updates make agents easier to direct, easier to configure, and better at handing work to each other. Mention another agent in a thread and Hyperagent hands off that part of the run, then brings the answer back into your thread. Agents can now call on other agents mid-run, without an @mention, so recurring delegated work happens automatically. The result comes back into the original thread. You control which agents each agent can delegate to. Override an agent's toolkit for a single thread without changing the agent itself. The Tools section is now editable right in the thread. Switch models right from the thread header. Click the model pill in the thread header to open the full picker. It shows context-window details, token usage, caching breakdown, and the thread's running cost, so you know where you stand before committing to a longer run. Set what an agent can do in threads you're watching separately from what it can do unattended on schedules and live runs. The agent editor's Access tab is now Autonomy. Run Live Mode on the cadence that fits, and see the estimated daily cost before you save. Choose every 2, 4, 8, or 12 hours, once a day, or a custom interval. Scheduled agents can stay quiet unless there's something that needs your attention. In the schedule editor, turn on "Only deliver when something needs attention." Scheduled runs can post their final report to a Slack channel instead of only writing it back to the original thread. Each subagent now gets its own browser session, and the canvas shows every active session in a grid with inline live views. Generated skill scripts are directly editable, so you can fix the last details yourself instead of regenerating the whole script. --- # Memory and learning updates Source: https://www.hyperagent.com/docs/changelog/2026-07-memory-and-learning > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Cleaner memories, a clear view of where each one came from, and bulk tools for managing what your agents know. These updates make agent knowledge easier to inspect, clean up, and reuse. Hyperagent now spots near-identical memories and groups them for review, with a similarity score for each group. Each group shows the best version alongside its duplicates. Resolve them one group at a time: keep the best one, merge them into a single clean memory, or skip the group. Resolve all keeps the best version in each group and archives the rest in one pass. Anything that isn't clearly safe to merge stays for manual review. Select memory cards, shift-click to grab a range, then archive, merge, pin, or link them to an agent from the selection bar. Every memory now links back to the thread it came from, so you can inspect the original exchange. Suggested learnings no longer pile up duplicates. Each new suggestion is checked against pending ones before it appears, so the strip stays short and useful. --- # Hyperagent now supports more models Source: https://www.hyperagent.com/docs/changelog/2026-07-new-models > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Pick from new Anthropic, OpenAI, Google, and open-source models for your agents. You can now pick from more models right from your thread. Sonnet 5, Fable 5, GPT 5.5, Gemini Flash 3.5, and open-source options including Kimi K2.6 and GLM 5.2 are now available in the model picker. The latest models appear first, and the full list is grouped by provider, so you can jump between Anthropic, OpenAI, Google, and open-source models without leaving the conversation. Threads started with an Anthropic model stay on Anthropic models, and threads started on other model families can't switch to Anthropic models. --- # Threads and layout updates Source: https://www.hyperagent.com/docs/changelog/2026-07-threads-and-workspace > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Better thread navigation, editable queued messages, richer references, and a cleaner thread canvas. These updates make threads easier to find, easier to reference, and easier to keep organized. When you send while an agent is mid-run, your message waits in a queue and stays editable. You can revise it before it sends, or use steering to push it into the current turn. Click the pencil icon to edit a queued message, including its attachments, while the agent keeps working. Your queue is saved to your account, so it'll still be there after a refresh or on another device. Fork thread clones the current context into a fresh thread, so you can explore a second path without losing the original. You can now search message content from the Threads page, not just thread names and summaries. Command-K now reaches deeper into your history, with results for messages, projects, and agents in one launcher. Highlight text in a reply or artifact and send that passage back into chat, so your follow-up carries the precise context. Thread controls moved into the prompt box: model, tools, and integrations are available in a compact popover, with the full drawer one click deeper. Add the conversations you live in to a Starred section at the top of the sidebar for easy access. Browser tabs now show when a thread finishes or needs you. The favicon and title update, so you can kick off multiple runs and scan the tab strip to see which one is waiting. New threads name themselves shortly after your first message, so the sidebar stays readable. Threads stay findable by name instead of showing up as a generic "New thread" label. Open screenshots and design mocks full-screen from chat. The canvas now has layout modes, window sorting, and folder docks for artifacts produced in a thread. Switch between side-by-side, grid, and stacked layouts from the toolbar band, sort windows by recency or title, and collapse related artifacts into a folder-style dock (a collapsible group). Agent-written documents now copy as Markdown, preserving structure when you move them into a wiki, handoff note, or review document. Filter the thread list to named agents, so quick generalist threads don't drown out organized work. --- # Team Memories, agent delegation, and model choice Source: https://www.hyperagent.com/docs/changelog/2026-08-12-team-memories > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Shared team memory that survives handoffs, agents that delegate with inspectable replays, model choice including open source, browser session replays, and full-library memory search. Your Team now has a shared memory library for operating knowledge. Team agents can save memories just to themselves, or share them with the Team Library. Link a memory to another agent without changing ownership. Promote an agent-owned memory into the Team's library while keeping the original agent connected. Or move a library memory into one agent, resetting its previous links so only that target agent keeps access. [Delegation gets powerful fast.](https://www.hyperagent.com/docs/concepts/agents/invocations/other-agents) It should also come with clear boundaries. Now, you can now decide which agents may invoke your agent via delegation. A more sensitive payroll agent can stay closed to inbound delegation requests, while a research agent remains available across the entire team. Together, those boundaries make agent-to-agent delegation governable as your agent-team grows. Browser work used to lose its visual evidence when the session closed. A completed browser session can now be saved as a video file in the thread, so the clicks, pages, and final state remain available for review. Open Files to replay an agent's browser actions, verify work on login-gated sites, or keep a durable record for debugging or approval. Personal memory search now covers the complete library. Filter counts reflect every match rather than the current page, and the By Agent section paginates beyond the first 50 memories. Search for a phrase, trust the totals beside each filter, and keep browsing agent groups without losing results. ## Additional improvements [#additional-improvements] * **Documents survive Team handoffs.** Attached documents travel with a thread when its ownership moves between personal and Team. Read-only viewers see read-only controls. * **Admin model defaults carry into every new agent.** The default model chosen by an organization administrator appears consistently on creation previews, agent configuration, and tool-generated drafts. * **Delegated threads replay from Activity.** Open a delegated entry from the parent thread's Activity feed to inspect the specialist's full run with agent identity, status, and authorized artifacts. * **Failed uploads recover automatically.** The composer retries a transient pre-signed upload failure instead of dropping the file. * **Edit skill documentation inline.** Open a skill and edit its documentation directly on the detail page. Credential setup prefills the inferred host from existing scripts. Team credentials stay visible only to Owners and Editors. * **Allowlist runs that may use saved browser logins.** Team owners can restrict which agent runs may attach a saved browser profile. The browser login view emphasizes meaningful authentication domains. --- # New models, shared agent context, and clearer controls Source: https://www.hyperagent.com/docs/changelog/2026-08-13-product-updates > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Four new models, shared context across agent teams, deeper knowledge search, safer agent editing, and clearer Slack setup. This release adds more model choices and gives teams clearer control over agent knowledge, configuration, Slack access, and delegated work. Choose from four new models based on the context, volume, and depth your work requires. * **Gemini 3.7 Flash:** Review and compare large document sets, such as ten vendor proposals and a set of evaluation criteria. A job at that scale usually costs tens of cents in model usage, depending on the files and number of retries. * **MiniMax M3:** Work across process documents, customer notes, sales transcripts, pricing sheets, and product documentation. Try it as a lower-cost option for searching a large internal knowledge base. * **DeepSeek V4 Flash:** Handle high-volume coding and tool work, including routine bug fixes, integration updates, tests, and repetitive technical tasks. It's currently the lowest-cost model available in Hyperagent. * **Grok 4.6:** Complete longer research and analysis assignments that end in a decision-ready brief, market assessment, or competitor comparison. It costs more than the other three models, so use it when sustained analysis is worth the additional spend. Learn more in [Models](https://www.hyperagent.com/docs/concepts/agents/models). Agents in [Teams](https://www.hyperagent.com/docs/concepts/teams) can now work from shared [memories](https://www.hyperagent.com/docs/concepts/memories), [skills](https://www.hyperagent.com/docs/concepts/skills), and documents in the [Library](https://www.hyperagent.com/docs/concepts/library). When an agent delegates work, the specialist receives the relevant context. The result returns to the original thread, keeping the full assignment and its handoffs together. Learn how context travels in [Agent delegation](https://www.hyperagent.com/docs/concepts/agents/invocations/other-agents). [Library](https://www.hyperagent.com/docs/concepts/library) search now uses text inside document sections and table descriptions, along with exact terms and meaning. You can find the right document or table using a phrase from its contents without knowing its title. [Team memories and an agent's learned memories](https://www.hyperagent.com/docs/concepts/memories) use relevance-based retrieval too. Search for a topic or detail even when your wording doesn't match the title. Tables now include a purpose description and generated tags. Agents can find tables from other threads when you have access to them. Changes in [agent configuration](https://www.hyperagent.com/docs/concepts/agents/configuration) now stay in one editable draft, including identity, invocation settings, context, memories, and model. Review the complete set of changes, then use Save or Discard to apply or revert them together. Dedicated Slack apps can now find people by name or email, so agents can mention or prepare a direct message for the right person. Slack setup shows when admin approval is pending, denied, or complete. It also displays a reconnect notice when the bot token is no longer valid. The channel picker refreshes stale data and invites the bot when a newly granted channel requires it. From Bot identity, you can move the agent's app to another connected Slack workspace. Learn more in [Slack](https://www.hyperagent.com/docs/integrations/slack). ## Additional improvements [#additional-improvements] * **Clearer agent creation.** New-agent setup names the configured default model from [agent configuration](https://www.hyperagent.com/docs/concepts/agents/configuration). When required information is missing, the create control explains what you need to add. * **Saved thread views.** Switch between list and grid views across [Threads](https://www.hyperagent.com/docs/concepts/threads) with one saved preference. * **Nested delegated threads.** Expand [delegated child threads](https://www.hyperagent.com/docs/concepts/agents/invocations/other-agents) beneath their parent instead of scanning them as separate top-level conversations. * **Control thread knowledge.** Choose "Include in knowledge" or "Exclude from knowledge" from a thread's actions menu. Learn more in [Knowledge access](https://www.hyperagent.com/docs/concepts/agents/knowledge-access). * **Clearer schedule details.** Agent pages show author-given schedule names, and weekday controls follow the ordering used by your locale. Learn more in [Invocations](https://www.hyperagent.com/docs/concepts/agents/invocations). * **Restore scheduled destinations.** Restoring an agent version preserves its [scheduled delivery destinations](https://www.hyperagent.com/docs/concepts/agents/invocations). * **Preview skills and memories.** The @mention picker distinguishes similarly named [skills](https://www.hyperagent.com/docs/concepts/skills) and [memories](https://www.hyperagent.com/docs/concepts/memories) with previews. In a new thread, choices are scoped to the selected agent. --- # More capable agents with visible control Source: https://www.hyperagent.com/docs/changelog/2026-08-20-more-capable-agents-visible-control > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Approve external writes from Inbox, recall relevant work in fresh threads, review community skills before installing, and inspect lasting changes. Your agents can ask you before taking sensitive actions like writing to external systems or updating their configurations. Now you can review those asks all from one place. Your inbox surfaces asks from multiple agents and allows you to approve or deny requests, and open the thread to provide more instructions or context. When installing community skills from skills.sh in the Marketplace, you can now review the files and content advisory before installation. Review the files and content advisory, then install the exact content you approved. The installed skill keeps its skills.sh origin and a link to the listing. Learn more in [Skills](https://www.hyperagent.com/docs/concepts/skills). A fresh thread can bring in relevant prior conversations, memories, and skills before the first answer. You can see which context shaped the first response through the knowledge hints that appear, and click in to each to inspect the prior work. Learn more in [Threads](https://www.hyperagent.com/docs/concepts/threads) and [Memories](https://www.hyperagent.com/docs/concepts/memories). When a thread's context fills beyond your desired threshold, use the Compact context option. From the thread header, click the model name and choose Compact context now from the menu. You can also use `/compact`, or set an auto-compact threshold on your agent's settings. After compaction, the agent can retrieve stored work instead of guessing from a shortened summary. Learn more in [Threads](https://www.hyperagent.com/docs/concepts/threads). When your agent spins up a browser to navigate a site or an app, you can now record the session as a demo. The recording captures the browser's state and actions, and is saved as an mp4 with captions, a visible cursor, smooth scrolling, and click zooms. Use the recording as a shareable walkthrough of the completed browser task. When an agent auto-saves a memory, it creates a receipt in the thread. The receipt shows what the agent saved and why, and links to the memory for you to further inspect. Open the receipt to inspect the saved detail. Archive the memory if it should not last. Learn more in [Memories](https://www.hyperagent.com/docs/concepts/memories). ## Additional improvements [#additional-improvements] * **Edit proposed learnings.** Rubric and skill proposals arrive as editable drafts that you can change, save, or dismiss. * **Take over a live browser.** Watch the browser, open it in a new window, or take over browsing with an address bar, forward, back, and refresh buttons. Hand the page back when you finish, and the agent continues from the same state. * **Check generated webpages.** Hyperagent checks a generated webpage for clean rendering before the agent calls it ready. * **Run shared skills.** A shared personal agent can use its author's working skill connection, so teammates do not have to repeat setup. * **Switch Slack identities.** Move an agent from the shared Hyperagent identity to a dedicated Slack app while keeping its connected channel. * **Start group DMs.** A dedicated Slack app can open a group DM with teammates and send the first message. --- # Agents Source: https://www.hyperagent.com/docs/concepts/agents > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Shape a job once, then hand it to an agent: a teammate that runs it with its own tools and knowledge, wherever the work shows up. Somewhere in your week there's a job you've already figured out: pull the pipeline, check it against last week, write it up the way the team likes it. An **agent** is the teammate you hand that job to. It carries the brief, the tools to do the work, and the knowledge to do it your way, and it's on call wherever the work shows up. The agent runs it with its own tools and knowledge, wherever the work arrives: a thread, a schedule, your team's Slack. Same teammate, same standards, every time. ## When a job deserves an agent [#when-a-job-deserves-an-agent] A fresh thread is enough for a one-off question or unfamiliar work. Create an agent when the responsibility itself has become reusable. A weekly pipeline brief, support triage, launch production, or another job with a recognizable finished result. The role uses recurring standards, tools, source material, or judgment that would otherwise need to be explained in every thread. You start it every week, the calendar starts it, teammates ask for it, or a system sends the same kind of event. The agent gives that responsibility a name and a durable home. Update its instructions, connect an integration, or teach it a skill, and the next job reaches the same role wherever it starts. ## What an agent brings to the job [#what-an-agent-brings-to-the-job] The identity and standing instructions: what the job is, what good looks like, how to work with you. Written once, read on every run. See [Configuration](https://www.hyperagent.com/docs/concepts/agents/configuration). The default model, reasoning effort, runtime, subagent model, turn timeout, and context controls that fit the work. See [Models and compute](https://www.hyperagent.com/docs/concepts/agents/models). Built-in capabilities like search, browsing, and code, plus the apps you've connected: Slack, your CRM, your sheets. See [Tools and integrations](https://www.hyperagent.com/docs/tools). The [memories](https://www.hyperagent.com/docs/concepts/memories) it draws on, the [skills](https://www.hyperagent.com/docs/concepts/skills) it follows, and the files you've attached, plus what it's allowed to learn from its own runs. See [Knowledge access](https://www.hyperagent.com/docs/concepts/agents/knowledge-access). Its usual execution mode, approval behavior, and permission to hand work to another agent. These settings control how independently it may act. A thread when you ask, a schedule when the calendar does, Slack when the team does. See [Invocations](https://www.hyperagent.com/docs/concepts/agents/invocations). ## The same teammate, everywhere it works [#the-same-teammate-everywhere-it-works] Put the same agent on a schedule, bring it into Slack, or give it an email address. Every run starts with the same instructions, tools, and standards. See [Invocations](https://www.hyperagent.com/docs/concepts/agents/invocations) for more on how you can run your agents from anywhere. Put recurring work on the calendar so the agent runs it on time and delivers the result where it belongs. Bring the agent into channels and DMs so teammates can reach it where they already work. Give the agent an inbox so forwarded messages can start work and replies can stay in the conversation. ## What it remembers between jobs [#what-it-remembers-between-jobs] Skills, memories, and documents are durable knowledge. The earlier conversation stays in its thread unless the agent is allowed to search it or preserve something it learned. See [Knowledge](https://www.hyperagent.com/docs/knowledge) for more detail. Reusable methods for doing the work: a research process, report format, brand voice, API pattern, or checklist. Small standing facts and preferences the agent can retrieve in future runs, without asking you to explain them again. Larger bodies of reference material the agent reads and keeps current: structured, versioned, and available across the threads that should see it. ## How an agent completes work [#how-an-agent-completes-work] Take a **Pipeline Analyst** that owns the Monday morning brief. It knows the format leadership expects, can reach the CRM, and compares this week's pipeline with the last one. ### Work reaches the agent [#work-reaches-the-agent] At 7 AM Monday, a saved [schedule](https://www.hyperagent.com/docs/concepts/agents/invocations/schedules) sends the recurring request. A thread, Slack mention, email, webhook, or another agent could start the same role through a different [invocation](https://www.hyperagent.com/docs/concepts/agents/invocations). ### The agent loads its working setup [#the-agent-loads-its-working-setup] The Pipeline Analyst brings the same instructions, model defaults, CRM connection, tools, reporting skill, memories, and autonomy settings to the run. The invocation supplies the request; the agent supplies how the work should be done. ### The run happens in a thread [#the-run-happens-in-a-thread] The thread holds the request, tool calls, working files, approvals, and finished brief. It remains the complete record even when the result is also delivered to Slack or another destination. ### Review improves the next run [#review-improves-the-next-run] Open the thread from [Activity](https://www.hyperagent.com/docs/concepts/agents/activity). Clarify the instructions when the role was unclear, save a repeatable method as a skill, or preserve a standing fact as a memory. ## Where to go next [#where-to-go-next] Each part of the role has its own page. Start with whichever decision you're making. ## FAQs [#faqs] Because conversation history doesn't cross threads. Each run starts fresh in its own thread by design, so nothing from an earlier conversation leaks into the next one. The way to carry things forward is [memories](https://www.hyperagent.com/docs/concepts/memories) for standing facts and [skills](https://www.hyperagent.com/docs/concepts/skills) for methods, both of which the agent reads on every run regardless of thread. No. An agent's system prompt is copied into a thread when that thread is created, so later edits shape the next run rather than rewriting conversations already in flight. Connecting a tool or attaching a skill likewise applies from the next turn onward. Make a new agent when the responsibility is genuinely different: a different audience, operating style, or outcome that would need its own instructions and tools. Improve the existing one when it's the same job done better. If you find yourself writing conflicting instructions into a single system prompt, that's usually the signal to split the role. --- # Activity Source: https://www.hyperagent.com/docs/concepts/agents/activity > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. The agent's own thread history: every run it has done, live and interactive alike, with search and filters, each row opening the thread behind it. When an agent runs on its own, on a schedule, in Slack, from a webhook, you need somewhere to see what it has been doing. **Activity** is that place: the agent's own history of runs, one row per thread, each opening the conversation behind it. It is where you watch a working agent rather than configure it. Every run an agent does becomes a thread, and the Activity tab lists them all, live runs and conversations together, so you can open any one and see exactly what happened. The complete run history for one named agent. Open any row to inspect its thread, tools, approvals, files, and output. The fleet-wide view across every agent you operate: active work, decisions, cost, and quality trends. ## Open the agent's history [#open-the-agents-history] Activity is a tab on the agent's own page, alongside Overview, Instructions, Autonomy, Knowledge, Integrations, Invocations, and Tools. Open an agent and select **Activity**, or go straight to it at `/agents/:id?page=activity`. It is scoped to that one agent: this is the agent's history. The fleet-wide view across every agent you operate is the [Command Center](https://www.hyperagent.com/docs/concepts/command-center). ## What each row is [#what-each-row-is] Every row is one **thread**, which is one run or conversation the agent handled, and it links straight to that thread at `/thread/:id`. A background run started by a [schedule](https://www.hyperagent.com/docs/concepts/agents/invocations/schedules), Live Mode, or a webhook lands in the same list as a conversation you had by hand, so the whole of what the agent has done sits in one timeline. Opening a row is how you audit a run: the thread holds the complete record of what the agent read, did, and produced. The **Search threads...** input narrows the list to matching runs, so you can find one conversation among a long history. The **Filter threads** control scopes which of the agent's threads are listed; on a shared agent, that includes narrowing to your own runs versus everyone's. ## Turn on Live Mode from here [#turn-on-live-mode-from-here] When an agent isn't on a schedule yet, Activity is also where you start one. A **Live** card at the top of the list offers **Set up Live Mode**: turn it on and the agent checks in on a schedule, with each run landing in this list and a notification only when something needs you. Once Live Mode is on, its scheduled runs appear in Activity right beside the threads you started, so the tab is the single record of the agent working, whether you kicked it off or the schedule did. See [Live Mode](https://www.hyperagent.com/docs/concepts/agents/invocations/live-mode). ## Where to look for cost [#where-to-look-for-cost] Activity answers "what has this agent done," not "what has it spent." Cost lives on the agent's Overview, switchable between total, per run, and per thread, and the [Usage tab](https://www.hyperagent.com/docs/concepts/threads/thread-settings#see-what-a-run-has-cost) inside any single thread breaks down that one run. ## FAQs [#faqs] Yes, but it isn't this tab. The [Command Center](https://www.hyperagent.com/docs/concepts/command-center) is the fleet-wide dashboard: active operations, items needing attention, and cost and score trends across every agent. Activity is the per-agent drill-down you land on from there. Yes. Every run becomes a thread, whatever started it, so schedules, Live Mode, Slack, Telegram, webhooks, and hand-started conversations all appear in the same list. Each opens the thread with the full record of that run. Yes. Each row links to its thread, which holds the complete transcript: the messages, tool calls, approvals, and outputs. That is the place to audit a run rather than a status badge. --- # Other agents Source: https://www.hyperagent.com/docs/concepts/agents/agent-delegation > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Let one named agent hand specialist work to another. This page now lives with the other ways an agent can be invoked. **[Open Other agents →](https://www.hyperagent.com/docs/concepts/agents/invocations/other-agents)** --- # Configuration Source: https://www.hyperagent.com/docs/concepts/agents/configuration > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Set up each part of an agent — its brief, autonomy, knowledge, integrations, doorways, and tools. You want an agent to produce work you recognize, even when the request arrives next week or through a different channel. Its **configuration** is the durable contract behind that consistency: the responsibility it owns, the standards it follows, the resources it can use, and the boundaries it works within. An agent's configuration describes how it should work across many jobs. The request, source material, and finished output for one job belong in its thread. Everything below lives in one place. Open **Agents** in the sidebar and click your agent: the configuration tabs run across the top of its page — **Instructions**, **Autonomy**, **Knowledge**, and **Integrations**, with **Invocations** and **Tools** under **More**. The sections here follow that same order. ## Set up each part [#set-up-each-part] ### Give it a brief and a model [#give-it-a-brief-and-a-model] Instructions are the role itself: who the agent works for, what finished work looks like, and the judgment calls it should make without asking. The model settings underneath decide how much thinking each new thread starts with. On the agent's page, open the **Instructions** tab: * Write the **System prompt** — the responsibility the agent owns, the standards its output must meet, and how it should decide when you're not there. Keep reusable methods and standing facts out of it; those belong in [skills](https://www.hyperagent.com/docs/concepts/skills) and [memories](https://www.hyperagent.com/docs/concepts/memories), where they can grow without a prompt rewrite. * Under **Model and limits**, pick the **Model** new threads start with, and the **Subagent model** for workers it dispatches. Match the compute to the work, not the agent's title — see [Models and compute](https://www.hyperagent.com/docs/concepts/agents/models). * **Turn timeout** caps how long one run may go before it's stopped; runs inherit it unless their invocation sets its own. **Budget limit per query** caps spend per request. ### Decide what it may do on its own [#decide-what-it-may-do-on-its-own] Reading and drafting carry different consequences from sending messages or changing records. Autonomy sets the default posture once, from the consequences of the work. On the agent's page, open the **Autonomy** tab: * Set **When you're in conversation** to **Auto** (runs end-to-end) or **Ask first** (pauses for your approval before sensitive actions). Ask first needs you present to answer, so it applies in conversation; any thread can [override it for itself](https://www.hyperagent.com/docs/concepts/threads/thread-settings#autonomy--safety). Scheduled and live runs are governed separately, by each schedule's own rules in Invocations. * Under **Agent delegation**, choose whether this agent may hand work to other agents, and to which ones — an explicit allowlist, or a mode that includes your other agents automatically. Leave **Ask for approval** on to see each handoff before it runs. See [Other agents](https://www.hyperagent.com/docs/concepts/agents/invocations/other-agents) for how a delegated run works. ### Choose what it knows and how it learns [#choose-what-it-knows-and-how-it-learns] Knowledge is what the agent brings to the work beyond its prompt: the memories and skills it may reach, the documents it always carries, and what it's allowed to keep from its own runs. On the agent's page, open the **Knowledge** tab and pick a **Knowledge profile** to define how the agent learns. **Synced self-learning** shares your full library and learns as it works; **Curated** sees only what you add and doesn't learn on its own; **Standalone** keeps what it learns to itself; **Custom** lets you set each control yourself. See [Knowledge access](https://www.hyperagent.com/docs/concepts/agents/knowledge-access) for more detail. ### Give your agent the right context [#give-your-agent-the-right-context] Choose which memories the agent can see, and where its new lessons are saved: shared with your other agents, or private to this one. Let it reach every skill you've saved, or turn that off and attach the specific skills the role needs with **+**. Pin the documents the agent should carry into every run, like a working outline or a standards doc. ### Connect the services it works in [#connect-the-services-it-works-in] Integrations are the external systems the agent may act in — email, calendars, CRMs, databases. Each card is a service; each chip under it is an account the agent may use. On the agent's page, open the **Integrations** tab: * Click **+** in the corner to add a service, or **+ Add account** on a card to connect another account for one it already has. * Remove an account chip to narrow the agent to the accounts its job actually needs. Start from the responsibility and grant no broader. Browse what's available in [Integrations](https://www.hyperagent.com/docs/integrations), or go straight to [Slack](https://www.hyperagent.com/docs/integrations/slack), [HubSpot](https://www.hyperagent.com/docs/integrations/hubspot), [Databricks](https://www.hyperagent.com/docs/integrations/databricks), or [custom MCP servers](https://www.hyperagent.com/docs/integrations/custom-mcp). ### Bring your agent to where your work is [#bring-your-agent-to-where-your-work-is] The same configured role can be reached from a thread, a schedule, Slack, email, a webhook, or another agent. Each row on this tab is one doorway, with its own setup. On the agent's page, choose **Invocations**: * **Thread** is on from the start — that's chatting with the agent in the app. * Choose how and where the agent should start and deliver work: on a schedule, through [Live mode](https://www.hyperagent.com/docs/concepts/agents/invocations/live-mode), in Slack or Telegram, by email, or through another invocation. Learn more about [Invocations](https://www.hyperagent.com/docs/concepts/agents/invocations) to pick the right channel for your agent, including [Telegram](https://www.hyperagent.com/docs/concepts/agents/invocations/telegram). ### Enable its built-in capabilities [#enable-its-built-in-capabilities] Tools are what the agent can do directly — search the web, drive a browser, run code, generate media. Instructions define the responsibility; tools decide which parts of it the agent can execute itself. * Toggle each capability on or off. They're grouped — research, browser, data and code, documents, media — so related tools travel together. * Use **Smart pick** to have a sensible set chosen from the agent's role, or **All** / **None** to start from either end. * Enable the smallest useful set: add a tool when the work requires it, not because it might be useful someday. Go deeper on [research](https://www.hyperagent.com/docs/tools/research), the [browser](https://www.hyperagent.com/docs/tools/browser), [data and code](https://www.hyperagent.com/docs/tools/data-and-code), [webpages and slides](https://www.hyperagent.com/docs/tools/webpages-and-slides), or [media generation](https://www.hyperagent.com/docs/tools/media-generation). ## Test it before you put it on call [#test-it-before-you-put-it-on-call] A configuration is a working hypothesis about how the agent should perform. Test it with real work before teammates or automations depend on it. Give the agent a realistic assignment with the source material, ambiguity, and quality bar it will face in practice. A polished demo prompt hides the gaps you need to find. Inspect what the agent read, which tools and integrations it used, where it paused, and what it produced. Fix the configuration from evidence in the run rather than from the final answer alone. Clarify the role in Instructions. Save a repeatable method as a [skill](https://www.hyperagent.com/docs/concepts/skills), a standing fact as a [memory](https://www.hyperagent.com/docs/concepts/memories), and larger source material as a [document](https://www.hyperagent.com/docs/knowledge/documents-and-tables). If the agent will run from a schedule, Slack, email, or another invocation, test it there. Unattended work exposes missing context, permissions, approvals, and delivery choices that an interactive thread can hide. A thread keeps the instructions, model, and runtime it started with. Test edits in a new thread, and use configuration history to restore an earlier version when a change misses the mark. ## FAQs [#faqs] No. A thread keeps the instructions it started with. The edit applies to new threads, while existing work remains a faithful record of the role and settings it began with. See [Thread settings](https://www.hyperagent.com/docs/concepts/threads/thread-settings) for how a thread inherits and overrides the agent's defaults. Instructions define the role and its standing standards. [Skills](https://www.hyperagent.com/docs/concepts/skills) hold reusable methods. [Memories](https://www.hyperagent.com/docs/concepts/memories) hold facts and preferences. [Documents](https://www.hyperagent.com/docs/knowledge/documents-and-tables) hold larger sources the agent should consult. Keeping those layers separate lets each one evolve without destabilizing the others. The configuration stays consistent, but each [thread](https://www.hyperagent.com/docs/concepts/threads) brings a different assignment, source material, conversation, and set of decisions. The agent is the same teammate; the thread is the work in front of it. Every save records a version snapshot. Open the agent's configuration history to review earlier versions and restore the one you want. --- # Invocations Source: https://www.hyperagent.com/docs/concepts/agents/invocations > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Choose where a named agent shows up and what can start its work: time, channels, systems, or another agent. Once a named agent has a job, choose where it should show up like a coworker. It might prepare the report every Monday, answer the team in Slack, receive work by email, or take a specialist handoff from another agent. An **invocation** is any way that agent's work starts besides you opening a thread and asking. The invocation supplies the trigger; the named agent brings its identity, instructions, model, tools, and knowledge. The work still happens in a thread. Save the agent first, then add the places and events that may start its work. Each invocation belongs to that agent and uses its configuration. A temporary thread without a named agent cannot have schedules, channels, endpoints, or requests from other agents attached to it. ## Four ways a run starts [#four-ways-a-run-starts] A thread. This is where every job begins its life: you watch the agent work, correct it, and refine the process before trusting anything to run alone. [Schedules](https://www.hyperagent.com/docs/concepts/agents/invocations/schedules) produce a deliverable on a recurrence. [Live Mode](https://www.hyperagent.com/docs/concepts/agents/invocations/live-mode) watches something and alerts you when it matters. Both run with nobody at the keyboard. A request in Slack, an email in the inbox, an event from your systems. The work arrives where it already happens, and the run starts there. A named agent hands specialist work to [another agent](https://www.hyperagent.com/docs/concepts/agents/invocations/other-agents), which runs in its own thread and returns the result to the caller. ## What every invocation shares [#what-every-invocation-shares] The subpages cover each doorway in detail. Four rules hold across all of them, and knowing them makes every subpage easier to read. **The thread is the record.** Every run lands in one. The invocation decides whether each run gets a fresh thread or accumulates in a continuing one, and that choice shapes what the agent remembers between runs. **Trust is granted per doorway.** A run started by outside content begins with less: schedules default to read-only, email addresses take sender allowlists, webhooks want their secret. You loosen each doorway on its own terms, and loosening one never loosens another. **Delivery is not access.** Sending a result to Slack never grants the agent Slack write access. Reporting and permission are separate systems everywhere, which is why a read-only run can still deliver its report. **Every invocation has an owner.** Runs execute with the context of whoever configured the invocation, and count against their usage. If the owner leaves the workspace, the invocation pauses rather than run as a ghost. ## Which invocation fits the job [#which-invocation-fits-the-job] ## Start attended, then automate [#start-attended-then-automate] The invocations aren't a menu to fill out on day one. Most agents earn them in order: ### Shape the job in a thread [#shape-the-job-in-a-thread] Run the work interactively until the output is right more often than not. This is where you find out what the agent needs: sources, format, the standard. ### Put it on one trigger [#put-it-on-one-trigger] Once the job is stable, give it the one invocation that matches how the work arrives: a schedule if it's calendar-shaped, Slack if the team asks for it, a webhook if a system produces it. ### Widen trust as it earns it [#widen-trust-as-it-earns-it] Start read-only, watch the runs, then loosen the write level or the sender list once you've seen it succeed enough to trust. ## FAQs [#faqs] Yes, and mature agents usually do: a Slack presence for the team, a schedule for the weekly report, a webhook from the CRM. Each one is configured, trusted, and paused independently. The invocation's owner. A teammate mentioning your agent in Slack, or a webhook firing from a partner system, runs with your configuration and counts against your usage. That's also why trust is scoped per doorway. That's what the per-doorway controls are for. External runs start with less trust by default: read-only write levels, allowlists, secrets. The subpage for each doorway covers exactly what its controls protect. --- # Email Source: https://www.hyperagent.com/docs/concepts/agents/invocations/email > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Give an agent its own email address: control who may send, turn messages into threaded work, and let the agent reply or deliver updates. You want to forward an invoice, support ticket, or lead to an agent and have it pick up the work on its own, the way you would hand it to a colleague. An **email address** gives the agent that doorway: mail sent to the address starts a run, the message becomes the briefing, and the agent can reply from the same address when you allow it. Mail to the agent's address becomes a run, framed by a prompt template you write. You decide who may send, whether files come through, and whether the agent writes back. ## How email works [#how-email-works] Each email address belongs to one agent. Messages sent there can start runs without someone opening Hyperagent first. Incoming mail must pass sender authentication. Your allow list then decides which authenticated senders may invoke the agent. A prompt template turns the sender, subject, body, date, and attachments into the instructions the agent receives in its thread. With replies on, one email conversation maps to one Hyperagent thread. You can also let the agent start an email to you. ## Create and configure an email address [#create-and-configure-an-email-address] On the agent's **Invocations** tab, open the **Email** card and select **Create Email Address**. The form controls the address, the briefing each message creates, who may send, and whether the agent can answer. ### Name the address [#name-the-address] Choose the readable start of the address. Hyperagent adds a random suffix and your deployment's email domain. ### Frame the work [#frame-the-work] Write the prompt template that introduces each message to the agent. If replies are off, you can also tell the agent how to name each new thread. ### Set access and file handling [#set-access-and-file-handling] Add exact senders or domains, then decide whether attachments should enter the thread with the message. ### Choose the conversation behavior [#choose-the-conversation-behavior] Decide whether the agent may reply and whether it may start a new email conversation with you. ## Email configuration options [#email-configuration-options] ## Control who can trigger the agent [#control-who-can-trigger-the-agent] Every inbound message clears two gates: the receiving mail service must authenticate it, and the sender must satisfy the address's **Allowed Senders** rules. ### Allowed senders [#allowed-senders] Leave the list empty to accept any authenticated sender. This works for public intake, but it lets more people invoke the agent. A line such as `alice@example.com` matches that address and no one else. A line beginning with `@`, such as `@company.com`, admits every sender at that domain by matching the end of the address. Enter one rule per line. There is no wildcard or separate subdomain syntax, and Hyperagent stores patterns in lowercase so matching is case-insensitive. Once the list contains a rule, unmatched senders are rejected silently. An empty list creates an open inbox for any authenticated sender. Use exact addresses or domains when the agent can write to connected systems or take other consequential actions. Virus, spam, authentication, replay, size, rate-limit, paused-address, and allow-list failures are silent. A bounce would confirm that the address is live or reveal its sender rules. When a run row already exists, the failure reason appears there for you instead. ### What an accepted sender can do [#what-an-accepted-sender-can-do] Email-invoked runs use the agent's normal tools and integration access; they aren't forced into the read-only behavior a standard schedule starts with. The allow list is therefore both an entry gate and a trust boundary. An open inbox authorizes accepted mail for ordinary work. When a sender matches a populated allow list, Hyperagent treats that sender as explicitly trusted, which also lets the email-invoked run delegate work to subagents on their behalf. ## Choose how email conversations work [#choose-how-email-conversations-work] ### Reply behavior and threading [#reply-behavior-and-threading] Every inbound message opens its own thread, named from the **Thread naming hint**. The agent does the work without answering by email. Messages in one email conversation continue in one Hyperagent thread, and the agent can reply from its own address. With replies on, Hyperagent follows the standard `In-Reply-To` and `References` headers to find the thread a message belongs to. The agent's replies come from `{slug}-{suffix}@your-domain`, using the agent's name as the display name. The agent can't change the From address, and the subject remains `Re:` plus the original without accumulating prefixes. ### Let the agent email you first [#let-the-agent-email-you-first] **Start Email Conversations** is off by default and becomes available when **Reply to Email** is on. Enabling it gives the agent the **Send Email** tool so it can start an email to you, its run owner. It can't use this setting to email arbitrary addresses. Your reply returns to the originating thread through an agent-initiated exception, even if your address isn't on the allow list. Scheduled and Live Mode email delivery use this outbound path. ## Operate and monitor an address [#operate-and-monitor-an-address] Each address is managed independently, including its state, test runs, settings, and history. ### Pause, resume, or archive [#pause-resume-or-archive] An address can be **active**, **paused**, or **archived**. Pausing stops inbound mail from starting runs without deleting the address or its history; resuming turns it back on. You can pause, resume, edit, test, or delete one address without affecting another address on the same agent. ### Test the configuration [#test-the-configuration] **Send Test Email** opens a dialog where you enter a From address, subject, and body. The To address is fixed to the email invocation you're testing. A test skips SES delivery and the replay guard so you can exercise the prompt template and reply behavior end to end. If the agent replies, Hyperagent redirects that reply to your own email instead of the simulated sender. ### Review Recent Emails [#review-recent-emails] The **Recent Emails** section on the address detail page logs what has arrived. Each row shows a status badge, sender address, when the run started, its duration, and a link to the thread. Before anything arrives, it reads `No emails received yet`. A failed run shows its error beneath the row. ### Ownership on team agents [#ownership-on-team-agents] Multiple workspace members can see and edit an agent's email addresses, but each address has one runtime owner: the member whose context and usage the runs execute under. If the runtime owner leaves the workspace, the address pauses instead of running without an owner. Any remaining member can resume it, which makes that member the new runtime owner. ## Deliver scheduled and Live Mode updates [#deliver-scheduled-and-live-mode-updates] A [scheduled](https://www.hyperagent.com/docs/concepts/agents/invocations/schedules) run or [Live Mode](https://www.hyperagent.com/docs/concepts/agents/invocations/live-mode) watch needs an active email address on the same agent before it can deliver updates by email. The address gives the run a valid From address, and **Start Email Conversations** provides the outbound path to the run owner. Set up an email invocation for this agent to start receiving alerts. The warning's **Set up** button opens the **Create Email Address** dialog. Once an active address exists, email becomes a valid delivery channel and the warning clears. ## Troubleshooting and FAQs [#troubleshooting-and-faqs] Most often the sender isn't on a populated allow list, so the message was rejected silently. Other silent drops include a virus or spam verdict, a message over the 30 MB size limit, hitting the per-sender rate limit, a paused address, or failed authentication, such as a spoofed From address or mail forwarded through an untrusted ARC sealer. If a run row exists in Recent Emails, its error says which check failed. Yes. Turn on **Start Email Conversations**, which requires **Reply to Email**. The agent can then email you, its run owner—not arbitrary addresses—and your reply returns to the same thread. Scheduled and Live Mode email delivery use this behavior too. No. With **Reply to Email** off, each message opens its own thread and the agent works without answering by email. Both replying and starting an email require the reply switch to be on. Yes, within reason. The random suffix makes the complete address impractical to guess, and every message must pass authentication before anything runs. The real exposure is capability: an open inbox lets anyone who clears authentication invoke the agent, so scope **Allowed Senders** before publishing an address for an agent that can write to your systems. No. Every rejection is silent: no bounce, delivery notice, or other response goes back to the sender. Answering spoofers or unlisted senders would confirm the address is live and reveal its access rules, so failures are recorded only on your side when a run row exists. Yes. An agent can have as many addresses as you need. Each has its own template, senders, and switches, and each can be paused, tested, or deleted independently. Two addresses on the same agent can't share a slug. --- # Live Mode Source: https://www.hyperagent.com/docs/concepts/agents/invocations/live-mode > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Keep an agent on a checklist so it watches for changes on its own and only pings you when something needs attention. You have something that needs watching: a pipeline before the forecast call, an account before renewal week, a launch through the day. **Live Mode** gives that watch to an agent. It checks on an interval and alerts you only when something needs attention. It checks on an interval, stays silent while everything is fine, and pings you the moment something needs attention. ## How Live Mode works [#how-live-mode-works] **Check.** On your cadence, the agent works through the checklist you wrote. Give it a clear alert condition: "Alert when a deal over $50k loses its champion or has no next step" gives the agent a threshold. "Make sure everything is fine" doesn't. **Compare.** Every check runs in the same thread, so the agent can compare the latest state with earlier findings. If yesterday's check flagged an enterprise deal with no next step, today's can see whether that risk was resolved. **Alert.** An all-clear stays in [Run History](https://www.hyperagent.com/docs/concepts/agents/invocations/schedules#run-history) as **nothing to report**. A finding goes to your selected channel. If the watch can't run three times in a row, Live Mode pauses it automatically. ## Live Mode or a schedule [#live-mode-or-a-schedule] Live Mode and [schedules](https://www.hyperagent.com/docs/concepts/agents/invocations/schedules) run on the same machinery, but they handle different jobs. | | Live Mode | Schedule | | ---------- | -------------------------------------------- | ----------------------------------------------------- | | **Job** | Watch changing work for a finding | Produce a recurring deliverable | | **Output** | Alert only when something needs attention | Report on every run | | **Thread** | Keep every check in one continuing thread | Start fresh or continue an existing thread | | **Timing** | Run on an interval, with a 30-minute minimum | Run on a clock or recurrence, with a 5-minute minimum | Use a schedule for work such as a Monday report that should arrive every Monday. Use Live Mode when "nothing changed" is a useful result and each check should compare against the ones before it. Choose the full schedule builder when you need a specific wall-clock time or weekly rule. ## Set up Live Mode [#set-up-live-mode] On the agent's **Live Mode** card, select **Set up**. Live Mode has its own control rather than using the schedule dialog. The setup covers seven decisions: ## Run and manage a Live watch [#run-and-manage-a-live-watch] After setup, the **Live** pill in the thread header is the way back into the watch. A pulsing emerald dot means it is running normally; the pill shows when delivery or checks need attention. | What you see | What it means | | ------------------------- | ------------------------------------------------------------------------- | | **Set up Live Mode** | No watch configured yet; the chip opens setup. | | **Live · Xh** | Running normally, with the cadence shown (for example `Live · 1h`). | | **Live · check delivery** | Running, but a recent alert couldn't be delivered. Reconnect the channel. | | **Live · check failing** | Checks are failing, but the watch hasn't paused yet. | | **Paused · check failed** | Auto-paused after repeated failed checks. | | **Paused** | You paused it by hand. | **Test it before relying on it.** Select **Check now** to run an immediate check without advancing the interval, so the next scheduled check stays where it was. This confirms the checklist, channel, and delivery before you leave the watch unattended. A **Checking now** badge appears while the run is in flight, and the button stays disabled until it finishes. **When the watch can't run.** A missing integration, failing tool, or unmet prerequisite counts as an error. After **three consecutive** errors, Live Mode pauses the watch rather than keep billing a broken check and repeatedly alerting you about the same failure. Only errors count toward the streak. A successful check resets it, and a normal finding never counts as a failure. Resuming clears the streak and starts the watch again from its next check. **The watch follows the agent.** The **Live** pill in any of the agent's threads opens the same watch. An agent can also have schedules, but it can have only one Live watch. Trying to set up another returns **This agent already has a live schedule** and opens the existing watch. ## Integration writes while you're away [#integration-writes-while-youre-away] A Live watch runs without anyone at the keyboard, so it starts read-only. Most watches never need more; widen access after you have watched the narrower policy succeed. The agent reads anything it already has access to and changes nothing in connected apps. The agent pauses before each change and sends you an approval request. Nothing goes out unless you approve it. The agent sends messages, edits files, and updates records without approval. Use this after the watch has earned that trust. Only the teammate who created the watch can change its write policy, including on a shared workspace agent. ## FAQs [#faqs] That's Live Mode working. When a check finds nothing that needs you, the all-clear is suppressed and no alert is sent. The check stays in Run History as **nothing to report**. You hear from the watch on findings, not on quiet. It hit three consecutive errors, which means the watch itself couldn't run because of a missing integration, failing tool, or unmet prerequisite. Live Mode pauses rather than keep billing a broken check and re-alerting you about the same failure. Fix the cause and resume it; resuming clears the streak. Every heartbeat check bills, including all-clears. The setup dialog shows the routine cost per day and month, and the Enable button repeats the monthly estimate as `~$X/mo`. Follow-up work after a finding uses the agent's main model and costs extra. No. Live Mode keeps at least 30 minutes between checks. Presets run from 30 minutes to once a day, and Custom still respects the 30-minute floor. Use a schedule when you need a shorter cadence or a specific clock time. Yes. They handle different jobs and can coexist on one agent. An agent can have only one Live watch; a second setup returns **This agent already has a live schedule** and opens the existing one. Slack DM delivery conflicts with the agent's conversational DM mode. If DM mode is on, you will see **Direct messages are enabled for this agent. Turn them off before configuring live-mode Slack DM delivery.** Turn off DM mode or choose another channel, and the watch will save. --- # MCP clients Source: https://www.hyperagent.com/docs/concepts/agents/invocations/mcp-server > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Connect Claude Code, Claude, Cursor, or another MCP client so it can start work with your Hyperagent agents. Connect the client to your Hyperagent account once. It can discover your available agents, start a thread, follow the work in the background, and read the result back where you asked. The connection belongs to your account rather than one agent. There is no MCP card to enable on an agent's **Invocations** tab. Your client discovers the personal, shared, and team agents your account can currently reach. This is inbound MCP: an external AI client starts work with Hyperagent. To give a Hyperagent agent tools from an external server, use [Custom MCP](https://www.hyperagent.com/docs/integrations/custom-mcp). [Model Context Protocol](https://modelcontextprotocol.io) is the standard the client uses to discover and call these Hyperagent tools. You configure one remote server connection rather than a separate integration for every agent. ## How an MCP invocation works [#how-an-mcp-invocation-works] The client calls create\_thread with an agent and a self-contained message. Hyperagent starts the work and immediately returns a threadId. The agent continues after the tool call returns. The client polls get\_thread until the thread is no longer running. The last assistant message contains the result. Use send\_message to continue the same thread or open it in Hyperagent. The run is asynchronous. There is no single call that waits for the entire job and returns its final answer. Closing or disconnecting the client does not turn the thread into a hidden process; it remains a normal Hyperagent thread that appears in your thread list and in `list_threads`, ready to open or continue. The OAuth connection belongs to you, so work started by the client acts with your existing access. Use the same care you would when sending the request from the Hyperagent app. ## Connect your client [#connect-your-client] Every supported client points to [https://hyperagent.com/api/mcp](https://hyperagent.com/api/mcp) and completes OAuth in a browser. There is no API key for you to generate or paste. ### Open MCP access settings [#open-mcp-access-settings] Go to [Settings → MCP access](https://hyperagent.com/settings/mcp-access). Copy the server URL from **Connect an app**. ### Add Hyperagent to the client [#add-hyperagent-to-the-client] Run: ```bash claude mcp add --transport http hyperagent https://hyperagent.com/api/mcp ``` Launch Claude Code, run /mcp, select **hyperagent**, and complete the browser sign-in. Open **Settings → Connectors → Add custom connector**, name the connection, and enter the server URL. Connect and approve access in the browser. The Claude web and desktop apps reach Hyperagent from Claude's servers, not your machine. If your instance sits behind a VPN or firewall, allow that traffic. Otherwise the connector signs in but can't open the session. Claude Code connects from your own machine and isn't affected. Register the server, then sign in: ```bash codex mcp add hyperagent --url https://hyperagent.com/api/mcp codex mcp login hyperagent ``` The login command opens the browser for OAuth. Check the connection with codex mcp list. Add Hyperagent to \~/.cursor/mcp.json (or a project's .cursor/mcp.json): ```json { "mcpServers": { "hyperagent": { "url": "https://hyperagent.com/api/mcp" } } } ``` Then open **Cursor Settings → MCP**, find **hyperagent**, and complete the browser sign-in when it prompts. Any other client that supports a remote HTTP MCP server with OAuth works the same way: give it the server URL and complete the browser sign-in. ### Review and approve access [#review-and-approve-access] The consent screen lists the scopes the client requested. Approve them, and the client stores its connection and can reconnect without another manual setup. ### Start with one agent [#start-with-one-agent] Ask the client to list your agents, choose one, and send a complete first request. Confirm the result comes back before relying on the connection in a longer workflow. ## What your client can do [#what-your-client-can-do] | Tool | What it does | | -------------------------- | ---------------------------------------------------------------------------------------- | | list\_agents | Lists available agents with their ID, name, description, and execution mode. | | create\_thread | Starts work on an agent and immediately returns a threadId. | | send\_message | Sends a follow-up to an existing thread, immediately when idle or after the active turn. | | get\_thread | Reads recent messages and reports whether the thread is still running. | | list\_threads | Pages through your threads, newest first. | | create\_attachment\_upload | Creates a direct file upload and returns the fileId used with a message. | | list\_pending\_approvals | Lists actions and drafts waiting for your decision, most urgent first. | | resolve\_approval | Approves or denies one pending item. | The MCP server doesn't include tools for creating or configuring agents, skills, or memories. An agent with the right permissions can still do that work when you prompt it through MCP. An agent set to **Ask first** pauses mid-run to get your approval before sensitive actions. MCP has no surface to show that approval prompt, so `create_thread` refuses to start one: > Can't start that agent over MCP: it's set to Ask first, and MCP has no approval surface. Run it in Hyperagent, or switch the agent to Auto. The agent still appears in `list_agents` so you can see it and its execution mode. To run it from your editor, either run it in Hyperagent instead, or switch it to **Auto** if it's safe to run on its own. ## Start a run, then poll for the result [#start-a-run-then-poll-for-the-result] The single most important thing to know is that runs don't block your editor. `create_thread` returns a `threadId` the instant you call it, and the agent keeps working after the call ends. There is no synchronous "run and give me the answer" call. To collect the result, poll `get_thread` until it reports the run is no longer running, then read the last assistant message. It's a normal thread on your account, so you can also open it in Hyperagent to watch the full run or continue it there. Send a follow-up with `send_message` to keep the same thread going. ## Manage access [#manage-access] Every client is its own connection, signed in through OAuth. You can see and revoke them all at [Settings → MCP access](https://hyperagent.com/settings/mcp-access): each connection lists its scopes and when it was last used, and revoking one cuts that client off immediately without touching the others. A connected client acts as you and reaches only what you already can, and it can't create or edit skills, memories, or agent configuration. ## Attach a file without loading it into client context [#attach-a-file-without-loading-it-into-client-context] Call create\_attachment\_upload with the file name, type, and exact size. Hyperagent returns a fileId and short-lived upload URL. Upload the bytes directly, then include the fileId in create\_thread or send\_message. ```bash curl -T report.pdf -H "If-None-Match: *" "" ``` The file moves to storage rather than through the client's model context or the MCP endpoint. ## Access and security [#access-and-security] Each client completes its own OAuth 2.1 connection and receives only the scopes approved on its consent screen. Hyperagent issues that client a bearer token prefixed `hat_`. The secret is delivered to the client once and is never shown for you to copy; Settings displays only the connection and token prefix. | Scope | What it grants | | --------------- | --------------------------------------- | | threads:read | Read your agents, threads, and messages | | threads:write | Create threads and send messages as you | | approvals:read | See pending actions and drafts | | approvals:write | Approve or deny pending items | It can reach the same agents and threads you can, including shared resources already available to you. Connecting MCP does not grant new access elsewhere in the account. Hyperagent supports up to 50 active client connections. Each appears in **Settings → MCP access** with its scopes, token prefix, and last-used time. **Revoke** cuts off that client immediately without affecting the others. ## Troubleshooting [#troubleshooting] Check its execution mode. An Ask-first agent cannot begin over MCP because the run has no live approval surface. Use Hyperagent or switch the agent to Auto when that is safe. Poll get\_thread with the returned threadId until the thread is no longer running, then read the last assistant message. The connection can only list agents your signed-in account can currently reach. Confirm the agent is shared with you and that the client connected to the intended account. Open **Settings → MCP access**, find it under Active connections, and select **Revoke**. It must complete OAuth again before it can return. No. Enter the server URL and complete browser sign-in. The OAuth token is delivered to the client rather than shown to you. --- # Other agents Source: https://www.hyperagent.com/docs/concepts/agents/invocations/other-agents > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Let one named agent hand specialist work to another, with controls on who can call it and what each agent can do. You have a support agent that fields customer questions all day, and some of those questions belong with the product specialist down the hall. Instead of answering outside its depth, the support agent hands that question to the specialist, gets an answer back, and finishes the reply. **Other agents** is the invocation that lets one named agent start work for another. The caller writes the brief. The specialist runs in its own thread with its own instructions, model, tools, skills, and knowledge, then returns the result. Delegation lets a capable generalist bring in a specialist for the part of a job that specialist does best. It takes consent on both sides: the caller has to be allowed to delegate, and the specialist has to be willing to be called. ## How delegation works [#how-delegation-works] The caller invokes another agent by name. The agent it calls runs in its own brand-new [thread](https://www.hyperagent.com/docs/concepts/threads) with a fresh context window, does the work with its own prompt, model, tools, skills, and knowledge, then returns a short result. Nothing of the caller's conversation crosses over except the brief the caller writes for the handoff. During a run, the parent agent calls an allowed specialist by name and sends a brief: the goal, the inputs, and what a finished result looks like. Hyperagent opens a new thread on the specialist with a clean context window. It carries the specialist's own configuration, not the parent's history. The parent's transcript shows a card with the specialist's summary, a status pill, and a link into the specialist's thread so you can read the full run. The specialist hands its result back to the parent and cannot invoke a third agent. Delegation is one level deep by design, so chains stay legible. The parent's runner pays for the delegated run, and the specialist's budget is clamped to the parent's cap. A delegation can never spend more than the run that started it. ### The result card in the parent thread [#the-result-card-in-the-parent-thread] When a delegated run finishes, the parent thread shows a card for it. The card carries the specialist's name, a summary line of what came back, a status pill, and a **View thread** link that opens the specialist's own thread. The specialist is still working. The card shows elapsed time while the run is in flight. The run completed and the summary and View thread link are ready to read. The run started but could not complete. Open the thread to see what went wrong. The specialist could not be reached to run, so no work happened. ## Consent on both sides [#consent-on-both-sides] Delegation only happens when both agents agree to it. The caller has to be allowed to delegate, and the agent being called has to permit other agents to invoke it. Neither side alone is enough. On the caller's Autonomy tab, the Agent delegation section turns delegation on and holds the allowlist of agents this one may invoke, up to 500 agents. A workspace mode instead includes your other agents automatically. On the specialist's Invocations tab, the Other agents row controls who is allowed to invoke it as a sub-agent. Its chat, schedules, and channels are unaffected. ## Execution modes: Auto and Ask first [#execution-modes-auto-and-ask-first] Every agent acts in one of two modes while you are in conversation with it. The mode is set on the Autonomy tab and a thread can override it per-conversation. Agent runs everything end-to-end without stopping. Agent pauses for approval before sensitive actions. Heads up: this is a behavioral preference the agent follows, not a sandbox. Use Ask first for oversight, not for adversarial isolation. ### Ask first when nobody is watching [#ask-first-when-nobody-is-watching] Ask first works by pausing for a person to approve. That means it only applies where someone is present to answer. When a run happens on its own, on a surface with no approval to give, there is nobody to unblock the pause. On those surfaces the run either refuses or folds to Auto rather than hanging, so an unattended run never stalls waiting for an approval that can't arrive. ## The approval card [#the-approval-card] When the caller is set to ask for approval before delegating, a delegation doesn't start on its own. Instead, a card appears in the parent thread asking for your OK, and the specialist runs only after you approve it. The card shows the specialist's name and the prompt the caller wants to send, with Approve and Deny controls. The card switches to the specialist running, with a View thread link into its work. The card reads Denied - Research Agent was not invoked. and nothing runs. If a pending delegation is interrupted before it finishes, the card asks you to run it again rather than leaving the request half-started. ## Subagents are not delegation [#subagents-are-not-delegation] Both can divide work, but they solve different problems. The specialist has its own identity, instructions, tools, knowledge, and thread. Use delegation when the work belongs to a durable role you want to configure, trust, and inspect independently. A run may dispatch anonymous workers inside the same thread for short-lived legwork. They have no settings page and disappear when the work ends. The thread's Subagents setting chooses only their model. ## Trace a delegated run [#trace-a-delegated-run] A delegated run lives in the specialist's own **Activity**, the same place all of that agent's threads appear. Each row opens the thread where the work happened. From the parent side, the result card's **View thread** link takes you straight into that thread, and the run carries provenance back to the parent thread that started it. Because delegation is one level deep, tracing a delegation is a single hop from caller to specialist and back. ## Trust and tool access [#trust-and-tool-access] A delegated run is treated as external content for learning purposes. The brief the caller sends arrives in the same trust class as content that came from outside, kept separate from what you yourself wrote, so a specialist doesn't learn from a caller's prompt as if a person had typed it. What a specialist can actually do is governed by its own tool access, not the caller's. Delegating work to an agent doesn't lend it any capability it wasn't already configured with. If a specialist can't send email on its own, it can't send email just because another agent asked it to. ## FAQs [#faqs] A delegation is refused before any work starts for one of three reasons: the specialist isn't on the caller's allowlist, the specialist doesn't permit other agents to invoke it on its Invocations tab, or the call would go past one level deep. Fix the one that applies and the invocation goes through. No. Delegation is one level deep by design. The agent you call returns its result to the caller and cannot invoke a third agent. Design a hub with specialists around it, not a chain of handoffs. The caller's runner. The specialist's budget is clamped to the caller's cap, so a delegated run can never spend more than the run that started it. No. Heads up: this is a behavioral preference the agent follows, not a sandbox. Use Ask first for oversight, not for adversarial isolation. What a specialist can do is set by its own tool access, not by the caller's execution mode. No. It runs in its own new thread with a fresh context window and receives only the brief the caller writes for the handoff. Include every input it needs to do the work. --- # Schedules Source: https://www.hyperagent.com/docs/concepts/agents/invocations/schedules > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Put an agent on a recurrence: define the work, control its threads and write access, deliver the result, and review every run. You have a report that should exist every Monday at 7 AM, whether or not you remembered to ask for it. A **schedule** is how you hand that job over: the agent receives the schedule's message, works in a thread, and delivers the result where you chose, with nobody watching. Brief the job once, choose when it should run, and decide where the result belongs. The agent repeats that work with fresh information on every occurrence. ## How schedules work [#how-schedules-work] Set a schedule in plain language or with the recurrence controls. Hyperagent keeps the timing in your timezone and calculates each next occurrence. The agent receives the schedule's message as its instructions. Template variables can add the current date, time, weekday, or run count. Choose whether runs start fresh or continue together, then decide whether the agent may only read, ask before changes, or write unattended. Hyperagent delivers the finished result after the run and records its status, duration, thread, and errors in Run History. ## Create and configure a schedule [#create-and-configure-a-schedule] On the agent's **Invocations** tab, open the **Scheduled** card and select **Create schedule**. ### Describe the routine [#describe-the-routine] Enter timing and work together—for example, `Every Monday at 9 AM, check my inbox and summarize unread emails.` Select **Generate** to draft the complete schedule, or **Skip** to open the form directly. ### Confirm the recurrence [#confirm-the-recurrence] Review the generated timing, timezone, and next occurrence. Every generated field remains editable. ### Brief the work and choose its thread [#brief-the-work-and-choose-its-thread] Write instructions that can stand on their own, then decide whether each occurrence starts fresh or continues in an existing thread. ### Set guardrails and delivery [#set-guardrails-and-delivery] Choose the write level, quiet-delivery behavior, completion notification, and destination before saving. ## Schedule configuration options [#schedule-configuration-options] [Live Mode](https://www.hyperagent.com/docs/concepts/agents/invocations/live-mode) uses a rolling monitoring interval and is configured from its own control on the agent, not from the schedule builder. ## Set the timing and recurrence [#set-the-timing-and-recurrence] ### Set the recurrence [#set-the-recurrence] Describe the timing in plain language—`Every weekday at 8:30` or `The last Friday of the month`—and let **Generate** build it, or configure the recurrence manually. Both paths produce the same schedule. | You want | You configure | | --------------------- | -------------------------------------------------------------------------- | | A daily brief | **Daily** and a time | | Weekdays only | **Weekly**, the five weekday choices, and a time | | Every other week | **Weekly**, every 2 weeks | | A monthly report | **Monthly**, then a date or a slot such as First Monday or Last Friday | | High-frequency checks | **Hourly** or **Minutely**, keeping at least 5 minutes between occurrences | Hyperagent stores every schedule as a standard recurrence rule, or RRULE, with an IANA timezone. If you already have an RRULE, the API accepts it directly. ### Template variables [#template-variables] The message and new-thread naming hint support variables resolved in the schedule's timezone at runtime: | Variable | Resolves to | | --------------- | ------------------------------------ | | `{{date}}` | The occurrence's date | | `{{time}}` | The occurrence's time | | `{{dayOfWeek}}` | The weekday name | | `{{isoDate}}` | The date in ISO format | | `{{runCount}}` | How many times this schedule has run | A naming hint such as `Weekly pipeline report {{isoDate}}` keeps months of run threads sortable. ### Timezones and clock changes [#timezones-and-clock-changes] Daily and coarser schedules preserve local wall-clock time through daylight-saving changes, so a 7 AM report stays at 7 AM. Sub-daily schedules measure elapsed time instead, so `Every 4 hours` remains four hours apart even when the clock changes. ## Choose how scheduled runs work [#choose-how-scheduled-runs-work] ### Choose a thread strategy [#choose-a-thread-strategy] Every occurrence gets a clean thread carrying the agent's instructions, skills, and memories but no history from earlier runs. Use it for work that should stand on its own. Every occurrence is appended to one existing thread, so the agent can read what earlier runs left there. The thread must belong to this agent. Use the optional **Thread naming hint** to derive each new thread's title from runtime variables or the work itself. Leave it empty to use the default name. ### Choose standard, alert, or Live behavior [#choose-standard-alert-or-live-behavior] | Behavior | How you configure it | What you receive | | ------------ | ------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- | | **Standard** | The schedule default | Every run reports. Use it when the output should exist every time, such as a Monday report. | | **Alert** | Enable **Only deliver when something needs attention** | The agent explicitly reports a status after each run; all-clear runs stay quiet and only findings are delivered. | | **Live** | Configure [Live Mode](https://www.hyperagent.com/docs/concepts/agents/invocations/live-mode) | Rolling monitoring with a 30-minute minimum, alert-style silence, and an automatic pause after repeated consecutive failures. | Standard schedules keep at least five minutes between occurrences. Live Mode keeps at least thirty. ### How scheduled runs start [#how-scheduled-runs-start] If the previous run is still working when the next scheduled time arrives, the new run waits. A schedule never runs two jobs at once. When a schedule continues an existing thread, it waits while someone is actively using that thread and starts when they're finished. The schedule keeps moving while paused, blocked by billing, or waiting on another run. It starts at the next scheduled time without creating a backlog. ### Run Now and completion [#run-now-and-completion] **Run Now** starts an immediate occurrence without moving the recurrence. The next scheduled time remains unchanged. Use it to test the message, thread behavior, write controls, delivery, and completion notification end to end. When a fixed-span recurrence has no future occurrences, the schedule marks itself **Completed** instead of remaining active indefinitely. ## Control writes and delivery [#control-writes-and-delivery] ### Integration writes and approvals [#integration-writes-and-approvals] Scheduled runs work without you present and may act on content nobody reviewed first. Standard schedules therefore default to read-only. Read connected apps normally without changing them. Most reporting and monitoring jobs don't need more access. Stop at the first attempted change and create an approval with an exact preview of what would be sent. Use the agent's normal integration access unattended. Reserve this for schedules you've observed and trust. Approving a pending write executes exactly the previewed action and nothing more. Denied or expired approvals can never execute. A run waiting for approval doesn't block the recurrence; later occurrences follow the normal schedule instead of stacking behind it. ### Deliver results [#deliver-results] Hyperagent delivers after the run finishes, separately from the agent's integration permissions. A read-only schedule can therefore send its completed report to Slack, Telegram, or email. | Destination | Where the result lands | | ----------------- | ----------------------------------------------- | | **Thread** | The run's thread, with no external copy | | **Slack channel** | The configured channel | | **Slack DM** | A direct message to the schedule creator | | **Telegram** | The chat mapped to the schedule's target thread | | **Email** | The schedule creator's email address | **Notify when complete** is separate from report delivery. It sends a browser or mobile push after the run, including runs started with **Run Now**. Two delivery rules prevent surprises: * **The destination is snapshotted when the run starts.** Editing delivery during an active run can't redirect that result; the new destination applies on the next occurrence. * **Delivery failures remain visible.** A completed run that couldn't deliver adds a warning to the schedule. A later successful delivery clears it. ## Monitor and manage a schedule [#monitor-and-manage-a-schedule] ### Run History [#run-history] Every schedule records each occurrence in **Run History**, including its status, start time, duration, thread, and any error or result classification. ### Ownership on team agents [#ownership-on-team-agents] A schedule belongs to its creator. Runs use that person's context, count against their usage, and keep that ownership even when other teammates use the agent. The schedule doesn't continue under a missing owner. If its creator leaves the workspace, it pauses. Teammates with run-only access to the shared agent can't create or edit schedules. ## Troubleshooting and FAQs [#troubleshooting-and-faqs] It serves the same recurring-job purpose with a visual and plain-language builder. Hyperagent stores the result as an RRULE with an IANA timezone. Daily and coarser schedules preserve local wall-clock time through clock changes; sub-daily schedules measure elapsed time. The new occurrence is deferred. Occurrences from one schedule never run concurrently. In continue mode, they also wait while a person actively uses the target thread. The recurrence advances without building a backlog. No. While a schedule is paused or blocked, the recurrence keeps advancing. When the schedule can run again, it fires at the next occurrence instead of catching up on everything it missed. No. It starts an immediate occurrence while the next scheduled time stays where it was. Run Now counts as an unattended run, so write controls, delivery, and completion notifications still apply. A Live schedule pauses after repeated consecutive errors, and a team schedule pauses when its creator leaves the workspace. A fixed-span schedule with no future occurrences becomes Completed instead. Other failures remain visible in Run History without automatically pausing a standard schedule. That run was already active. Hyperagent snapshots delivery when a run starts, so an in-flight edit can't redirect it. The next occurrence uses the new destination. Continue mode requires an existing thread that belongs to this agent. Select one of the agent's own threads. --- # Telegram Source: https://www.hyperagent.com/docs/concepts/agents/invocations/telegram > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Bring your agent into Telegram: the bot connection, account pairing, group authorization, and how media and replies flow both ways. You want to reach your agent from your phone the way you'd message a colleague: a quick DM on the train, a report dropped into a team group, a voice note when your hands are full. Telegram is where the agent meets you; the bot you connect is just the doorway, tied to your account, so the agent answers the people you chose and not everyone who stumbles onto the username. Connect a bot as the doorway, pair it to your account so the agent recognizes you, and decide chat by chat who can reach it. Every conversation becomes a lasting thread. ## How Telegram works [#how-telegram-works] A Telegram bot gives the agent a name, username, and place to receive messages. Its token connects that bot to one Hyperagent agent. A one-time link ties your Telegram user ID to the bot. The paired account becomes the owner who can use it in DMs and authorize it in groups. Direct messages are owner-only. In groups, you choose who can reach the agent and which kinds of messages start a run. Every DM, group, or forum topic maps to a lasting Hyperagent thread, keeping its conversation and replies in the right place. ## Connect your agent to Telegram [#connect-your-agent-to-telegram] The doorway is a Telegram bot, and Telegram bots are created inside Telegram, so setup starts with a token from BotFather and ends with the agent recognizing you. On the agent's **Invocations** tab, open the Telegram control and the **Connect Telegram Bot** dialog walks the same three steps: ### Create the bot in Telegram [#create-the-bot-in-telegram] Message @BotFather, send `/newbot`, then choose a name and username. The username must end in `bot`; the description is optional. This bot is your agent's face in Telegram, so name it like the agent rather than like infrastructure. Copy the token BotFather returns. ### Paste the token and connect [#paste-the-token-and-connect] Paste the token into the **Bot Token** field. Hyperagent validates it live against Telegram, and a valid token surfaces a green confirmation with the bot's `@username` and display name so you can be sure you pasted the right one. **Connect** stays disabled until validation succeeds. ### Pair with your Telegram account [#pair-with-your-telegram-account] Connecting proves the bot is real; pairing proves *you* are the owner. Select **Open Telegram to pair**, then tap **Start** in Telegram. That stamps your Telegram identity onto the connection, and the agent replies "You're paired with Hyperagent. You can now chat with your agent here." Telegram identifies people by numeric user ID, which Hyperagent can't know until you pair. Before that link stamps your ID onto the connection, the agent can't distinguish you from a stranger, so an unpaired bot answers no DMs. The link is single-use and expires after 15 minutes. The dialog shows the exact expiry time; if it lapses, generate a new one. Use **Re-pair** when the owning Telegram account changes. Re-pairing resets the bot's thread mappings so the new owner doesn't inherit the previous owner's conversation history; existing chat threads start fresh. One bot belongs to one agent, and one token belongs to one bot everywhere on the platform. Reconnecting a fresh token from BotFather replaces the old binding. Your raw token is never stored in plaintext; it lives in the secret store, and the database keeps only the bot's numeric ID and username. ## Control who can use the bot [#control-who-can-use-the-bot] Pairing establishes the owner. From there, direct messages and groups follow different access rules: DMs stay private to that owner, while each group must be explicitly authorized before anyone can use the agent there. ### Direct messages [#direct-messages] Anyone who finds your bot's username can open a chat with it, but only the paired owner gets answers. The bot matches every incoming DM against its pairing record, and messages from any other account aren't routed to the agent. The first time a non-owner messages the bot in a given hour, it replies once with a fixed notice: > Sorry, I'm not configured to respond to you. Contact the bot owner for access. Further DMs from that person within the hour are dropped silently. The first reply tells a legitimate person they've reached the wrong bot; the silence that follows keeps the bot from being used to spam them. ### Add the bot to a group [#add-the-bot-to-a-group] A bot sitting in a group does nothing until you've allowed group chats on the bot and authorized that specific group from inside it. Being added isn't authorization: Telegram lets anyone add a bot to a group, so Hyperagent waits for the paired owner to approve it. ### Allow group chats [#allow-group-chats] In the manage dialog, turn on **Allow group chats**. It's off by default. This reveals the group settings and lets the bot accept authorization. ### Add the bot to the group [#add-the-bot-to-the-group] Add your bot from the group's member list. ### Authorize the group [#authorize-the-group] Send `/authorize` in the group as the paired owner. Commands from anyone else are silently ignored. On success, the bot replies "Group authorized. Members can now talk to me based on this bot's settings." Until the group is authorized, every message in it is dropped. The `/authorize` command is checked before response-trigger filtering, so it works regardless of the trigger mode you've chosen. ### Choose who can trigger the agent [#choose-who-can-trigger-the-agent] An authorized group inherits the bot's **Default for new groups** policy at that moment, then keeps its own copy. Changing the default later doesn't rewrite existing groups, and you can override each group's policy from its row in the manage dialog. Only the paired owner's messages trigger the agent. Everyone else's are ignored, which suits a group where the agent is present but reports only to you. Any member can trigger the agent. Non-owners are limited to roughly one message every three seconds each; the owner isn't rate limited. ### Choose when the bot responds [#choose-when-the-bot-responds] The access policy decides *whose* messages count. The response trigger decides *which* of those messages start an agent run, so a busy group doesn't turn every line into work. This setting is shared by all of the bot's groups under **When should I respond?** The bot reacts when someone @mentions it or replies directly to one of its messages, and stays quiet otherwise. The bot reacts only to `/commands` or direct replies. This is the one mode that works with Telegram privacy mode left on. Every eligible message in an authorized group starts a run. Telegram privacy mode must be turned off. ### Configure Telegram privacy mode [#configure-telegram-privacy-mode] Telegram privacy mode is on by default and determines which group traffic Telegram forwards to the bot. With it on, only `/commands` and direct replies to the bot's own messages reach Hyperagent. That makes **Commands or replies** the only mode that works without changing BotFather. When you choose **@mentions or replies**, Hyperagent recommends turning privacy mode off because plain @mentions aren't forwarded while it remains on. **Every message** requires it: Telegram won't send ordinary group messages to the bot otherwise. The manage dialog shows a warning when the selected trigger needs this change. Message @BotFather, send `/setprivacy`, pick your bot, and choose **Disable**. Privacy changes only take effect when the bot joins, so remove and re-add it to any existing group. ## How Telegram conversations work [#how-telegram-conversations-work] ### Threads and topics [#threads-and-topics] Every Telegram chat maps to a lasting Hyperagent thread named "Telegram chat." That thread is the record; there isn't a separate Telegram run history. The conversation with the paired owner stays together in one thread. A regular group maps to one thread, so its messages and replies keep the same context. Each Telegram topic gets its own thread, keeping parallel conversations and replies separate. Thread trust follows the setting. DM threads are treated as user-facing. Group and supergroup threads are treated as external for memory auto-accept because anyone in the group may contribute to them. ### Messages and media [#messages-and-media] Attachments are routed into the thread and identified by their actual bytes rather than Telegram's label. Each attachment is capped at 20 MB. When a file is too large, the agent is told that it couldn't take it in and can ask for a smaller version. | You send | The agent gets | | --------------- | --------------------------------------------------------------------------------------------------------------------------- | | **Photos** | Inlined as a vision block it can see directly, plus a short text description for later reference. | | **Documents** | Images and PDFs come in as readable content; other files arrive as a stored file reference the agent can open. | | **Voice notes** | Transcribed automatically on arrival, so the transcript stands in as your message, and kept as a file it can re-transcribe. | | **Audio files** | Stored as a file, not auto-transcribed; the agent can call `TranscribeAudio` on it when the contents matter. | | **Albums** | Several photos sent together are combined into one message with every image attached. | Video isn't supported yet. A message with nothing routable—no text, caption, or supported attachment—is dropped. ### Replies and progress updates [#replies-and-progress-updates] Replies are formatted in Telegram's MarkdownV2 so links render as tappable links. Because Telegram caps a message at 4096 characters and the platform's formatting is applied only when the escaped text fits under that cap, a very long reply falls back to plain text rather than arriving broken. Images the agent produces through Hyperagent's own file pipeline are sent as real Telegram photos. External image URLs the agent might emit are deliberately demoted to plain links and never fetched and re-sent as photos, which closes off a way for a crafted URL to exfiltrate data or probe internal services. With **Show progress updates** on, the bot edits a single status message in place during a run to show what the agent is doing. It's on for DMs and off for groups by default, since **Also in group chats** would double the message count in a shared room. ## Deliver scheduled and Live Mode updates [#deliver-scheduled-and-live-mode-updates] [Live Mode](https://www.hyperagent.com/docs/concepts/agents/invocations/live-mode) and [scheduled](https://www.hyperagent.com/docs/concepts/agents/invocations/schedules) runs can deliver reports and alerts into a Telegram chat the agent already knows. ### Link the destination chat [#link-the-destination-chat] Message the bot from the DM, group, or topic where you want updates. Hyperagent creates the chat-to-thread mapping from that first message. ### Target the linked thread [#target-the-linked-thread] Choose that existing thread for the Live Mode or scheduled run. Delivery follows the schedule's target thread back to its Telegram chat. ### Select Telegram delivery [#select-telegram-delivery] Choose Telegram as the delivery channel and save. Hyperagent checks the connection, pairing, and chat mapping before it lets the watch or schedule run. A schedule that creates a new thread for every run has no Telegram chat to deliver to. Target a thread that was created from the destination chat. Before it lets you save, Hyperagent runs a preflight that catches the setup gaps in plain terms: | If | You'll be told | | --------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | No bot is connected | "Connect a Telegram bot for this agent before using Telegram delivery." | | The bot isn't paired | "Finish pairing this agent's Telegram bot before using Telegram delivery." | | The thread isn't linked to a chat | "The selected thread isn't linked to a Telegram chat. Message the agent's bot from the chat you want reports in, then pick that thread." | A delivery warning appears only when the last three completed runs hit the same problem, so one transient failure doesn't raise a false alarm. If the token is revoked in BotFather or someone blocks the bot, Hyperagent surfaces the matching warning and asks you to reconnect or unblock it. ## Troubleshooting and FAQs [#troubleshooting-and-faqs] Being added to a group isn't authorization. Turn on **Allow group chats** on the bot, then send `/authorize` in the group as the paired owner. If you're on the default or the every-message trigger, also disable privacy mode in BotFather and re-add the bot, because Telegram won't forward the messages otherwise. Check the response trigger. On the default, the bot only answers @mentions and direct replies to its own messages, and with Telegram privacy mode still on, even plain @mentions don't reach it. Either reply directly to a bot message, or disable privacy mode in BotFather and re-add the bot, or switch the trigger to every message. They can open a chat with it, but they won't get answers. Direct messages are answered only for the paired owner. A non-owner gets a single "not configured to respond to you" notice per hour, then silence. To let others reach the agent, use it in a group with the **Anyone in the group** policy instead. Re-pairing is for handing the bot to a different Telegram account, so it resets this bot's thread mappings on purpose. That keeps the newly paired person from inheriting the previous owner's conversations. If you only need a fresh link for the same account, generating one still rotates the token without any change of identity. No. One bot binds to one agent, and one token binds to one bot across the whole platform. To move a bot to a different agent, connect its token there, which replaces the old binding. Photos come in as images the agent can see. Voice notes are transcribed automatically, so you can just talk. Documents and PDFs are readable; other files and uploaded audio are stored for the agent to open or transcribe on demand. Everything is capped at 20 MB, and video isn't supported yet. --- # Troubleshooting invocations Source: https://www.hyperagent.com/docs/concepts/agents/invocations/troubleshooting > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Why an invocation didn't run, ran silently, or errored: the three-step triage and the fix for each doorway. Something should have fired and didn't, or fired and you never heard about it. Most of the time the answer is one of three things, so start with the triage before digging into a specific doorway. Check the invocation's status first, then whether a run actually started, then whether it ran and chose silence. That order resolves most cases in under a minute. ## Check these three things first [#check-these-three-things-first] ### Is the invocation still active? [#is-the-invocation-still-active] Invocations pause themselves in specific, deliberate cases: a schedule whose creator left the workspace, a Live watch after three consecutive failed checks, an email address whose owner departed, a webhook endpoint you paused. A schedule with no future occurrences marks itself completed. Check the status where you configured it. ### Did a run start? [#did-a-run-start] Every doorway keeps its own log: **Run History** on schedules and Live Mode, **Recent Emails** on an email address, **Recent invocations** on a webhook endpoint, the thread itself for Slack, Telegram, and MCP. If there's a run, the problem is downstream; if there isn't, the trigger never got through. ### Did it run and stay quiet on purpose? [#did-it-run-and-stay-quiet-on-purpose] Alert schedules and Live Mode suppress the all-clear: the run appears in history as **nothing to report**, and that's success. A run that finished but couldn't deliver records a delivery warning on the schedule instead of failing. ## A schedule didn't fire [#a-schedule-didnt-fire] Occurrences never overlap: if the previous run was still going, the new occurrence was deferred, not lost. Missed occurrences skip rather than backfill, so a schedule paused for two weeks resumes at its next occurrence with no catch-up burst. In continue mode, a run also waits while a person is actively using the target thread. If runs are landing but the report goes to the wrong place, remember delivery is snapshotted at run start: mid-run edits apply from the next occurrence. Details in [Schedules](https://www.hyperagent.com/docs/concepts/agents/invocations/schedules). ## Live Mode is silent or paused [#live-mode-is-silent-or-paused] Silence is usually the product working: an all-clear check delivers nothing and logs **nothing to report**. A paused watch hit three consecutive error-severity checks, which means the check itself couldn't run (a missing integration, a failing tool), not that it found problems; fix the cause and resume, which resets the streak. **Live · check delivery** means checks run fine but a recent alert couldn't be delivered, so reconnect the channel. Details in [Live Mode](https://www.hyperagent.com/docs/concepts/agents/invocations/live-mode). ## Slack doesn't respond [#slack-doesnt-respond] Check the trigger mode first: on mentions-only, plain channel messages are ignored by design. If the agent went silent everywhere at once, an identity change is the usual cause, because changing an agent's Slack identity disables its channel configurations until each one is re-enabled. And a bot can only see channels it has been added to. The full setup is in [Slack](https://www.hyperagent.com/docs/concepts/agents/invocations/slack). ## Telegram doesn't respond [#telegram-doesnt-respond] Work down the gate list: DMs answer only the paired owner, so an unpaired bot answers no one. In groups, being added is not authorization; the owner has to send `/authorize` in the group, and the response trigger still filters what counts. If mentions or plain messages never arrive, Telegram's privacy mode is eating them before Hyperagent ever sees them: disable it in BotFather and re-add the bot. A bot that stopped responding entirely may have a revoked token or a user who blocked it, both of which surface as warnings. Details in [Telegram](https://www.hyperagent.com/docs/concepts/agents/invocations/telegram). ## An email didn't trigger the agent [#an-email-didnt-trigger-the-agent] Rejections are silent by design, so the sender never gets a bounce and you never get an error. The message was dropped if the sender didn't match the **Allowed Senders** list, failed email authentication, was flagged as spam or a virus, or exceeded the size cap. Check **Recent Emails** on the address: if the message isn't listed, it was rejected before reaching the agent. Details in [Email](https://www.hyperagent.com/docs/concepts/agents/invocations/email). ## A webhook call errored [#a-webhook-call-errored] The status code says exactly where it stopped: | Code | What it means | | ------------- | ----------------------------------------------------------------------------------------------------- | | `401` / `403` | Missing or wrong secret. Send it in the `X-Hyperagent-Webhook-Secret` header; rotate it if it's lost. | | `404` | Wrong endpoint ID in the URL. | | `413` | Body over the 1 MB cap. | | `422` | The endpoint is paused, or the agent is archived. | | `429` | Rate limited; retry after the `Retry-After` header. | | `503` | The webhook feature is disabled for the account. | A `202` means the call worked: webhooks are fire-and-forget, the response never contains the agent's result, and the work lands in the run's thread. Details in [Webhooks](https://www.hyperagent.com/docs/concepts/agents/invocations/webhooks). ## An MCP client can't run an agent [#an-mcp-client-cant-run-an-agent] If an agent shows up in `list_agents` but `create_thread` refuses it, the agent is set to **Ask first**, which can't run over MCP because there's no surface to approve its actions. A run that seems stuck usually isn't: every MCP run is asynchronous, so poll `get_thread` until it stops running. If the client can't connect at all, check whether its connection was revoked under **Settings → MCP access**; revocation is immediate. Details in [MCP server](https://www.hyperagent.com/docs/concepts/agents/invocations/mcp-server). ## Still stuck [#still-stuck] Open the run's thread. Whatever the doorway, the thread holds the complete record of what the agent did, and the error messages there are specific in ways a status badge can't be. --- # Webhooks Source: https://www.hyperagent.com/docs/concepts/agents/invocations/webhooks > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Trigger an agent with an HTTP POST: configure the prompt and thread, secure the endpoint, and understand the asynchronous response. Some work should start the moment an event happens somewhere else: a pull request opens, a form is submitted, a CI job fails, or a CRM record changes. A **webhook endpoint** turns that event into an agent run. The system that saw the event sends an HTTP POST, and the agent starts with your instructions and the payload in hand. POST a payload to the endpoint URL and the agent runs on it. A shared secret authenticates the caller, and Hyperagent acknowledges the request before the run finishes. ## How webhooks work [#how-webhooks-work] GitHub, your CRM, a form service, or your own backend sends the event body to a URL created for this agent. Authenticated endpoints require a shared secret in the request header. Public endpoints trade that protection for broader compatibility. Your standing prompt tells the agent what to do. Hyperagent appends the raw request body and starts the run in the configured thread. A successful call returns `202 Accepted` with a run ID. The work continues asynchronously and its result lands in the run's thread. ## Create and call a webhook [#create-and-call-a-webhook] On the agent's **Invocations** tab, open **Webhook Endpoints**. Each endpoint has its own URL, prompt, secret, and thread strategy, so one agent can support several event sources without mixing their configuration. ### Create the endpoint [#create-the-endpoint] Add an optional name, write the prompt every event should follow, choose a thread strategy, and decide whether the caller must authenticate. ### Save the secret [#save-the-secret] Authenticated endpoints reveal their secret once. Copy it into the calling system before closing the confirmation. ### Copy the URL [#copy-the-url] The endpoint card shows the complete URL and a ready-to-run curl example. ### Send a POST [#send-a-post] Add the secret header when required, send a body no larger than 1 MB, and treat `202 Accepted` as confirmation that the run was queued. ## Webhook configuration options [#webhook-configuration-options] ### Endpoint URL [#endpoint-url] Every endpoint accepts one method at one URL: ```text POST /api/webhooks/{endpointId}/receive ``` The endpoint ID is a long random identifier created with the endpoint, which makes the URL impractical to guess. Only POST is accepted. The complete URL appears on the endpoint card with a copy button and curl example. ## Secure the endpoint [#secure-the-endpoint] Authenticated endpoints use a shared secret. The caller sends it in a header, and Hyperagent checks it before creating a run. ### Send the secret [#send-the-secret] ```bash curl -X POST https://your-workspace.hyperagent.com/api/webhooks/{endpointId}/receive \ -H "X-Hyperagent-Webhook-Secret: {secret}" \ # [!code highlight] -H "Content-Type: application/json" \ -d '{"event": "pull_request.opened", "number": 42}' ``` Hyperagent generates the secret from 32 random bytes when the endpoint is created. The UI shows it once with the warning **Save this secret now—it won't be shown again** and tells you to send it as `X-Hyperagent-Webhook-Secret`. The server stores only a SHA-256 hash, never the original secret. For each call, it hashes the submitted header and uses a timing-safe comparison against the stored value so a caller can't learn the secret from response timing. Copy it into the calling system before closing the dialog. A lost secret can't be recovered; it must be rotated. ### Rotate a secret [#rotate-a-secret] Select **Rotate secret** on the endpoint card to generate a new 32-byte secret. It is shown once, and the old secret stops working immediately. Only the endpoint owner can rotate it. Update the calling system as soon as you rotate. Rotate when the secret may have leaked or on the schedule required by your security practice. ### Understand the security boundary [#understand-the-security-boundary] Hyperagent verifies that the submitted secret matches. It does not verify an HMAC signature of the request body. A captured valid request can be sent again and will start another run. There are no timestamps or nonces in the authentication check. Any host with the URL and secret can call the endpoint. Source-IP restrictions aren't part of this authentication model. This model works when the caller can hold a secret in a header. If your integration requires signed bodies, replay protection, or source-IP restrictions, those checks need to happen before the request reaches this endpoint. ### Unauthenticated endpoints [#unauthenticated-endpoints] Enable **Allow unauthenticated calls (no secret required)** only when the caller can't send a custom header and you accept a public endpoint. If the URL is shared, placed in client-side code, or otherwise leaked, third parties can trigger runs and incur charges on your account. Use this only for public integrations where that risk is acceptable. Hyperagent adds two protections to unauthenticated endpoints: * A separate **pre-parse rate limit** rejects excess anonymous calls before the body is read. * Runs receive lower trust, which **suppresses memory auto-accept**. Memories proposed during those runs aren't saved automatically. Authenticated calls are treated as owner-facing and don't carry that restriction. Only the owner can select **Add a secret** on the endpoint card. Doing so immediately returns the endpoint to header-based authentication. ### Rate limits [#rate-limits] Two independent sliding windows protect each endpoint. Both default to **60 calls per minute** and are keyed to the endpoint, not the caller's IP: * The **invocation limit** applies to authenticated and unauthenticated endpoints. It runs after the size check but before a run is created. * The additional **unauthenticated limit** applies only when no secret is required. It runs before the body is read, making anonymous floods cheaper to reject. Crossing either window returns `429` with a `Retry-After` header. The first rejection in a window is also recorded as a skipped invocation in the endpoint's history. ## Understand the request and response [#understand-the-request-and-response] ### Request body [#request-body] The body can contain any data your caller sends, up to **1 MB**. There is no required schema. Hyperagent appends the raw body to the configured prompt inside a boundary the agent can distinguish from your instructions: ```text {your configured prompt} {the raw request body} ``` The request body isn't parsed or validated on the way in; it reaches the agent as text, exactly as sent. Any `` sequence inside the body is neutralized before delivery so incoming data can't close the wrapper and present itself as instructions. ### Successful response [#successful-response] A successful request returns immediately with **202 Accepted**: ```json { "runId": "clw3x8k2p0001abcd1234wxyz", // [!code highlight] "status": "accepted" } ``` The response means the run has been queued, not completed. The run ID identifies it in [Recent invocations](#review-recent-invocations); it isn't a public polling handle. ### Status codes [#status-codes] Every non-202 response explains why the call didn't start a run: | Code | Meaning | | ---- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 202 | Accepted. The run is queued; the body contains `runId` and `status: "accepted"`. | | 401 | The secret header is missing on an endpoint that requires it. An unknown endpoint also returns this when no header was sent, so a wrong URL can't be distinguished from a real one. | | 403 | The secret is present but wrong, or the endpoint's secret hasn't been generated yet. | | 404 | No endpoint with that ID exists, returned when a header was sent. | | 413 | The payload is larger than 1 MB. | | 422 | The endpoint is paused, or the agent is archived or otherwise unavailable. | | 429 | A rate limit was exceeded. The response includes `Retry-After`. | | 503 | Webhook triggering is disabled for the deployment. | ### Fire-and-forget delivery [#fire-and-forget-delivery] There is no public endpoint for fetching the finished result. The run ID helps the owner find the run in Hyperagent, and the output lives in the run's thread—not in the HTTP response and not somewhere the caller can poll. If the caller can act as an MCP client and needs the agent's response directly, use the agent's [MCP server](https://www.hyperagent.com/docs/concepts/agents/invocations/mcp-server) instead. Keep the webhook when an immediate acknowledgment is enough, and have the agent deliver the outcome another way: comment on the pull request, post to Slack, update your database, or call an API. ## Choose a thread strategy [#choose-a-thread-strategy] Every webhook run happens in a thread. The strategy decides whether events remain independent or build on the same history. Each event gets a clean thread with the agent's instructions, skills, and memories but no history from previous events. Use it for independent work, such as triaging each pull request separately. Every event is appended to one thread you choose, so the agent sees what earlier events left there. The target must already belong to this agent. New threads are named `Webhook: {agentName}` by default. Add a **Thread naming hint** to derive a more useful title from the payload—for example, `Name it after the PR number`. Leave it empty to keep the default. ## Operate and monitor an endpoint [#operate-and-monitor-an-endpoint] Each endpoint keeps its own configuration and invocation history, so you can debug or pause one integration without affecting the agent's other event sources. ### Review Recent invocations [#review-recent-invocations] Expand **Recent invocations**, shown with the current run count on the endpoint card, to see its latest runs, most recent first. This is the first place to look when the caller received `202` but no outcome appeared where expected. | Field | What it tells you | | ----------------- | -------------------------------------------------------------------- | | **Status** | `running`, `success`, `error`, or `skipped`. | | **Started at** | When the run began. | | **Completed at** | When it finished, when available. | | **Duration** | How long the run took. | | **Error message** | Why it failed or was skipped, when a reason exists. | | **Thread** | The thread where the run worked and where its complete output lives. | A `skipped` invocation means Hyperagent declined to start the run, most often because of a rate limit or because the endpoint owner is no longer in the workspace. An `error` means the run started and then failed; its thread contains the full context. ### Pause, resume, or delete [#pause-resume-or-delete] Pausing preserves the endpoint's URL, secret, configuration, and history while stopping new runs. Calls return `422` with `Endpoint is paused`. Resume the endpoint when you're ready to accept calls again. Deleting an endpoint is immediate and permanent. The endpoint and its invocation records are removed, and the URL stops working. Deleting the agent removes all of its endpoints too. ### Ownership on team agents [#ownership-on-team-agents] Every endpoint has one runtime owner, and its runs use that person's account and billing. All members of a shared agent can see its endpoints, but only the owner can change an endpoint's prompt, thread strategy, or secret. The next call is skipped with an owner-not-a-member note, and the endpoint pauses automatically. Another member can activate it to take ownership. Archiving the agent keeps its endpoints but makes calls return `422` until the agent is available again. ## Troubleshooting and FAQs [#troubleshooting-and-faqs] No. The endpoint returns `202 Accepted` with a run ID before the run starts, and there is no public endpoint to poll. The result lives in the run's thread. If the caller can use MCP and needs the response directly, use the agent's [MCP server](https://www.hyperagent.com/docs/concepts/agents/invocations/mcp-server) instead. Otherwise, have the webhook-triggered agent deliver the outcome to the calling system itself. You can't. Hyperagent stores only its SHA-256 hash, so no screen can recover the original. Rotate the endpoint to a new secret and update the calling system. Only for public integrations where you accept that anyone with the URL can trigger the agent and incur charges. These endpoints get an early rate limit and their runs don't auto-accept memories, but the URL is still the only access barrier. Keep the prompt narrow and add a secret as soon as the caller can send one. The endpoint exceeded a rate limit, which defaults to 60 calls per minute. Use the response's `Retry-After` header to decide when to retry. Unauthenticated endpoints have a second, earlier limit in addition to the shared invocation limit. No. Authentication uses the `X-Hyperagent-Webhook-Secret` header, not an HMAC signature of the body. There is no replay protection or IP allowlist. If you need signed payloads or network restrictions, enforce those before forwarding the request to Hyperagent. The endpoint runs under its owner. If that owner leaves, the next call is skipped and the endpoint pauses itself. Another member can activate it to become the new owner. --- # Knowledge access Source: https://www.hyperagent.com/docs/concepts/agents/knowledge-access > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. What an agent can reach and where its new knowledge is saved: read scope, attachment and discovery, save destination, knowledge profiles, and what changes on a team. Every agent starts a run with context, and after it finishes its work, it can save what it learned to use later. Define how an agent should use and save context on the agent's **Knowledge** tab, and every run inherits it. Set the boundary once and every run inherits it. The agent reads only the memories, skills, and files you allow, and any new learning is saved where you chose, not wherever it happens to land. ## The three kinds of knowledge [#the-three-kinds-of-knowledge] Facts and preferences it carries between runs: a threshold you set, how you like a report opened, who owns a process. Methods worth repeating: how to pull the weekly report, how your team decides an escalation is urgent. Documents and files it should reference directly, like a playbook, a spec, or a brand guide. Each kind has its own depth in [the knowledge docs](https://www.hyperagent.com/docs/knowledge). What follows is the boundary itself: which of them a particular agent may use, and where its own additions go. ## How an agent remembers [#how-an-agent-remembers] Two things happen around every run. Before it starts, the agent gathers what it is allowed to know. After it ends, whatever it picked up is saved. * **Access** governs *exposure*: an agent answering questions in a public Slack channel should not be able to reach a preference you told a private assistant. * **Learning** governs *accumulation*: an agent handling a hundred support conversations a week should not turn all of that chatter into memories cluttering everything else you own. The two are independent, which is more useful than it sounds. An agent can read everything you have saved while keeping everything it learns to itself, so it benefits from your context without adding to it. ## What an agent can reach [#what-an-agent-can-reach] Scope decides what information is reachable. **Which memories can this agent see** sets the outer limit: **All memories** hands it everything in your workspace, while **Only curated memories** narrows it to what you linked to this agent by hand. Within that limit, knowledge arrives four ways, and each kind of knowledge uses them a little differently. ### Manage how an agent uses memories [#manage-how-an-agent-uses-memories] When configuring an agent, you can choose which memories an agent can reference: Everything saved in your workspace, including anything you save later. Best for a private coworker that should understand your standing context without being briefed twice. Just the memories you link to this agent, and nothing else. Best for any agent other people talk to, where it should know exactly what you gave it and no more. #### Curating memories [#curating-memories] The agent draws on two banks: your workspace memories, and the agent's own memories, which belong to it alone. You can choose to let the agent pull from all those memories, or link specific ones that it should see. A linked memory is retrieved when the work calls for it; **pin** one instead and it loads into every run whether or not the run has anything to do with it. You can also point at a memory directly: type **@** in the composer to name one, and the agent loads it for that request. A pinned memory costs room in every single conversation the agent ever has. Save pins for the handful of things the role genuinely cannot operate without, like a quality standard it must apply every time or a policy it must never violate. If you find yourself pinning a fifth memory, what you probably want is a [context file](https://www.hyperagent.com/docs/knowledge/documents-and-tables). ### Manage which skills your agent can use [#manage-which-skills-your-agent-can-use] Depending on what your agent does, you may want it to discover every skill available, or only to draw from a certain set. You control this with **skill discovery.** * **On**, the agent can reach any skill you have saved globally. It works from summaries: a pinned skill puts its name and description in the prompt every run, so the agent always weighs whether this is the moment for it, and the full instructions load only when it decides to use them. * **Off**, the agent works from the attached kit alone, and starts every run holding those skills in full. That suits a narrow role you want behaving predictably, and works against you once the kit is large enough to crowd the conversation. The agent finds a skill by its **name, description, and when-to-use** text, so a method called *Weekly Pipeline Summary* with an honest note about when it applies gets found, and the same method called *Reporting* does not. #### Team agents [#team-agents] A personal agent searches all skills available to you. A [team](https://www.hyperagent.com/docs/concepts/teams) agent searches the skills its team owns or has been given, and never a teammate's private library. ### Give an agent documents to work from [#give-an-agent-documents-to-work-from] Context files are the documents and files the agent should be able to reach directly, like a playbook, a spec, or a brand guide. Attach them in the **Context files** section. Attaching a file does not push its contents into every conversation. Every run, the agent sees what is attached, each file by name and description, and it opens one to read in full when the work calls for it. A long playbook costs nothing until the moment it is relevant, and you never have to tell the agent to go and read it. If something must be considered on every single run, put the instruction in the agent's instructions rather than hoping it notices. And when what you need every run is small, a threshold or a policy line, a pinned memory holds the content directly with no file to open. ### Let an agent read its own past work [#let-an-agent-read-its-own-past-work] **Thread search** lets an agent look back through its own past conversations, picking up work it started last week, or recalling what it already tried before trying it again. Turn it on when an agent's job spans conversations. Leave it off when each run should stand alone. An agent's search covers its own threads only, so it cannot read your other conversations or another agent's. And it is unavailable entirely on runs triggered from external sources, including Slack, email, webhooks, and Telegram, so an externally triggered run can never go browsing through your history. ## Where an agent saves knowledge [#where-an-agent-saves-knowledge] When an agent learns something it should remember, it can save it to use in the future. Where it lands depends on two things: the type of knowledge, and who owns the agent. ### Memories [#memories] An agent can save a memory to two places, and this is the one destination you set yourself. * **Its own memories** belong to that agent alone. No other agent can see them, which suits a specialist whose lessons would be noise everywhere else. * **Workspace memories** are shared with every agent in that workspace: yours on a personal agent, the team's on a team-owned one. ### Skills [#skills] Skills always belong to a workspace the agent operates in. If the agent is in your personal workspace, skills are saved there. If you're using a team-owned agent, skills are saved to the team. A skill headed for a team is never saved without you. Its instructions, scripts, and any credentials it carries affect every member, so that confirmation is required no matter how much you have let the agent learn on its own. ### Documents [#documents] A document an agent writes during a run belongs to that run's thread, and so to whoever started it. The exception is a team agent producing something meant to be broadly available: that becomes a team document its members can read. For the whole picture, see [what's private and what's shared](https://www.hyperagent.com/docs/concepts/teams/whats-private). ## Choose a knowledge profile for your agent [#choose-a-knowledge-profile-for-your-agent] A **knowledge profile** sets scope, destination, and learning behavior together. So when configuring an agent, you can pick a posture that matches the agent. Reads all your memories and skills, and saves what it learns back to yours. You and the agent share one body of knowledge, so anything it picks up helps your other agents. The right default for an agent you use yourself. Reads only what you explicitly added, and learns nothing on its own. The locked-down stance, and what Hyperagent applies for you the first time an agent joins a [Slack](https://www.hyperagent.com/docs/integrations/slack) channel. Reads only what you added, but saves what it learns to its own memories. It grows with use while staying self-contained, so teammates who invoke it make it smarter without touching anything of yours. The same decisions, made one at a time. Change any single control under a named profile and you land here automatically, which is worth knowing so it doesn't surprise you. When you connect an agent's first Slack channel and its knowledge was never configured, Hyperagent switches it to Curated so channel traffic can't teach it or read your wider set of memories. You'll see a notice saying only selected memories are shared with the agent. Widen it later, once you've watched how the channel actually uses it. ### Custom settings [#custom-settings] Under **Self-learning**, a master switch decides whether the agent may learn at all, and a row for each kind of change sets how far you trust it: propose nothing, propose and wait for you, or save on its own. [Manage learning behavior](https://www.hyperagent.com/docs/learning/manage-learning-behavior) covers what each level means, who else can teach the agent, and which changes wait for review however much you trust it. ## How your agent works with team knowledge [#how-your-agent-works-with-team-knowledge] A [team](https://www.hyperagent.com/docs/concepts/teams) is a shared workspace that holds its own agents, skills, and memories. When an agent belongs to a team, the team is its workspace, so the same rule applies to a wider audience: what it saves to the workspace reaches everyone in it. A [team-owned agent](https://www.hyperagent.com/docs/concepts/teams/team-agents) works from the team's knowledge rather than any individual's. Nothing personal comes in: the agent reads the team's memories and its own, never the personal memories of whoever happens to start the run. This allows you to use a shared agent without wondering whose context is leaking into it. What it learns is the team's as well, so a lesson one person teaches reaches everybody's runs. Learn more about team knowledge in [Teams](https://www.hyperagent.com/docs/concepts/teams). ## Why the agent doesn't remember something [#why-the-agent-doesnt-remember-something] When an agent seems to have forgotten a fact, a memory has almost never been lost. Something is sitting on the wrong side of one of the two boundaries, and there are three usual culprits. * **You taught it to a different agent.** If an agent saves its learning to its own memories, the fact lives there and no other agent can see it. To share an agent-owned memory, link it to the other agent, or teach that agent directly. * **It was saved somewhere this agent doesn't read.** A memory in an agent's own memories will not appear in your personal memories, and the reverse holds too if your agent only reads its own. To fix this: change the save destination so future learning lands where you want it, then recreate the stray memory in the right place. * **It exists but was never linked.** A curated agent reads only what you linked to it, so a memory can be sitting in plain sight and still be invisible to that agent. Link it, or widen the scope to all memories if the narrow boundary is not earning its keep. ## FAQs [#faqs] Scope is what the agent can see before a run: all the memories in your workspace, or only the curated ones. Destination is who owns what it learns after a run: the workspace, or this agent alone. They're independent, and a profile only sets both together as a shortcut. That memory was probably saved to the other agent's own memories, or this agent reads only curated memories and it was never linked. Link the memory to this agent, or set this agent to read all memories. There's no move control. Change the save destination so future learning is saved where you want, then recreate the memory there. The destination setting only affects new learning, not memories already saved. No. Every skill belongs to a workspace, yours or a team's, so there's no agent-only skill. You choose the destination when you accept the suggestion, starting from the agent's own workspace. A linked memory or skill is discoverable and retrieved when relevant. A pinned one is always in context, loaded into every run. Link most things; pin only the few the role must carry every time. [How context gets into a thread](https://www.hyperagent.com/docs/concepts/threads/loading-context) covers what pinning costs. Curated, which Hyperagent applies for you when you connect the first channel. Link the exact memories, skills, and files the channel role needs, and leave learning off until you've inspected real runs. Whether channel members can teach the agent is covered in [Manage learning behavior](https://www.hyperagent.com/docs/learning/manage-learning-behavior). No. Thread search lets the agent read its own past conversations and tool history. [Memories](https://www.hyperagent.com/docs/concepts/memories) are structured facts and preferences built to travel across runs. One reaches prior discussion; the other carries curated knowledge. You can attach documents and generated files. The agent sees the attached list on every run and opens a file to read when the work calls for it, so attaching a long document doesn't crowd out the conversation. See [documents and tables](https://www.hyperagent.com/docs/knowledge/documents-and-tables). Run access does not grant configuration access. Owners and Editors manage the team's shared memories and what is linked to team-owned agents. See [Team roles](https://www.hyperagent.com/docs/concepts/teams/members). --- # Models and compute Source: https://www.hyperagent.com/docs/concepts/agents/models > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Choose from a wide model catalog and match reasoning, speed, and cost to the size of the job. Hyperagent supports a wide range of models, from fast, efficient models for routine work to frontier models built for deep reasoning. That range lets you choose the right level of thinking for the size and stakes of the job instead of giving every agent the same model. A one-line triage check does not need the same reasoning budget as a dense research brief. Give the recurring role a sensible default, then override it when one conversation needs more depth or more speed. ## Match the model to the job [#match-the-model-to-the-job] Model choice changes the quality, latency, and cost of every run. Start with the work the agent owns, then choose enough capability to do that work reliably. Classification, formatting, extraction, and simple recurring checks reward speed and a lower cost per run. Research, drafting, analysis, and multi-step tool use need dependable judgment without paying for the strongest model on every turn. Ambiguous research, difficult strategy, complex debugging, and external final work benefit from a frontier model and more reasoning effort. ## Where you choose a model [#where-you-choose-a-model] The same model choice appears in four places. Choose the surface that matches the scope you want to change. Sets the agent's default model, runtime, subagent model, turn timeout, and auto-compact threshold for new work. Changes the model for the current conversation without changing the named agent's default. Holds the same thread override beside Fast inference and Reasoning effort, so the model and its compute controls stay together. Sets the model a home thread starts on when no agent is bound. Open Agent defaults to change it. ## Set the usual model, change it when needed [#set-the-usual-model-change-it-when-needed] The model saved on an agent is the starting point for its work. You can change the model for one conversation without changing what the agent uses everywhere else. Choose the model that fits the role's recurring work. Every new thread on that agent starts with this model unless you change it inside the thread. Change the model from the thread header or Model & compute. That thread keeps the new choice; the agent's usual model and its other threads stay unchanged. A home thread that is not connected to a named agent starts with your [Agent defaults](https://www.hyperagent.com/settings/agent-defaults). Once any thread begins using a model, changing the agent's usual model does not rewrite that existing conversation. ### Latest aliases and pinned versions [#latest-aliases-and-pinned-versions] The picker opens in two sections, and which one you choose decides whether the agent moves with upgrades or stays put. Maintained aliases such as **Latest (Opus)** that track the newest version in a family. Pick one and the agent receives the family's normal upgrades with no configuration change. Hover the section for the note: *We'll automatically use the latest model in the selected family when you create a new thread.* Pinned numbered versions, grouped by provider. Pick a pin when you need repeatability, such as an evaluation or a controlled comparison, and the model stays exactly where you set it until you change it. When an alias is selected, the model chip carries a **Latest** badge. Experimental models carry an **Experimental** badge, with the tooltip *Early access, behavior and availability may change.* ## Supported model catalog [#supported-model-catalog] Hyperagent supports models from several labs, so you can match the model to the agent's job instead of rebuilding the agent around one provider. The catalog changes as models are validated; the picker is the source of truth for what is available to your account. ### Anthropic [#anthropic] | Model | Best fit | Context | | ----------- | ------------------------------------------------------------- | ------- | | Fable 5 | Highest-capability work when quality matters more than cost | 1M | | Opus 5 | Complex agents, difficult reasoning, and careful final output | 1M | | Opus 4.8 | Earlier flagship for complex work; supports Fast inference | 1M | | Opus 4.7 | Earlier Opus model for complex work | 1M | | Opus 4.6 | Earlier Opus model for complex work | 1M | | Sonnet 5 | Balanced everyday agents at lower cost than Opus | 1M | | Sonnet 4.6 | Earlier balanced Sonnet model for everyday work | 1M | | Haiku 4.5 | Quick, simple tasks and high-volume lightweight work | 200K | ### OpenAI and Google [#openai-and-google] | Model | Best fit | Context | | ----------------- | ----------------------------------------------------------------- | ------- | | GPT 5.6 Sol | OpenAI's most capable option for difficult agent work | 950K | | GPT 5.6 Terra | Balanced OpenAI option for everyday agents | 950K | | GPT 5.6 Luna | Fast, low-cost OpenAI option | 950K | | GPT 5.5 | Earlier OpenAI flagship | 950K | | Gemini 3.6 Flash | Fast structured execution, monitoring, research loops, and coding | 1M | | Gemini 3.5 Flash | Earlier fast Google model for everyday work | 1M | ### Open and specialist models [#open-and-specialist-models] | Model | Best fit | Context | | ------------------ | -------------------------------------------------------------------- | ------- | | Kimi K3 | Moonshot's highest-capability open model | 900K | | Kimi K3 Fast | Faster Kimi K3 output when latency matters | 900K | | Kimi K2.6 | Low-cost everyday work on an open model | 230K | | GLM 5.2 | Low-cost everyday agent work | 1M | | GLM 5.2 Fast | Faster GLM output for high-volume work | 1M | | Qwen 3.8 Max | Frontier coding, research, and long-horizon work | 1M | | Qwen 3.7 Plus | Cost-aware general work and coding | 230K | | DeepSeek V4 Flash | High-volume coding and tool work at the lowest cost | 1M | | DeepSeek V4 Pro | Deep reasoning on an open model | 1M | | MiniMax M3 | Low-cost search and synthesis across a large internal knowledge base | 1M | | Fugu Ultra | Coordinated expert-agent work on complex tasks | 1M | | Grok 4.6 | Longer research and analysis that ends in a decision-ready brief | 500K | | Grok 4.5 | Conversational agent work | 500K | | Muse Spark 1.1 | Creative agent work | 1M | | Inkling | Compact, low-cost open-model work | 230K | If a model you need is missing, share both the model and the job you want it to perform with the Hyperagent team. The use case helps the team evaluate quality, runtime compatibility, and demand. ## Model & compute controls [#model--compute-controls] Inside a thread, **Model & compute** gathers the model and the two dials that shape how it runs. Reasoning effort decides how hard the model thinks; Fast inference trades cost for speed on the models that support it. ### Reasoning effort [#reasoning-effort] **Reasoning effort** sets how much thinking a model does before it answers. More effort buys deeper reasoning on hard problems; less effort returns faster and costs less. The default is **Medium**, shown as *Balanced*. | Level | Reads as | | ---------- | ---------------- | | Low | Fast responses | | Medium | Balanced | | High | Deep reasoning | | Extra high | Deeper reasoning | | Max | Maximum capacity | Each model shows only the effort levels it supports, so its picker may contain a subset of these five. When a model has no configurable reasoning, the effort picker does not appear. ### Fast inference [#fast-inference] **Fast inference** runs an eligible model at higher throughput. Its helper text states the tradeoff plainly: *Faster output, billed at 2x token cost.* Reach for it on interactive replies and tight loops where latency matters, and leave it off for deep analysis and final writing where standard speed is the better fit. The toggle appears only on the models that expose it, currently **Opus 4.8** and **Opus 5**. If you don't see the toggle on the model you're using, that model doesn't offer Fast inference in Hyperagent. ### Subagent model [#subagent-model] [Subagents](https://www.hyperagent.com/docs/concepts/agents/invocations/other-agents#subagents-are-not-delegation) are short-lived workers a run spins up to handle parallel legwork on its own. **Subagent model** sets the default model those workers use. Balanced capability and cost. The default subagent model, shown as **Default (Sonnet 4.6)**. Frontier reasoning for delegated work that needs the strongest model. Fastest and lowest cost, for high-volume lightweight legwork. Match the parent agent's own model instead of a fixed tier. ### Runtime [#runtime] The **Runtime** control on the agent's Model and limits card decides which execution runtime serves the model. It defaults to *Default chooses the runtime from the selected model*, which is the right setting unless you have a specific reason to change it. ### Turn timeout [#turn-timeout] **Turn timeout** caps how long one turn may keep running. It applies to the current turn, not the lifetime of the thread: later turns can continue in the same conversation. Use a longer timeout for deep research, browser work, coding, or other jobs that may need sustained tool use. A shorter timeout gives routine or unattended work a firmer stop. If the limit is reached, Hyperagent ends that turn rather than letting it run indefinitely, and the thread keeps the record of where it stopped. ### Auto-compact threshold [#auto-compact-threshold] Every model has a finite context window. **Auto-compact threshold** decides how full a thread's active context may become before Hyperagent compacts it automatically. Compaction summarizes older conversation so the agent has room to continue; it does not remove the transcript from the thread. A lower threshold compacts sooner and leaves more headroom for upcoming work. A higher threshold keeps more of the raw conversation active before compacting. For a one-time compaction, open the model menu in the thread and choose **Compact context now**, or enter `/compact`. The thread's **Thread Context Document** survives compaction and keeps the facts, corrections, decisions, and plan tasks the agent recorded for the current job. See [how a thread keeps working context](https://www.hyperagent.com/docs/concepts/threads/thread-context). ### Live Mode model [#live-mode-model] [Live Mode](https://www.hyperagent.com/docs/concepts/agents/invocations/live-mode) runs each scheduled check on its own heartbeat model, chosen separately from the thread and defaulting to the latest Sonnet. This lets a frequent check use a faster, less expensive model without changing the model used for the agent's other work. ## When a model becomes unavailable [#when-a-model-becomes-unavailable] If a model is removed from your account, it leaves the picker and any new run that resolves to it errors with *not available for your account*. Latest aliases migrate gracefully: when a family is retired behind an alias, stored selections resolve to the model now serving that family, and the thread shows the model actually in use. ## FAQs [#faqs] Start on **Latest (Opus)**, the maintained alias described in the picker as *Auto-updates to the latest Opus, recommended for most users.* It tracks the current flagship, so the agent keeps up with upgrades on its own. Move to a faster or lower-cost model once you know a job doesn't need that much capability. The picker depends on your account and the active runtime. It is the source of truth for what you can select right now. If a model you need is missing, share the model and the job you want it to do with the Hyperagent team. Higher effort gives the model more room to think, which usually means more latency and a larger token bill per turn; lower effort returns faster and cheaper. Match the level to the difficulty of the work rather than defaulting to the top of the ladder. Not by default. [Subagents](https://www.hyperagent.com/docs/concepts/agents/invocations/other-agents#subagents-are-not-delegation) use the agent's subagent model, which starts at **Default (Sonnet 4.6)** and is set independently of the thread's main model. Choose **Parent model** if you want them to match the parent instead. --- # Command Center Source: https://www.hyperagent.com/docs/concepts/command-center > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. The cockpit for running many agents at once: catch what's waiting on you, see what's running, and track cost and quality across the fleet, then drill into the one that needs you. You're running several agents, and most of them work while you're not watching: one on a 7 AM schedule, one answering in Slack, one triggered by a webhook. You can't open each one to check on it. The **Command Center** is where you don't have to: one page that catches what's waiting on you, shows what's running, and tracks cost and quality across every agent at once. A blocked approval just waits, a runaway schedule just spends, and quality drifts with nobody in the thread. Checking the Command Center like an inbox is how an unattended fleet stays a managed one. ## It's the fleet view; one agent's view is its Activity tab [#its-the-fleet-view-one-agents-view-is-its-activity-tab] The Command Center is workspace-wide: every agent, one dashboard. That's what makes it different from an agent's [Activity](https://www.hyperagent.com/docs/concepts/agents/activity) tab, which shows a single agent's runs. You live here when you operate many agents and drill into Activity or a thread when one needs a closer look. Open it at `/command-center` from the user menu; a team workspace has its own Command Center over the team's shared fleet, and **Refresh dashboard** re-pulls the data in place. ## Clear what's waiting on you [#clear-whats-waiting-on-you] The first thing to check is whether anything is blocked on a decision from you, because an unattended agent that hits an approval or a proposed change just waits. **Needs Attention** collects exactly those items so they don't sit unseen in a sub-page. Its lead row summarizes the workspace's pending improvements and opens the queue at `/improvements`; each item below shows the start of its description and a type tag, like `New Rubric`, and links straight to where you act on it. Clearing this list is the main thing you *do* here. What these proposals are and how you review them is [Learning](https://www.hyperagent.com/docs/learning). ## See what's running right now [#see-whats-running-right-now] Before you kick off new work, **Active Operations** tells you what's already in flight across the workspace: the agent runs executing right now. When it reads **"All quiet — no active operations."**, nothing is running, which is the calm state, not a missing one. It's the fastest way to know whether an agent is still mid-task before you pile on. ## Catch a runaway cost [#catch-a-runaway-cost] Cost is the number that surprises operators of unattended fleets, so the Command Center keeps it in view. The **Total Cost** figure sits in the headline stats, and **Cost Breakdown** shows where the spend is going; **Open cost portfolio** drills into cost per agent, which is how you find the one schedule quietly running up a bill and decide whether it's worth it. ## See whether quality is holding [#see-whether-quality-is-holding] Agents drift, and a scheduled agent can degrade for weeks before anyone opens a thread. **Avg Score** in the stats and **Score Trends** over time are the early warning: a criterion sliding down is your cue to open that agent, read a low-scoring run, and fix it. The scores come from the rubrics you set in [Rubrics and evaluations](https://www.hyperagent.com/docs/learning/rubrics-and-evaluations). ## Find the agent to dig into [#find-the-agent-to-dig-into] The Command Center points; the detail lives one click away. The **Agent Roster** lists every agent with a **Search agents...** filter, and **Recent Runs** is the cross-fleet feed of what just happened. An agent opens to its own page, a run opens its thread, and that agent's full history is its [Activity](https://www.hyperagent.com/docs/concepts/agents/activity) tab. So the loop is: notice it here, drill in there, act in the thread. ## FAQs [#faqs] When you're minding more than one agent. The Command Center is the fleet view: what's blocked, what's running, and cost and quality across every agent. An agent's [Activity](https://www.hyperagent.com/docs/concepts/agents/activity) tab is one agent's run history, the place you drill into after something here catches your eye. Because nothing is running, which is the good case. The card reads "All quiet — no active operations." when the workspace has no runs in flight, and fills the moment an agent starts working. The workspace's pending improvement proposals, the learning suggestions and rubric proposals waiting for review. The card exists so a decision that's holding up an agent doesn't hide in a sub-page; each item links to the queue at `/improvements`. Yes. A team workspace has its own Command Center reporting on the team's shared fleet the same way your personal one reports on yours. --- # How Hyperagent fits together Source: https://www.hyperagent.com/docs/concepts/how-hyperagent-fits-together > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Agents carry a job into threads; skills, memories, invocations, teams, and the Library make that work reusable. **Hyperagent** is where you staff AI teammates for ongoing work. An agent carries a defined job, tools, context, and controls. Every time that agent works, it does so in a thread. The other parts of the product help the role start, remember, improve, share, and keep its output. ## The pieces [#the-pieces] The configured teammate. It owns the role, model, tools, knowledge access, controls, and invocations. [Agents](https://www.hyperagent.com/docs/concepts/agents) Where one run happens. It holds messages, tool calls, files, decisions, and the output from that conversation. [Threads](https://www.hyperagent.com/docs/concepts/threads) A reusable method. It teaches an agent how to perform a specific kind of work. [Skills](https://www.hyperagent.com/docs/concepts/skills) Saved context. It carries facts and preferences forward without turning the whole chat history into the brief. [Memories](https://www.hyperagent.com/docs/concepts/memories) A home for related goals, threads, files, and working documents. The sharing and governance surface for agents, skills, memories, and other work people should access together. [Teams](https://www.hyperagent.com/docs/concepts/teams) The gallery of outputs produced across threads, ready to find, reuse, publish, or share. [Library](https://www.hyperagent.com/docs/concepts/library) **Agent** is who shows up. **Thread** is where a run happens. **Skill** is the method. **Memory** is saved context. ## Why the parts matter together [#why-the-parts-matter-together] Each part removes a different kind of repeated setup: * Improve a **skill** once, and every linked agent uses the better method * Save the right **memories**, and you stop re-briefing standing facts * Add an **invocation**, and the job starts from Slack or a schedule without rebuilding the agent * Share a stable **agent** with a team, and other people run the same role and controls * Keep outputs in the **Library**, and work from older threads stays findable The model can change while the role stays intact. That is the point of separating the agent's job and context from the reasoning model that runs it. ## One Monday pipeline brief [#one-monday-pipeline-brief] Imagine a pipeline update that should arrive every Monday without someone restaffing the work. ### Staff the role [#staff-the-role] Create a RevOps [agent](https://www.hyperagent.com/docs/concepts/agents) with CRM access, a clear job description, and the model the judgment deserves. ### Teach the method [#teach-the-method] Attach a Weekly Pipeline Summary [skill](https://www.hyperagent.com/docs/concepts/skills) so the checklist and output format stay consistent. ### Keep the facts [#keep-the-facts] Link [memories](https://www.hyperagent.com/docs/concepts/memories) for risk thresholds, reporting preferences, and the delivery audience. Set the [knowledge boundary](https://www.hyperagent.com/docs/concepts/agents/knowledge-access) before the agent is shared. ### Start each run [#start-each-run] Add a Monday [schedule](https://www.hyperagent.com/docs/concepts/agents/invocations). The schedule starts the work, but the run still happens in a thread. ### Keep and share the result [#keep-and-share-the-result] The brief appears in the thread and its reusable output lands in the [Library](https://www.hyperagent.com/docs/concepts/library). Share the agent with the sales team when they should run the same role themselves. Start with [Agents](https://www.hyperagent.com/docs/concepts/agents) when you are staffing a recurring role. Start with [Skills](https://www.hyperagent.com/docs/concepts/skills) when you already have a method worth teaching once. --- # Library Source: https://www.hyperagent.com/docs/concepts/library > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Where thread artifacts stay organized and ready to reuse. The Library keeps the outputs from your threads in one place: documents, tables, webpages, images, videos, maps, apps, and files. Use it when you want the finished work, not the full conversation behind it. ## Where finished work lands [#where-finished-work-lands] A thread is where an agent researches, reasons, uses tools, and produces outputs. Those outputs are artifacts: the files the agent creates as it works. The Library gives those artifacts a dedicated view. They still belong to the thread that created them, so you can always return to the original context, but you do not have to retrace the whole run to find the finished piece. That matters once your account starts filling up with useful work: renewal summaries, competitor tables, or client reports. The Library is where you search, filter, open, share, and reuse what your agents have already created. ## What shows up in the library [#what-shows-up-in-the-library] The Library collects the artifacts agents create while they execute. You do not need to save them separately. You can search the Library by artifact title or filename. Filters help narrow the view by type, published status, source, saved items, global items, agent, project, thread, and archived artifacts. Markdown files the agent writes and updates for notes, explanations, research findings, briefs, account summaries, and other written work. Documents can be scoped to a thread, project, or globally. Typed rows and columns the agent builds and updates: pricing comparisons, lead lists, account trackers, or research datasets. Tables can be exported to CSV or JSON. Published HTML pages the agent designs and writes: reports, dashboards, visualizations, client pages, or embedded map views. Decks the agent designs slide by slide for reviews, briefings, pitches, or internal updates. Generated images, edited visuals, videos, audio, and talking-head avatar outputs. Interactive maps, routes, location views, Street View outputs, and other location-based artifacts. Maps appear under Webpages because they are HTML artifacts. Interactive applications the agent creates when the output needs live interaction, search, or tool access. Uploads, exports, PDFs, CSVs, code files, and other generated or attached files that are renderable types, such as images, text, PDF, and JSON. Thread and Project Context Documents are the agent's notes, so they stay out, along with system files like thumbnails and configuration exports. What you browse here is what your agents produced, not how they produced it. ## How artifacts get there [#how-artifacts-get-there] You do not create a Library item separately from the work. The agent creates outputs while working in a thread, and those outputs appear in the Library automatically. Every invocation type produces Library items the same way. Scheduled runs, webhooks, Live Mode ticks, Slack mentions, Telegram messages, emails, and MCP clients all create threads. Artifacts from those threads appear in the Library just like artifacts from manual conversations. When you open a Library item, you can click through to the source thread to see the prompt, context, tool calls, decisions, and feedback that shaped the output. ## Finding the right artifact [#finding-the-right-artifact] The Library becomes more useful as agents create more artifacts. Search and filters help you get back to the right output without digging through old threads. * **Search.** Match against the artifact title or filename. * **Category.** Narrow to images, video, audio, webpages, slides, tables, documents, or apps. * **Scope.** View everything, saved items, global items, items from a specific agent, a specific project, or a specific thread. * **Published status.** Show published items, unpublished items, or both. * **Sort.** Sort newest or oldest. * **Archived threads.** Artifacts from archived threads are hidden by default. Toggle archived items on when you need them. Library search does not search inside artifact content. It does not inspect the body of a document, the rows of a table, or the HTML of a webpage. If you remember the topic but not the exact title, narrow by project, agent, artifact type, scope, or published status. ## What you can do with artifacts [#what-you-can-do-with-artifacts] Once an artifact is in the Library, you can use it beyond the thread that created it. Open the thread behind an artifact to see the prompt, context, tool calls, decisions, and feedback that shaped the output. Publish supported artifacts with a link when the output needs to reach stakeholders, clients, or teammates. Domain restrictions can limit access by email domain. Export tables to CSV or JSON, read documents as markdown, and download files directly. Documents save a version on every edit. Webpages, slides, and HyperApps save the previous version before each edit. Add a document, table, or file as context, or @ mention a document or table in a new thread. Star important artifacts so they show up quickly in the Saved filter. Tables and media do not have version history. If you need a clear audit trail for changing written work, pages, decks, or apps, use the artifact types that keep versions. ## Reusing artifacts as context [#reusing-artifacts-as-context] Artifacts stay connected to the thread that created them, so you can always get back to the source trail: the prompt, files, tool calls, decisions, feedback, and revisions behind the output. When you want to reuse an artifact in a new run, the path depends on what kind of artifact it is. * **Documents.** Use documents when the artifact should become written context. @ mention a document in a thread, add it to an agent as a context file, share it across a project, or make it global. This works well for research notes, brand voice guides, operating principles, customer briefs, and project plans. * **Tables.** Use tables when the agent needs structured data again. @ mention a table in a thread, add it to an agent as a context file, or mark it global when a pricing table, account tracker, lead list, or dataset should be available broadly. * **Files, media, and published outputs.** Images, videos, audio, webpages, slides, maps, and files work more like finished deliverables. To reuse one, paste the published URL, attach the file, add a supported file as context, or bring over the exact reference yourself. * **HyperApps.** HyperApps have their own URL. Once created, you can open the app directly from that URL, no matter which thread produced it. For anything an agent should always have, use a context file. For anything needed once, @ mention the document or table, paste the URL, or attach the file in the thread. ## FAQs [#faqs] No. The Library gives you another way to find the output. The source thread still keeps the artifact and the context around it. Yes. Add documents, tables, or files to an agent as context files so it always have them. You can also @ mention a document or table directly in your prompt. For example: "Use the Q3 pricing table as the baseline for this renewal analysis." Supported artifacts can be published with a link. Domain restrictions let you limit access to people with an approved email domain. Use publishing when the output needs to reach stakeholders, clients, or teammates who should not need to open the original thread. Documents keep a version snapshot on every edit. Webpages, slides, and HyperApps save the previous version before each edit. Tables and media do not have version history. Search matches the artifact title or filename. It does not search inside artifact content. If you remember the topic but not the exact title, use filters for agent, project, artifact type, scope, or published status. Yes. Every invocation creates a thread. Artifacts from those threads appear in the Library the same way manual thread outputs do. To see how an artifact was created, open it and follow the **Go to thread** link. Threads keep the run. The Library keeps the artifacts organized and ready to reuse. Use it to search, filter, open, share, export, version, and reuse the documents, tables, webpages, media, maps, apps, and files your agents create. --- # Memories Source: https://www.hyperagent.com/docs/concepts/memories > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. What an agent knows about you and your work, kept as small standing records it can retrieve in future runs. A **memory** is one small standing record of something an agent may need again: your role, how you like reports written, the color scale your team uses on renewal briefs, or the channel where updates land. Save the fact once, and future work can retrieve it instead of asking you to explain it again. A memory turns stable context into something an agent can use again. Pinned and high-importance memories arrive up front; the rest are recalled when the work makes them relevant. ## A memory loads by one of three paths [#a-memory-loads-by-one-of-three-paths] A thread does not start with every memory loaded. That would crowd out the work. Instead, memories arrive through three retrieval paths. A pinned memory loads before every run that can see it, without ever being searched for. Reserve pins for the few facts every run genuinely needs. High-importance memories load at the start of a run, ahead of recall, for every agent that can access them. The UI labels this **Always include**. The rest stay out of context until the agent's recall finds them relevant to the conversation, then brings them in on demand. The choice is about timing. Put only the facts that shape nearly every run in the up-front paths; let topic-specific context wait for recall. Pinned and importance 4-5 memories load before the run, but within a [context window](https://www.hyperagent.com/docs/concepts/threads/index#when-the-work-changes-start-a-new-thread) budget. If the set that qualifies is larger than the budget, the lowest-priority ones are left out. "Always include" is the UI label for the tier, not a guarantee that every such memory appears in every run regardless of how many there are. ### How recall finds a memory [#how-recall-finds-a-memory] For everything below the up-front tiers, the agent searches its memories before it responds. That search reads three fields together: the memory's content, its **When to use** guidance, and its tags. A memory about `Stripe` can also surface on a request about `billing` or `payments` when related tags were expanded for it in the background. Specific terms carry more weight than generic ones, so precise content and tags are what make the right memory appear at the right moment. You can also point the agent at a memory directly. Ask what it knows about your renewal process, or name the context you want used, and the agent searches its knowledge and brings the matching memory into the thread. ## A memory is a few editable fields [#a-memory-is-a-few-editable-fields] Each memory is a short editable record with a handful of fields. Together they decide what the memory says, when it appears, and which agents can use it. | Field | What it controls | | --------------- | ----------------------------------------------------------------------------------------------------------------------------------- | | **Content** | The fact, preference, correction, or constraint the agent should remember. | | **Category** | The kind of memory it is, used for organizing and filtering. | | **Importance** | A 1 to 5 rating. A 4 or 5 moves the memory into the up-front tier so it loads before the run; 1 to 3 leaves it to recall. | | **Tags** | Search and organization signals. Tags feed recall, can be expanded with related terms, and make the Memories page easier to filter. | | **When to use** | Guidance that helps the memory surface on the right requests. This text is read during recall alongside the content. | | **Pinned** | Marks the memory as always in context, loaded before every run that can see it without being searched for. | Importance is the field people misread most. Raising a memory to 4 or 5 does not make it more true or more trusted; it only changes *when* the memory loads, moving it from recall into the up-front tier. Rate a memory high when the agent should carry it before work begins, and leave it low when it only matters around a specific topic. ### The eight categories [#the-eight-categories] A memory's category is one of eight kinds. They exist so you can organize and filter, not to change how a memory loads. Who you are: your name, role, company, location, and other stable personal details. How you like work delivered: tone, format, source style, level of detail, naming conventions, or units. What you are building: tech stack, constraints, timelines, goals, and project-specific decisions. Subject expertise the agent should understand: industry terms, technical concepts, market definitions, or regulatory context. Colleagues, contacts, teams, customers, and relationships the agent should recognize when they come up. Current projects, deals in flight, and other in-progress work that shapes how the agent should prioritize. Systems you use, how they connect, process patterns, and operational conventions the agent should follow. Company structure, team channels, operating rhythm, approval chains, and other institutional context. Not everything should become a memory. Current deals, one-off numbers, temporary plans, and details that only matter inside one run usually belong in the thread, a table, a document, or the connected system where they came from. ## Memories come from real runs [#memories-come-from-real-runs] Most memories start in a real run. You correct a detail, state a preference, or explain a team rule, and that context gets saved for next time. There are three ways it reaches your library. When the agent notices something worth keeping, it proposes a memory as a draft card in the thread or in a post-run review. You can save, edit, adjust importance, or dismiss it before it becomes standing context. If you allow it, an agent saves memories without showing a draft first. Use this for personal agents you trust to learn from the conversation, and keep it off for shared agents. Create a memory directly with the **New memory** button when you want to front-load context before the first conversation. Every memory records where it came from, shown on its detail view. The **Source** line reads **Agent suggested** when an agent proposed it, which covers both auto-saved memories and drafts someone later confirmed; **User created** when a person wrote it; or **Manual entry** when there is no recorded origin. In a team workspace, a **Saved by \[name]** line attributes it to the teammate who added it, and an **Origin thread** link jumps back to the conversation the memory was learned in. ## The Memories surface [#the-memories-surface] The Memories page at `/memories` is where every saved memory lives. It gives you a searchable, filterable list to review context, group by category, and clean up duplicates. The filter bar narrows the list several ways at once: * **Tags** filters to memories carrying a chosen tag. * **Category** filters by one or more of the eight kinds. * **Agent** filters to memories tied to a specific agent. * **Audience** filters by reach: **Global**, **Linked to an agent**, or **Not visible to any agent**. * **Pinned** shows only pinned memories. * **Archived** switches the whole list to archived memories, separate from the active view. Each row carries per-memory actions on hover: **Pin** or unpin, **Promote** to move an agent-owned memory into your library, and an actions menu for **Archive** or **Delete**. To work in bulk, choose **Select**, click memories to gather them, and shift-click to grab a range. The selection bar can then archive, merge, pin, or link the whole set to an agent at once. ## Every memory has one owner [#every-memory-has-one-owner] Every memory has one owner, and that location helps determine which agents can use it. The **Visibility** row on the memory detail identifies where it lives. Personal memories that your agents may use according to their knowledge settings. Use them for your role, writing preferences, company context, and facts that should not belong to one specialist alone. Memories that belong to one named agent. They deepen that role's context without adding the same fact to your other agents. Shared context that team-owned agents can use according to the workspace's access and knowledge settings. This location explains the most common "where did it go" moment. Your personal `/memories` view and an agent's own Knowledge view are different surfaces. A memory saved to **This agent's memories** stays with that role rather than appearing as one of **Your memories**. Filter by **Agent** or open the agent to find it, and use **Promote** when the fact should move into **Your memories**. For the full read and save controls, see [Knowledge and learning](https://www.hyperagent.com/docs/concepts/agents/knowledge-access). ## A memory is edited, archived, and restored [#a-memory-is-edited-archived-and-restored] A memory stays useful only while it stays accurate, so it is built to be edited, set aside, and restored. Editing a memory's content, category, importance, tags, or when-to-use saves the previous state to version history. You can review what changed and restore an earlier version. Ownership moves like Promote leave no version trail. Archiving takes a memory out of recall and out of context while keeping the record. Its status reads **Archived - not recalled** until you restore it. Archiving is reversible, so lean on it freely. Permanent deletion happens only from the archived state. Archive a memory first, then delete it once you are sure it is gone for good. ### Tending your memories [#tending-your-memories] A smaller set of current, well-maintained memories serves the agent better than a large stale one. Three habits keep the set healthy: * **Merge near-duplicates** so one fact has one home instead of several drifting copies. * **Archive liberally.** It is reversible, so there is no cost to setting aside anything you are unsure about. * **Reserve pins** for the handful of facts every run truly needs. A pin spends part of the up-front budget on every run, so a short pinned set is a strong one. ## Memory, skill, or Thread Context Document [#memory-skill-or-thread-context-document] Memories work alongside skills and the Thread Context Document, but each answers a different question. | Concept | What it holds | Scope | Example | | --------------------------- | --------------------------------------------------------- | ------------------------------------- | ------------------------------------------------------------------------ | | **Memory** | A fact the agent should carry into future work | Your memories, one agent, or a team | "Leadership updates should start with risk, movement, and next actions." | | **Skill** | A reusable method for doing a piece of work | Agents that can access or discover it | "How to review a customer escalation." | | **Thread Context Document** | Facts, corrections, and plan details for one conversation | One thread only | "In this run, use the corrected $5.5B valuation." | A memory is not a process document. If the agent should remember that updates go to `#exec-updates`, that is a memory. If it should learn the full process for writing the weekly update, that is a skill. If it should hold a number you corrected ten minutes ago in this conversation, that belongs in the Thread Context Document. ## FAQs [#faqs] First confirm that the conversation became a saved memory. Then check two controls: whether the agent can access where the memory lives, and whether recall had a reason to surface it for this request. Pin the memory only if every run needs it; otherwise improve its content, tags, or **When to use** guidance. See [Knowledge and learning](https://www.hyperagent.com/docs/concepts/agents/knowledge-access#faqs) for access troubleshooting. Most likely into **This agent's memories**. Open the agent's Knowledge tab or filter by **Agent** to find it. Use **Promote** when the fact should move into **Your memories** and become available beyond that role. Yes. Editing a memory's content, category, importance, tags, or when-to-use saves the previous state to version history, and you can restore an earlier version from the detail view. The one exception is ownership moves such as Promote and Move, which leave no version trail. No. Archiving takes a memory out of recall and out of context but keeps the record, marked **Archived - not recalled**. You can restore it at any time. Permanent deletion is a separate step available only once a memory is archived. Pin it. A pinned memory loads before every run that can see it, without being searched for. Raising importance to 4 or 5 has a similar effect through the up-front tier. Both draw on a shared context budget, so keep the always-present set small and reserve it for facts every run genuinely needs. Only if you allow auto-save for that agent. By default an agent proposes memories as drafts you review before they are saved. Auto-save suits personal agents you trust to learn from the conversation; keep it off for shared agents. --- # Skills Source: https://www.hyperagent.com/docs/concepts/skills > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. A reusable method you teach once so agents do specific work the way your team does it. A **skill** is a reusable method. It teaches agents how your team does a specific kind of work: the research process, the report format, the brand voice, the API pattern, or the checklist that makes the output trustworthy. That is different from a fact the agent should remember, and different from a tool the agent can click. A [memory](https://www.hyperagent.com/docs/concepts/memories) might say "weekly summaries go to #exec-updates." A tool might be web search. A skill says *how* to build the summary: which fields matter, what counts as risk, and what good looks like when leadership reads it. You create a skill once. The agents that need that method can use it. When you improve the skill, every agent using it gets better. ## More than instructions [#more-than-instructions] A good thread often reveals a better way to work. The agent found the right research pattern, produced the report in the format your team prefers, followed your writing voice, or figured out how to use an API that matters to your workflow. *A weekly pipeline thread might teach which CRM fields matter, how your exec team wants risks called out, and what format the final update should follow.* Without a skill, that method lives in chat history. Next week someone re-explains it, or the agent improvises a slightly different version. A skill turns the method into something you can attach, pin, discover, and share. ## What skills can teach [#what-skills-can-teach] Skills capture different kinds of reusable methods. Most real skills mix more than one. A repeatable sequence, like preparing a weekly pipeline summary, reviewing support tickets, or turning research into a client brief. Writing standards, brand voice, editorial rules, tone preferences, and examples of what good output sounds like. How to gather sources, compare companies, evaluate claims, cite findings, or build a market scan. Formats for reports, emails, briefs, tables, webpages, decks, or other outputs your team creates often. How to work with a specific system, endpoint, query pattern, or third-party service the right way. Code-backed steps for calculations, data cleanup, API calls, file transforms, or other mechanics that should run the same way every time. Global skills ship with Hyperagent and teach every agent the built-in tools' craft: media generation, composed video, file conversion, data-connection setup, and context building. Your own skills add what no platform can ship: your team's process, voice, formats, and domain expertise. ## From thread to skill [#from-thread-to-skill] Skills usually come from work you have already shaped once. The agent pulled the data, found the risky deals, drafted the exec update, and you refined the output until it matched how your team talks about revenue. That process is worth saving. In the thread, you can ask Hyperagent to suggest a skill based on the output you just created. It drafts a method you review, edit, and save. The skill should hold the repeatable part, not this week's deal list. Current numbers stay in the thread, table, or connected system. A Weekly Pipeline Summary skill might capture: which CRM fields to check, how to compare this week to last week, what counts as a risk, and how leadership wants the update structured. Once it is saved, you make it available to the agents that should call that method when the request is relevant. ## Anatomy of a skill [#anatomy-of-a-skill] Before a skill can help an agent, it needs a clear label, a clear purpose, and enough instruction for the agent to follow the method. A Weekly Pipeline Summary skill should say when to use it, which source to query, what the summary must include, and what format the team expects. Vague names like "Reporting" make discovery harder than "Weekly Pipeline Summary." What you and the agent use to recognize the skill. Specific names are easier to find and safer to pin. Situations where the method should apply. This is the main signal for discovery when the skill is not pinned. Steps, examples, constraints, inputs, and what good output looks like. This is the core of the skill. Code for repeatable mechanics, plus credential fields for services those scripts need. Values stay out of the conversation. See [Skills with APIs and credentials](https://www.hyperagent.com/docs/concepts/skills/apis-and-credentials). ## How an agent uses skills [#how-an-agent-uses-skills] Once a skill exists, the agent needs a way to bring it into the [thread](https://www.hyperagent.com/docs/concepts/threads). That is controlled by **Skill Discovery**, pin state, and how far the agent is allowed to search. ### How skills enter a thread [#how-skills-enter-a-thread] Pinned always, discovered when needed, or preloaded as a fixed kit. **Pinned skills are visible from the start.** The agent sees the skill's name and description at the beginning of the thread, so it can recognize when that method applies. A RevOps agent might keep Weekly Pipeline Summary pinned because that workflow is central to its job. **With Skill Discovery on, other skills can be found when needed.** The agent starts lean: pinned summaries first, then search when the task points at a method. Full documentation loads only when matched. Context stays available for the conversation. **With Skill Discovery off, attached skills are preloaded.** The agent starts with full documentation for its attached skills and does not search broadly. That works well for a small, fixed kit. It uses more context from the first turn. ### How agents find the right skill [#how-agents-find-the-right-skill] With discovery on, clear fields matter. A skill named "Weekly Pipeline Summary" with when-to-use text like "Use when preparing recurring sales pipeline summaries for leadership" is easier to match than a generic "Reporting" skill. If you type the skill's name in your message ("use the Weekly Pipeline Summary skill"), the agent can search for it, load the full documentation, and follow it. You do not need to attach or pin it first, as long as the agent's scope allows the search. ### Search scope [#search-scope] Search scope controls how far the agent can look when a skill is not already visible. The agent can discover skills across your knowledge base, even when they are not attached. Use when a well-built method should be available without wiring it to every agent by hand. The agent only finds skills you linked in agent settings. Use for shared or Slack-facing agents that should not pick up methods from unrelated workflows. In agent settings, the **Skill Discovery** toggle usually drives these choices together: on means discover with broader search; off means preload the attached set. Full detail on how skills load and how the discovery boundary works lives in [Knowledge and learning](https://www.hyperagent.com/docs/concepts/agents/knowledge-access#skills). ## How skills help every agent improve [#how-skills-help-every-agent-improve] Skills are portable across agents. That is what makes them compound. You might build Weekly Pipeline Summary while working with a RevOps agent. Once it works, the same method can help a Chief of Staff agent prep leadership updates or a Sales Manager agent review team performance. When the method is ready for other people, share it through a [team](https://www.hyperagent.com/docs/concepts/teams). Teammates can use the skill without rebuilding the process. Teams also control credentials: no credentials, the owner's credentials, or each person bringing their own key. When you improve the skill (tighter checklist, better examples, a fixed API method), every agent using it benefits. That is different from stuffing the same instructions into one agent's system prompt. A system prompt belongs to one agent. A skill travels to the roles that need the method. ## Skills vs agents [#skills-vs-agents] An **[agent](https://www.hyperagent.com/docs/concepts/agents)** is the configured teammate: identity, instructions, tools, integrations, and the outcome it owns. A **skill** is a reusable method that teammate can call when the request requires it. The Weekly Pipeline Summary is not the agent. It is the method. Several agents can use it for different jobs without each one becoming a copy of the same mega-prompt. Role, tools, knowledge, model, controls, and [invocations](https://www.hyperagent.com/docs/concepts/agents/invocations). Examples: RevOps Lead, Leadership Brief, Renewal Watch. Steps, examples, scripts, credentials, and when-to-use guidance. Examples: Weekly Pipeline Summary, Brand Voice Guide, API Query Method. ## How skills differ from other context [#how-skills-differ-from-other-context] Skills work alongside memories, tools, and integrations. They solve a different problem. How to handle a specific output or workflow. "Write a client brief in our format." Facts or preferences that should travel forward. "Weekly summaries go to \#exec-updates." A built-in platform action. Web search, image generation, code execution. Access to a connected external account. Slack, GitHub, Gmail, Sheets. See [Tools and integrations](https://www.hyperagent.com/docs/concepts/tools-and-integrations). Tools and integrations give capabilities and access. Memories give standing facts. Skills teach the method. ## FAQs [#faqs] When you want an agent to repeat a method, not just remember a fact. Good candidates: recurring reports, research workflows, writing formats, review checklists, API procedures, and any process you find yourself explaining more than once. One-off preferences, single facts, or context that only matters once in one thread. If the agent needs to remember a detail later, that is usually a [memory](https://www.hyperagent.com/docs/concepts/memories). If it needs to follow a repeatable process, that is usually a skill. Specific, repeatable, and testable. It says when to use it, what steps to follow, what inputs it needs, and what finished output looks like. Writing skills need samples. Research skills need a source strategy. API skills need endpoints, required fields, and failure cases. Yes. Scripts handle repeatable operations. Credential fields supply secrets at run time without pasting keys into chat. Working with an API: [Skills with APIs and credentials](https://www.hyperagent.com/docs/concepts/skills/apis-and-credentials). Day-2 editing and import: [Edit and import skills](https://www.hyperagent.com/docs/concepts/skills/skills-edit-and-import). No. It depends on Skill Discovery, pin state, attach/scope settings, and [Knowledge and learning](https://www.hyperagent.com/docs/concepts/agents/knowledge-access#skills) for shared agents, where how skills load is covered in full. When it is part of the agent's default job. A writing agent might always need a voice guide. For methods that only matter sometimes, leave them discoverable. Yes. Name the skill in the thread. If scope allows the search, the agent loads the full documentation and follows it. A skill is a reusable method that teaches agents how to handle specific workflows and outputs. Capture it once, attach it where it matters, and improve it in one place so every agent that uses it gets better. --- # Call APIs from a skill Source: https://www.hyperagent.com/docs/concepts/skills/apis-and-credentials > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Make a skill that calls an external API work reliably, with scripts and safely held credentials. [Integrations](https://www.hyperagent.com/docs/integrations) and [MCP servers](https://www.hyperagent.com/docs/concepts/agents/invocations/mcp-server) are the best starting point for giving an agent access to another service. They package the connection and available actions so the agent can get to work. When a service does not offer an integration or MCP server, an API-backed skill can connect to its API directly. Point the agent at the API documentation and describe what you want to accomplish. The agent can write the scripts, document how to use them, define the credential fields they need, and keep the method current as the API changes. ## What an API-backed skill carries [#what-an-api-backed-skill-carries] The instructions for when and how to use the API: which endpoint to call, which fields to send, and what a successful result looks like. The executable steps that should behave the same way every time, from sending the request to cleaning data or transforming a file. The agent can write and update them as the API changes. The secret inputs the script requests at runtime, such as an API key or bearer token. Field names live with the skill. Secret values stay out of its documentation, scripts, references, and threads. ## Documentation [#documentation] Documentation is the operating guide the agent reads before it runs anything. It should explain when the skill applies, which script to use, what inputs the script expects, and what a successful result looks like. Include: * The job the skill handles and the requests that should trigger it * The endpoint, authentication method, and required credential field names * The script or command to run, including required inputs and defaults * The expected output, common failure cases, and any supporting references When the agent changes an endpoint, field name, script input, or expected response, it should update the documentation in the same pass. That keeps the written method and the executable code in sync. ## Scripts [#scripts] Scripts handle the mechanics that should run the same way every time, such as sending the request, following pagination, cleaning returned data, or transforming a file. The agent writes and updates them from the API documentation. Scripts execute on the agent's remote VM, which provides the runtime and filesystem for the run. They do not run on your local computer. When the agent fetches a skill's scripts, the files are copied into that working environment; credential values are never written into them, and the source sits on disk without entering the model's context until the agent actually reads a file. Keep scripts small and predictable: * Use clear arguments or input files with documented formats and defaults * Return structured output the agent can inspect * Produce actionable errors when authentication, inputs, or the API response fail * Read secrets from credential fields instead of embedding values in source If a script fails after an edit, the agent should check that its documented inputs, credential field names, and source still agree. ## Credentials [#credentials] Credential fields define the secret values a script needs at runtime, such as an API key, bearer token, or client secret. The field name and setup instructions live with the skill. The stored value stays out of its documentation, scripts, references, and threads. ### Limit what a skill can do with its key [#limit-what-a-skill-can-do-with-its-key] When you save a sensitive value like an API key, Hyperagent asks how it should be handed to the skill. There are two choices, and for most skills the default is the one to keep. Hyperagent sends the key only to the host you name, such as `api.stripe.com`. The key never enters the agent's remote VM, so scripts and other processes in the run cannot read, copy, or forward it elsewhere. Hyperagent makes the key available to the credentialed script while it runs, and to nothing else: it is not added to the model's prompt or the agent's general environment. But because the script can read it, poorly written code could print, save, or forward it. Use this mode only when the API requires code to handle the value directly, such as signing a request, and say so in the skill's setup instructions. Keep Locked to one host. If the skill stops connecting after you switch, switch it back to Readable by scripts and it works again. Nothing is lost either way. ## Sharing skills with credentials [#sharing-skills-with-credentials] When you share a credentialed skill to a [team](https://www.hyperagent.com/docs/concepts/teams), choose how its credentials travel: Every team member can run the skill with the sharer's stored credentials. Usage is billed to the sharer's account, so use this only when every current and future member should receive that authority. Every teammate must save values for the required credential fields before running the authenticated skill. The authenticated script runs only when the required values are available. See [Teams](https://www.hyperagent.com/docs/concepts/teams) for how shared access and credentials work together. ## FAQs [#faqs] Yes. Scripts handle the repeatable operation, and credential fields supply the secrets at run time. The values are never written into the documentation, the script, or the thread. The agent should check that its documented inputs, credential field names, and script source still agree. Credential values must be entered again when the field shape changes. The skill was shared without an executable credential path. Choose whether it uses the owner's credentials or requires each teammate to bring their own. No. Describe what you want the call to do and the agent can write the script and its documentation. When the endpoint or expected response changes, the agent can revise both together. --- # Edit and import skills Source: https://www.hyperagent.com/docs/concepts/skills/skills-edit-and-import > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Bring an existing method into Hyperagent from a file or documentation, and keep it current. When you want to import a method that already lives in a file or documentation, open **Skills** and select **Create skill**. From there, you can upload the file, link the source documentation, or have an agent build the skill with you. ## Create or import from Skills [#create-or-import-from-skills] The Create skill dialog offers three paths. Choose based on where the method lives today. Upload a JSON skill export or a Markdown SKILL.md file from your computer (up to 5MB). This is the path for a skill you have already written down or exported from somewhere else. Point Hyperagent at a documentation URL, or paste the documentation text. It reads the docs and learns the method. This is the path when the process lives in another service's documentation or an API reference you want your agents to follow. Have an agent research the topic, or build the skill interactively in chat. This is the path when the method does not exist anywhere yet. Importing always creates a new skill. If the name is already taken, Hyperagent adds an imported suffix instead of replacing the skill your agents already use. To update an existing method, edit that skill directly rather than importing a fresh copy. ## Update a skill [#update-a-skill] Methods change. A threshold moves, a checklist tightens, or an API adds a field. Edit the existing skill so every agent that uses it receives the improved method on later turns and new runs. ### Open the skill [#open-the-skill] Open it from **Skills** or from an agent that uses it, then select **Edit Skill**. ### Update the method [#update-the-method] Revise the name, description, when-to-use guidance, or documentation. Keep the retrieval guidance and operating method aligned so the agent can still find the skill for the right requests and execute it correctly. ### Update scripts when needed [#update-scripts-when-needed] **Optional.** If the skill runs code, expand the affected script and update its filename, description, or source. Keep its inputs and outputs aligned with the documentation. ### Update credentials when needed [#update-credentials-when-needed] **Optional.** If the service, secret name, or script access requirements changed, update the credential fields and their setup instructions. Secret values remain separate from the skill's documentation and code. See [Skills with APIs and credentials](https://www.hyperagent.com/docs/concepts/skills/apis-and-credentials) for host locking, script access, and team sharing. ### Save and test on a new turn [#save-and-test-on-a-new-turn] Save the skill, then start a new turn with an agent that uses it. Test a request that should match the skill and confirm the updated method runs as expected. Review a saved change with the same care you would give a shared template or production script. Later turns and new runs use the updated method. ## FAQs [#faqs] File import always creates a new skill. When the name is already taken, the new row receives an imported suffix, even if the content is similar. If you meant to update the existing skill, edit it in place instead. Start a new turn and confirm the agent is attached to the skill you edited. If two skills have similar names, the agent may be matching an imported duplicate instead of the one you updated. Yes. Importing gets the method in; editing keeps it current. Open the skill and edit it in place whenever the process or the API it calls changes. If the API has documentation, link to it or paste it and let Hyperagent learn the method. If you already keep the method as a JSON or Markdown skill file, upload that. Either way, the [APIs and credentials](https://www.hyperagent.com/docs/concepts/skills/apis-and-credentials) page covers how the credentials travel. Create from a thread when a method emerges from the work. Open Skills to import a file or link documentation, then edit the skill in place as the method changes. --- # Teams Source: https://www.hyperagent.com/docs/concepts/teams > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. A shared workspace that scopes a set of agents, skills, and memories, with governance that lets many people use what a few maintain. A **team** is a shared workspace that holds its own agents, skills, and memories, separate from your personal workspace. It does two things at once: it **scopes** a set of related work into one place, and it **governs** who may use, maintain, and administer each part. Build agents your whole group runs, govern who can change them and what they learn, and watch the entire fleet from one Command Center. Governance is what makes the scale safe: roles decide who edits, review decides what spreads, so ten people can rely on an agent without ten people being able to break it. ## What a team gives you [#what-a-team-gives-you] Agents the whole team runs: owned by the team and maintained together, or shared in run-only from one person. One maintained method everyone follows, with a clear choice of whose account runs its actions. Reviewed context the team's agents draw on across threads, promoted deliberately, not by accident. Owner, Editor, and Member, so broad use never means broad control over the shared source. The whole team's fleet on one dashboard: what's running, what needs a decision, and what it costs. ## When to reach for a team [#when-to-reach-for-a-team] Reach for a team when work has outgrown one person's private setup, or when a set of agents deserves a boundary of its own. Concretely, a team fits when: * Several people should maintain the same agents or skills. * Many people should run a capability while a smaller group maintains it. * Using, maintaining, and administering should carry different permissions. * Context should be reviewed before people or agents rely on it. * A set of agents should be scoped on its own, by client or by domain. If one person owns, maintains, and uses a resource alone and it needs no boundary, personal ownership is enough. Everything the list keeps pointing back to comes down to two things: **scope** and **governance**. ## Scope [#scope] A team puts a wall around the agents, skills, and memories that belong together. That boundary is useful even when you are the only person in it. Keep a team per client company, so the agents, methods, and reviewed facts for Acme never mix with Globex's. Keep a team per area of expertise, one for support, one for growth, each with its own agents and context. What belongs to one team stays out of the others, and out of your personal workspace, until you decide otherwise. People are something you add to a scope, not a requirement for making one. Add people, and those scoped agents become a shared system. Picture a support group running three: With [agent delegation](https://www.hyperagent.com/docs/concepts/agents/agent-delegation), Scout hands a resolved case to Scribe, which drafts documentation using the team's skills and memories, and Press publishes the approved result. The team holds the agents, methods, and reviewed context that make that handoff the group's, not one person's. ## Governance [#governance] A team's whole safety model is one split: everyone can **use** what the team has, but only some can **change** it. Three mechanisms enforce that split, and each has a page for the details. * **Roles decide who can change what.** Every Member runs the team's agents and reads its memories; Editors maintain the shared agents, skills, and context; one Owner administers the team itself. The smallest role that fits someone's job is the right one. See [Team roles](https://www.hyperagent.com/docs/concepts/teams/members). * **Ownership decides who maintains a given resource.** A team-owned agent or skill belongs to the team, so Owners and Editors edit it; a personal one shared in stays with its owner, who keeps the source while the team gets run-only access. See [Team agents](https://www.hyperagent.com/docs/concepts/teams/team-agents) and [Team skills](https://www.hyperagent.com/docs/concepts/teams/team-skills). * **Review decides what becomes shared truth.** An agent keeps a new observation to itself until an Owner or Editor promotes it into the team's shared memories, so one agent's guess never becomes the whole team's rule by accident. See [Team memories](https://www.hyperagent.com/docs/concepts/teams/team-memories). Whoever starts a run owns its thread and its outputs, whether the agent is team-owned or shared by a person. The team maintains the capability; it does not collect a shared folder of everyone's results. Teams govern collaboration, not payment. By default each person's usage bills to them; separately, an organization can turn on [shared billing](https://www.hyperagent.com/settings) so members' usage routes to one payer. You set it up in account settings, not on the team, but it's the natural companion when a group works together. ## Explore the team [#explore-the-team] Make a team, invite people by email or link, and manage membership. Decide who should administer, maintain, or use team resources. Who can see your runs and their outputs, and what a team agent can never reach. Choose team ownership or a run-only share for an agent. Share one maintained method, choose which account runs it, or fork it. Shared context, agent-specific learning, and deliberate promotion. Watch the team's whole fleet: what's running, what needs you, cost and quality. ## FAQs [#faqs] No. A team is a scope before it is a group: keep one per client or per domain and the agents, skills, and reviewed context for each stay cleanly apart, even with you as the only member. People are something you add to a scope, not a requirement for making one. Who maintains it. A team-owned agent belongs to the team, so Owners and Editors edit its configuration together. A personal agent shared in stays with its owner, who keeps the source while the team gets run-only access. Every member can run both kinds; the split is about change, not use. [Team agents](https://www.hyperagent.com/docs/concepts/teams/team-agents) covers moving between the two. Whoever started the run. The thread and its outputs belong to the person who ran the agent, whether the agent is team-owned or shared in. The team maintains the capability; it does not collect a shared folder of everyone's results. One exception is worth knowing: the team's Owner can read runs on agents the team owns, read-only, so someone is accountable for what shared agents do. See [What's private and what's shared](https://www.hyperagent.com/docs/concepts/teams/whats-private). No, and a denied change stays denied: Hyperagent does not quietly save an attempted team edit as personal data instead. Members run agents and read team memories; Editors and Owners maintain the shared source. When curating shared context is part of someone's job, give them Editor. See [Team roles](https://www.hyperagent.com/docs/concepts/teams/members). Not by itself. Each person's usage bills to them by default. An organization can turn on [shared billing](https://www.hyperagent.com/settings) so members' usage routes to one payer, but that lives in account settings, not on the team; they are separate, related settings. --- # Create a team and add people Source: https://www.hyperagent.com/docs/concepts/teams/create-a-team > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Make a team workspace, invite people by email or a shared link, assign the role each person needs, and manage membership as it changes. A team starts as an empty workspace. Create it, bring people in, and give each person the [role](https://www.hyperagent.com/docs/concepts/teams/members) that matches their responsibility. Create the workspace, invite people by email or a reusable link, and assign a role as each person joins. Membership and roles stay yours to change as the group evolves. ## Create the team [#create-the-team] Whoever creates a team workspace is its first Owner. It starts empty: no agents, skills, or memories until you build them or bring them in. Name it and invite people from the team's settings. ## Invite people two ways [#invite-people-two-ways] Enter a person's email, pick the role they'll join with, and **Send invite**. The invite is bound to that address, so it's the right choice when you know exactly who should join and as what. Share one reusable link with a group. Anyone who opens it can join the team, so use it for a known circle and regenerate it if it should stop working. It is separate from an email invite, not a copy of one. Either way, the person joins by opening the invite: they can follow the link or paste the invite code, and they land in the team with the role the invite carried. ## Assign the smallest role that fits [#assign-the-smallest-role-that-fits] Every invite carries a role. Invite most people as **Member**, so they can run the team's agents and read its memories; save **Editor** for whoever maintains shared agents, skills, and context, and **Owner** for whoever is accountable for the team. Roles change later, so start narrow. [Team roles](https://www.hyperagent.com/docs/concepts/teams/members) has the matrix. ## Manage membership as it changes [#manage-membership-as-it-changes] From the same Members settings, an Owner can: Move someone between Member, Editor, and Owner as their responsibility changes, using the role control next to their name. Take a person out of the team. They lose access to the team's agents, skills, and memories; the threads and outputs they already produced stay theirs. Step out of a team you're in. If you're the only Owner, hand ownership to someone else first. One guardrail is worth knowing: a team must always have an Owner, so Hyperagent won't let you demote or remove the last one. To hand a team off, promote another member to Owner first, then step down. Deleting the team entirely is an Owner action and a deliberate one, separate from removing people. ## FAQs [#faqs] An email invite is bound to one address and the role you chose, so it admits exactly that person as exactly that role. The team link is reusable and admits anyone who opens it, which is why it suits a known group and should be regenerated if it leaks. They're independent mechanisms, not two views of the same invite. Member. It lets someone run the team's agents and read its memories without changing the maintained source. Give Editor to the people who maintain shared agents, skills, and memories, and Owner only to those accountable for membership and settings. Roles are easy to change later, so start with the smallest one that fits. No. A team always needs an Owner, so the last one can't be demoted or removed. Promote another member to Owner first, then change or drop your own role. Their access to the team's shared agents, skills, and memories ends, but the threads and outputs they already produced remain theirs. Removing a person is an access decision, not a delete of their work. --- # Team roles Source: https://www.hyperagent.com/docs/concepts/teams/members > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Choose Owner, Editor, and Member by what each person needs to run, maintain, or administer. Roles split responsibility by outcome, so broad use never requires broad authority. Someone can run Scout every day without touching its escalation logic; someone else can maintain Scout and Scribe without managing who belongs to the team. Owners administer the team, Editors maintain its shared agents and context, and Members run what the team has built. Each person gets what their job needs and nothing they'd have to be careful with. ## Permission matrix [#permission-matrix] ## Choose the smallest role that fits [#choose-the-smallest-role-that-fits] A support rep runs Scout, uses its escalation skill, and reads approved team memories. A documentation specialist improves Scribe and curates the context it needs. The person accountable for membership, roles, settings, permanent deletion, and read-only oversight of other people's runs. Match the role to ongoing responsibility, not seniority. Start narrow and widen it later, since Editor access to membership nobody needs is a risk, and a Member who should be maintaining Scribe is a bottleneck. ## Roles don't reach shared personal resources [#roles-dont-reach-shared-personal-resources] Roles govern what the team owns. A personal agent or skill shared with the team stays under its owner's control: Editors can run Press but not edit it, and only its owner can change its configuration. When several people need to maintain it, make it team-owned. ## Denied memory changes [#denied-memory-changes] When a Member tries to add or change Team memory, Hyperagent denies the change. It does not save the attempted Team update as personal data instead. The result is either a permitted team change or no change, never a personal memory that looks like the team update worked. Give someone Editor when curating shared context is part of their job. ## FAQs [#faqs] Member. It lets someone run the team's agents, use its skills, and read approved team memories without changing the maintained source. Editor is for the people who improve those resources; Owner is for whoever is accountable for the team itself. No. Membership, invitations, roles, and team settings are Owner-only. Editors maintain the team's agents, skills, and memories, which is a deliberate separation: maintaining a shared agent shouldn't come with control over who belongs. No. A shared personal agent stays under its owner's control whatever your role. Editors can run it and nothing more. If several people need to maintain it, it should be team-owned instead. The change is denied outright. It doesn't quietly become a personal memory that looks like the team update worked, so there's never any doubt about whether shared context changed. Only the team's Owner, read-only, on agents the team owns. Editors can maintain a shared agent without seeing what anyone did with it, and Members see only their own threads. The grant exists so someone is accountable for what the fleet does. See [what's private and what's shared](https://www.hyperagent.com/docs/concepts/teams/whats-private). Yes, and it usually should. A team must always have at least one, so the last Owner can't be demoted or removed. Promote a second Owner before anyone needs to step down. --- # Team agents Source: https://www.hyperagent.com/docs/concepts/teams/team-agents > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Choose between a team-owned agent and a personal agent shared with a team for run-only access. A team makes an agent available two ways: the **team owns** it, or a person **shares** their personal agent for run-only use. Both let every member run it. They differ in who may change it, which is the decision that matters after the first run. Either model gets the agent in front of your team today. Only one of them decides who fixes it next month. The team's Agents tab keeps the two apart, so you can always tell which model an agent is on. ## Two ownership models [#two-ownership-models] The agent belongs to the team. Owners and Editors edit its configuration; every member runs it. * **Who maintains it:** Owners and Editors, together * **What they can change:** instructions, skills, tools, connected integrations, and its [execution mode](https://www.hyperagent.com/docs/concepts/agents/configuration) * **Choose it when** the agent's job belongs to the team's workflow rather than one person's Team ownership also lets agents work as a system. Scout triages a case, [delegates](https://www.hyperagent.com/docs/concepts/agents/agent-delegation) to Scribe when the resolution should become documentation, and hands the approved result toward Press. That handoff lives in the shared configuration, so Owners and Editors maintain it once and Members use it without redefining it each run. How each agent gets started, on a schedule, from Slack, or by another agent, is covered in [Invocations](https://www.hyperagent.com/docs/concepts/agents/invocations). Scout and Scribe fit here: support and documentation specialists maintain them together. The agent stays personal and the team gets run-only access. Its owner keeps everything else. * **Who maintains it:** the person who shared it, alone * **What the team can do:** run it, and nothing more, whatever their role * **Its context:** only what was already available to the agent, never its owner's wider library * **Choose it when** teammates should benefit from the agent without becoming its maintainers To share, use **Share…** on your agent and pick the team. Nothing transfers: no copy is made, and the team can't edit the source. If Press needs a new publishing connection, only its owner can add it. Revoking the share is an access decision, not an ownership change: Press stops being runnable through that team, nothing is deleted, and the team keeps no frozen copy. Share it again later and the same relationship comes back rather than a duplicate. A shared agent uses only the context already available to it. Press keeps its linked publishing preference, gains nothing else from its owner's personal library, and absorbs nothing from whoever runs it. ## Move an agent between personal and team [#move-an-agent-between-personal-and-team] Sharing grants access; a **move** changes who owns the agent. Reach for it when maintenance should change hands: a personal agent whose job has become the team's, or a team agent that should go back to one person. ### Start the import [#start-the-import] Open the team's **Agents** tab and choose **Import**, then pick the personal agent that should become the team's. ### Review what moves [#review-what-moves] The confirmation lists what changes hands: the agent's configuration, its own memories, and its threads, which are re-stamped to the team workspace. It tells you how many threads that is before you commit. Linked documents get a per-document choice: copy into the team, or leave behind. ### Confirm [#confirm] From then on Owners and Editors maintain the agent and every member can run it. The reverse move, demoting a team agent to one person, works the same way, and pauses the agent's automations so a schedule doesn't keep firing under changed ownership. Whichever model an agent is on, the person who starts a run owns the resulting thread and its outputs. Agent ownership decides who maintains the capability, not who owns the work it produces. ## FAQs [#faqs] Ask who fixes it next month. If several people should improve it, make it team-owned. If you should keep maintaining it and teammates only need to run it, share it. No. A shared agent reaches only the context already available to it. It gains nothing from your wider personal library, and it doesn't absorb the context of whoever runs it. The team stops being able to run the agent through that share. Nothing is deleted, and the team keeps no copy. Share it again later and the same relationship comes back rather than a duplicate. They do. The thread and everything it produces belong to whoever started the run, on either ownership model. Agent ownership decides who maintains the capability, not who owns the work. Sharing grants run access and leaves ownership alone. Importing moves the agent into the team, so Owners and Editors maintain it from then on. A move is heavier: threads are re-stamped to the new workspace, and Hyperagent tells you how many are affected before you confirm. --- # Team memories Source: https://www.hyperagent.com/docs/concepts/teams/team-memories > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. How a team agent's learning becomes shared context During a thread, a team agent learns that enterprise refunds require Finance approval. Once saved, that correction can guide the agent's future runs. It doesn't become guidance for every team agent until an Owner or Editor reviews and promotes it. An observation can help the agent that made it immediately. It becomes team guidance only after an Owner or Editor reviews and promotes it. **Team memories** are the reviewed policies, decisions, conventions, and facts that team-owned agents can use across their work. ## Agent memory or team memory [#agent-memory-or-team-memory] A team-owned agent can draw from its own memories and the team's shared context. Keep learning with one agent when it belongs to that role; promote it when other team agents should rely on the same guidance. Reviewed context that team-owned agents can retrieve according to their knowledge settings. Context that belongs to one team agent. It can help that role without changing what the rest of the team relies on. ## Manage shared context [#manage-shared-context] Team memories live on the team's **Workspace memories** page. The list groups memories by owner and can be filtered by category, agent, audience, pinned, or archived. Every team role can read shared memories. Owners and Editors add, edit, archive, and organize them; only Owners delete them permanently. See [Team roles](https://www.hyperagent.com/docs/concepts/teams/members) for the complete permissions matrix. ## How learning becomes shared [#how-learning-becomes-shared] ### The agent saves what it learned [#the-agent-saves-what-it-learned] Learning from a team agent starts in that agent's own memories. The new context can help the same role again without changing guidance for the rest of the team. ### An Owner or Editor reviews it [#an-owner-or-editor-reviews-it] They confirm that the memory is accurate, durable, and useful beyond the agent that learned it. ### They promote it to Team memories [#they-promote-it-to-team-memories] The same memory moves into the team's shared context. The originating agent can still use it, and promotion doesn't create a duplicate. When the team already knows a policy or decision, an Owner or Editor can add it directly with **+ New workspace memory** instead of waiting for an agent to surface it. ## Promote or move a memory [#promote-or-move-a-memory] Use the memory's actions menu to change who owns it. Both actions stay inside the team workspace. Move an agent-owned memory into shared context after it has been reviewed. The originating agent keeps access through the team memory. Give a team memory to one agent when the context no longer belongs in shared guidance. Earlier agent links are cleared. Neither action creates a copy or moves context into someone's personal library. A team-owned agent uses the team's context and its own memories, not the personal memories of whoever starts the run. A personal agent shared with the team keeps the same knowledge access it already had; sharing it doesn't open the team's memories or another person's private context. Version history records edits to a memory's content. It doesn't record ownership changes such as Promote to Team memories or Move to an agent. Check the memory's current location to see who can use it now. ## Related guides [#related-guides] * [Memories](https://www.hyperagent.com/docs/concepts/memories) explains memory fields, retrieval, editing, archiving, and the full ownership model. * [Knowledge access](https://www.hyperagent.com/docs/concepts/agents/knowledge-access) controls which memories an agent can retrieve and where it saves new knowledge. * [Manage learning behavior](https://www.hyperagent.com/docs/learning/manage-learning-behavior) controls when an agent may suggest or save new memories. ## FAQs [#faqs] Because learning starts narrow on purpose. A team agent's new memory belongs to that agent until an Owner or Editor promotes it, so one agent's learning doesn't become shared guidance before review. No. Promotion broadens who can use the same memory. The agent that learned it keeps access, and there is only one record to maintain. No. **Promote to Team memories** and **Move to an agent** both stay inside the team workspace. Neither action pulls from a personal library or pushes into one. No. A team-owned agent uses the team's memories and its own, regardless of who starts the run. A personal agent shared with the team keeps the knowledge access it already had. Not from version history. It records changes to a memory's content rather than moves between owners. Check the memory's current location to see who can use it now. --- # Team skills Source: https://www.hyperagent.com/docs/concepts/teams/team-skills > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Share reusable methods with a Team, choose which account runs them, and decide when to use the shared source or fork it. A skill gives an agent a reusable method. Team skills let many people and agents follow the same one without keeping a copy each. Improve the shared skill and every agent using it improves with it. Nobody redistributes anything, and nobody is quietly running last quarter's version. Four choices shape how a Team skill works: Decide whether Owners and Editors maintain it together or one personal owner keeps the source. Make it discoverable across the workspace or link it only to named agents. Run actions through the sharer's account or require each member to connect their own. Follow the maintained method or create an independent variation. ## Choose who maintains it [#choose-who-maintains-it] A skill can be **Team-owned** or **shared from a personal owner**. **Owners and Editors maintain it together.** Every Team member can use the shared method. Choose this for an operating practice the Team owns, such as the escalation procedure Scout uses to classify urgent support requests. **One person maintains the source.** The Team uses that skill by reference. Choose this when one person should remain accountable for the method while several teammates or agents use it. A shared personal skill stays connected to the original rather than becoming a frozen copy. When its owner clarifies how Scribe should format troubleshooting steps, every agent using it gets the new version immediately. Delete the personal skill and the Team keeps no snapshot. Use a shared skill when that dependency is intentional; use Team ownership when it isn't. ## Choose which agents can use it [#choose-which-agents-can-use-it] Owning a skill and exposing it are separate decisions. On the skill's **Agents & Discoverability** section, two controls decide who can pick it up. Any agent or thread in the workspace can find and use the skill without anyone attaching it first. It joins the pool every agent searches. Link specific agents and only they get the skill, regardless of what the rest of the workspace can discover. Leave a general method discoverable so agents pick it up when the work calls for it. Restrict a skill to named agents when it's specialized enough that another agent reaching for it would be a mistake, or when it carries credentials only certain agents should act through. ## Choose whose account performs actions [#choose-whose-account-performs-actions] Sharing a method doesn't decide whose account performs its actions. When a skill carries credentials, sharing offers two choices: Runs use the account connected by the person who shared the skill, and members do nothing. Use this for an approved shared account with one accountable maintainer; the connected service sees that account, its access, and its limits. If the sharer's credentials go missing, a member's next run posts a **Credentials missing** card in the chat rather than a dead end: they can add their own credentials to run it themselves, or ask the owner to restore the setup. Each runner connects their own account, so actions carry the runner's identity and access. **Open the shared skill.** It shows who shared it and the amber status **Needs your credentials to run**. **Select Add credentials.** The member enters their own keys, which stay encrypted and are never visible to the person who shared the skill. **Run as yourself.** The status changes to **Using your credentials**, and every action carries that member's identity and access. If a member runs it before connecting, nothing fails silently. The run stops and posts a card in the chat: A member can also choose their own credentials on a **Use my credentials** skill: opening it offers **Use my own credentials instead**, and their account takes over for their runs from then on. ## Use the shared source or fork [#use-the-shared-source-or-fork] Source improvements remain current for everyone using the skill. The new personal copy can change without affecting the shared source, and later source updates do not flow into it. Most teammates should follow the team's documentation style skill so Scribe holds the standard. A technical writer who needs a different structure for API references forks it and gets an editable variation without touching the team's version. The tradeoff is maintenance. A fork can diverge freely, but its owner now owns it, and later improvements to the shared source never reach it. Fork when divergence is the point, not to make one small edit. ## FAQs [#faqs] The team loses it. A shared skill is used by reference rather than copied, so there's no frozen snapshot left behind. When the team shouldn't depend on you keeping it alive, make it team-owned. Whichever mode was chosen when it was shared. **Use my credentials** runs everything on the sharer's account, so the connected service sees one identity. **Each member adds their own** makes each runner connect first, so actions carry their own identity and access. If the skill is set to **Each member adds their own**, they need to connect their own account before the credentialed part will run. The method is shared with them either way; only the external action is blocked. Edit the shared one when the change is an improvement everyone wants. Fork when you genuinely need a variation, and accept that you now maintain it: later improvements to the shared source won't reach your copy. No. A writing standard, a checklist, or a decision framework has no external account to act through, so it just runs. --- # What's private and what's shared Source: https://www.hyperagent.com/docs/concepts/teams/whats-private > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Who can see your runs and their outputs on a team, what a team agent can and can't reach, and where a document ends up when an agent makes one. Working on a team raises a question personal work never does: when I run a shared agent, what of this is mine, and who else can see it? The answer comes down to one rule. A team shares agents, skills, and reviewed context. It does not gather everyone's conversations into one place. Start a run and the thread and everything it produces belong to you, with one deliberate exception for the person accountable for the team. ## One run, start to finish [#one-run-start-to-finish] Follow a single run and every rule shows up in order. A support rep on the Support operations team asks **Scout**, an agent the team owns, to work through a backlog of escalations. **What Scout brings to the run.** The team's memories and skills, plus anything attached to Scout itself. Not the rep's personal memories: a team agent never reads the personal knowledge of whoever starts it, so nothing from their private work leaks into a shared agent's run. **Where the conversation lives.** The thread belongs to the rep who started it. Their teammates, including Editors who can edit Scout's configuration, cannot open it. **What Scout produces.** The summary, the table, the published page: all of it lands in the rep's thread and their Library, owned by them like any other work. **What Scout learns.** A lesson from the run goes wherever Scout's save destination points, which on a team agent is the team's memories or Scout's own. That's the one thing designed to outlive the rep's thread, because a shared agent that learns only for one person isn't shared. **Who else can look.** The team's Owner, and no one else. That grant is read-only, it covers agents the team owns, and it exists so the person accountable for the team can audit what the fleet is doing. ## What never crosses [#what-never-crosses] Three boundaries hold no matter how the team is configured. A team agent reads the team's memories and its own, never the personal memories of the member running it. Your private context stays out of shared work. Members and Editors see only their own threads. Editing a shared agent does not come with the ability to read what other people did with it. Sharing an agent with a team does not widen what it can reach. It uses the context already available to it, not everything its owner has. ## Who can open someone else's run [#who-can-open-someone-elses-run] | | Can open another member's run | | ------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------- | | **The person who ran it** | Yes. The thread and its outputs are theirs. | | **Owner** | Read-only, on agents the team owns, from the agent's Activity tab. Artifacts from those runs come with it. | | **Editor** | No. Editors maintain the agent; they don't read other people's work with it. | | **Member** | No. | | **The owner of a personal agent shared with the team** | Their own agent's runs only. An agent shared in rather than owned by the team stays outside the Owner's grant. | Owner oversight is something a person does, not a capability any agent gets. An agent searching past conversations is limited to its own threads, and that search is switched off entirely for runs started from Slack, email, webhooks, Telegram, and channels, and for teammates running an agent shared with them. ## Where a document ends up [#where-a-document-ends-up] Documents follow the same rule as everything else, with one wrinkle worth knowing before you go looking for a setting that doesn't exist. * **What you create is yours.** A document you make in the app is personal, whatever scope you give it. * **What a run creates lives with the run.** It sits in the thread that made it, owned by whoever ran it. * **What a team agent creates for the whole team is a team document.** When a run on a team agent creates a document meant to be broadly available, it lands in the team's shared documents, where every member can read it, Owners and Editors can curate it, and Owners can delete it. * **Moving an agent into a team asks about its documents.** The move offers a choice for each linked document: copy it into the team, or leave it behind and drop the link. Team documents come from a team agent's own work or from an agent move. If you want teammates to have something you wrote, attach it to a team agent they run, or ask the agent to produce the shared version. ## Keep something to yourself [#keep-something-to-yourself] If a piece of work should stay entirely yours, run it on a personal agent rather than a team-owned one. Nothing about a team-owned agent's run is hidden from the team's Owner, and no setting changes that: the audit path is the point of it. Personal agents have no such grant, so their runs stay yours even when the agent is shared for others to run. ## FAQs [#faqs] No. Members and Editors see only their own threads. The team's Owner can read runs on agents the team owns, read-only, from the agent's Activity tab. That is the only cross-member path. Not on an agent the team owns. The oversight grant exists so someone is accountable for what shared agents do. When work should stay private, run it on a personal agent. No. It reads the team's memories and its own. This holds regardless of who starts the run, which is what keeps your private context out of shared work. Whoever started the run. The thread, the files, and the published pages are theirs, and they appear in their Library. The team maintains the agent, not a shared folder of everyone's results. There's no direct control for it. A team document is created by a team agent's own work, or by copying a linked document into the team when an agent moves there. To get material in front of teammates, attach it to a team agent they run. The threads and outputs you produced remain yours. Leaving ends your access to the team's agents, skills, and memories, which is an access change rather than a transfer of your work. --- # Threads Source: https://www.hyperagent.com/docs/concepts/threads > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. A thread is one piece of work kept together: the conversation, the agent's workspace, and everything it produced. Threads are isolated by default and connected on purpose. A **thread** is one piece of work: the conversation, the agent's workspace, and everything it produced, kept together. Ask an agent to turn interview notes into a launch brief, and the thread holds what you asked, what the agent did, what changed after your feedback, and the finished brief. Everything about a job stays together: the request, the files, the tools that ran, the corrections you made, and the finished output. Nothing to reassemble later and nothing to hunt for. ## A thread holds one piece of work, front to back [#a-thread-holds-one-piece-of-work-front-to-back] You start a thread by asking for something, in the composer or from an existing conversation. An [invocation](https://www.hyperagent.com/docs/concepts/agents/invocations) starts one the same way for its agent: a schedule firing at 7 AM, a Slack mention, an inbound email. Whoever starts it, the work gets the same container. Inside it live the conversation you can read, the private workspace where code and files run, the [Thread Context Document](https://www.hyperagent.com/docs/concepts/threads/thread-context) holding the agent's facts and plan, and the finished outputs. Open an output and it fills the canvas beside the conversation, the same pane where you can watch the agent's browser live or browse its workspace files. What surrounds that view is just as much part of the thread: a private workspace with Python and Node.js where the agent executes code, the tools it can call, and the settings that bound it. [What's in a thread](https://www.hyperagent.com/docs/concepts/threads/whats-in-a-thread) covers the full working environment. ## A thread keeps working after you leave [#a-thread-keeps-working-after-you-leave] Once the agent is working, the thread lives on the server rather than in your browser tab. Close the laptop, switch devices, lose your connection: the agent runs by itself until the work is done, pausing only when it needs your input, like an approval or a question only you can answer. To call it off early, click **Stop** in the composer while it's running. Work already finished stays in the transcript. [Run, stop, and fork a thread](https://www.hyperagent.com/docs/concepts/threads/running) covers the details. ## When the work changes, start a new thread [#when-the-work-changes-start-a-new-thread] Everything the agent carries in a conversation competes for the model's **context window**, the finite space it can actually pay attention to. A long thread fills that window with its own history, so an old conversation steered somewhere new spends attention on work that no longer matters, and eventually starts [compacting](https://www.hyperagent.com/docs/concepts/threads/running#long-threads-and-compaction) older messages into summaries to make room. A fresh thread starts with the whole window available for the new work. ## Threads are isolated by default, connected on purpose [#threads-are-isolated-by-default-connected-on-purpose] One thread's conversation never leaks into another. Each piece of work starts clean, which is what keeps an agent's threads predictable: no stray context from last week steering this week's work. When work **should** cross threads, you say so, and there are real mechanisms for it: Turn on [Thread Search](https://www.hyperagent.com/docs/tools/research#search-across-your-own-threads) and the agent can look through your earlier conversations for the decision or detail it needs, without you locating the thread yourself. Under any agent reply, click Fork from here. It copies the conversation up to that message into a new thread, so you can try a different direction with a running start. Save a fact as a [memory](https://www.hyperagent.com/docs/concepts/memories) or a method as a [skill](https://www.hyperagent.com/docs/concepts/skills), then attach either to a later thread with the composer's + button. Outputs land in the Library. | Part of the work | Where it remains | | --------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | | **Conversation and tool history** | In this thread. Another thread does not inherit the transcript. | | **Thread Context Document** | In this thread, including across compaction. It does not become cross-thread memory. | | **Finished outputs** | In the transcript and Library. Their own scope determines which future threads can use them. | | **Saved memories** | Available to future work according to what that agent can reach, set in [Knowledge access](https://www.hyperagent.com/docs/concepts/agents/knowledge-access). | | **Saved skills** | Reusable by agents that can discover or access the method. | | **Named-agent configuration** | Carried by that agent into new threads; it does not belong to one conversation. | ## Start general, or start with a named agent [#start-general-or-start-with-a-named-agent] Use a generalist thread when you are exploring an unfamiliar task or do not need a standing role. Its browser login persistence belongs to this thread. If the work becomes repeatable, Save as agent turns it into an editable named agent. An agent-bound thread begins with that agent's identity, instructions, tools, integrations, and knowledge. Browser persistence belongs to the agent and can support its other threads. There's no way to switch the bound agent mid-conversation. When the work belongs with a different agent, fork or start fresh. You can still change the bound agent's tools, integrations, and attached knowledge, and those apply from the next turn. ## Go deeper [#go-deeper] ## FAQs [#faqs] No. A thread stays generalist or bound to the agent it started with. Fork or start a new thread to move the work to another agent. You can still change the bound agent's tools, integrations, or available knowledge; live capability changes apply from the next turn. Because threads are isolated by default: each piece of work starts clean, without an old conversation steering the new one. What the agent should carry forward is explicit instead. Save a fact as a [memory](https://www.hyperagent.com/docs/concepts/memories) or a method as a [skill](https://www.hyperagent.com/docs/concepts/skills), attach either with the composer's **+** button, or turn on [Thread Search](https://www.hyperagent.com/docs/tools/research#search-across-your-own-threads) so the agent can find the earlier conversation itself. Nothing stops. The thread runs on the server, not in your browser, so the agent keeps working and you can pick it up on another device. It pauses only when it needs you, for an approval or a question only you can answer. It summarizes older messages to free room in the context window, so a long thread can keep going. The transcript you can read is unaffected, and the Thread Context Document survives compaction intact, which is where the agent keeps facts it needs to stay exact. Not by default. A thread belongs to whoever started it, even on an agent your team owns. The one exception is the team's Owner, who can review runs on team-owned agents. See [what's private and what's shared](https://www.hyperagent.com/docs/concepts/teams/whats-private). No. Finished outputs stay in their thread's transcript and in your Library, reachable from anywhere. Starting fresh only leaves the old conversation behind. --- # How context gets into a thread Source: https://www.hyperagent.com/docs/concepts/threads/loading-context > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. What the agent starts a run with, what surfaces as the conversation moves, and what it fetches on demand: memories, skills, files, tool results, and integration data. You've given the agent plenty: instructions, memories, skills, files, tools, connected apps. A thread doesn't start with all of it. The model's context window is finite, and an agent that packed everything it owns into every run would leave no room for the work itself. Instead, context arrives three ways, and knowing them answers most "why didn't it use that?" questions. A run starts with the essentials, gets shown what's relevant as the conversation moves, and fetches the rest the moment the work calls for it. ## Carried in from the start [#carried-in-from-the-start] Some things are in the thread before the first word, because every run needs them: * **The brief.** The agent's instructions, snapshotted into the thread when it's created. * **Pinned memories.** A pinned [memory](https://www.hyperagent.com/docs/concepts/memories) loads in full on every run that can see it, before anything is searched for. * **Always include memories.** Memories rated importance 4 or 5 also load up front, but within a fixed context budget. If more of them qualify than the budget holds, the lowest-priority ones are left out, so "Always include" is a strong bias, not a guarantee that every one appears every time. * **Pinned skills.** A pinned [skill](https://www.hyperagent.com/docs/concepts/skills) puts its name and description into the system prompt on every run, so the agent weighs it each time it plans. It reads the full instructions only if it decides to use the skill. * **Context files.** Documents and files attached to the agent are listed by name and ID on every run, so the agent always knows they exist, but their full content is not loaded up front. The agent opens one with a tool call when the work calls for it. Attaching makes a file available and visible, not resident in every run. * **The thread's own notebook.** The [Thread Context Document](https://www.hyperagent.com/docs/concepts/threads/thread-context), so a continuing thread picks up its working memory. Pins are the part of this tier that costs real room, because a pinned memory rides along in full on every single run. That is why pinning is a budget you spend, not a default you reach for; the listings for skills and files are cheap by comparison, since they carry only a name until the agent opens them. ## Surfaced as the conversation moves [#surfaced-as-the-conversation-moves] Each turn, Hyperagent matches what's being discussed against the agent's knowledge and surfaces what's relevant: memories that bear on the topic, and skill summaries that look applicable. It surfaces them by their **name, description, and when-to-use** text, so the agent sees enough to know an item exists and what it's for, then pulls the full content only if it decides to use it. You can see what surfaced. **Knowledge hints** on a response name the memories and skills that informed it, and the tool results below show the context the agent fetched to answer, so what shaped a run stays visible rather than hidden. ## Fetched when the work calls for it [#fetched-when-the-work-calls-for-it] The rest arrives because the agent decides it needs it, mid-run: * **Knowledge it searches.** The agent searches its skill and memory library, gets summaries back, and loads full documentation only for what it chooses. [Knowledge and learning](https://www.hyperagent.com/docs/concepts/agents/knowledge-access#skills) covers this in depth, including the discovery setting that widens or narrows the search. * **Documents and tables it opens.** A [document](https://www.hyperagent.com/docs/knowledge/documents-and-tables) is read when the work references it; a table is opened when the agent needs the rows. @mentioning one in your message is a direct instruction to go get it. * **Tool results.** A web search, a browser session, a code run: the tool executes and its result lands in the transcript, where it's context from then on. A large result doesn't have to: the agent can save it as a file in the thread's workspace and read just the parts it needs, so a big export sits on disk without occupying the context window. * **Integration data.** Connecting an app loads nothing by itself. It gives the agent tools it can call, and data enters the thread only when a call happens: reading a Slack channel, pulling CRM records, opening a sheet. What arrived is visible in the thread's record. Once fetched, it stays: everything that enters a thread becomes part of its record, which is what lets a later turn build on an earlier tool call without repeating it. Type **@** in the composer to name a specific document, table, skill, memory, or past [thread](https://www.hyperagent.com/docs/concepts/threads), and the agent loads that item for this request instead of waiting to discover it. A mention is a direct instruction: use this, now. ## How the agent decides what to load [#how-the-agent-decides-what-to-load] It reads the same signals you would. When the work mentions an invoice process, the agent searches for skills about invoices; when a question touches a customer, it looks for memories about that customer; when your message @mentions a table, it opens that table. It navigates by names, descriptions, and when-to-use notes, which makes those fields the highest-leverage writing in your knowledge base: The few facts and methods every single run needs. Pinning everything crowds out the work; pinning nothing makes the agent rediscover its own job. Write memory content, skill descriptions, and table descriptions like signposts. Specific beats broad: the search that loads them matches meaning. When you already know what the agent should read, @mention the table or name the document. A direct pointer beats waiting for discovery. ## Related [#related] ## FAQs [#faqs] It probably never found it. With discovery on, the agent searches by meaning, so a skill whose name and description don't resemble the task stays invisible. Sharpen the description or when-to-use note, pin the skill if every run should consider it, or @mention it directly. See [Knowledge and learning](https://www.hyperagent.com/docs/concepts/agents/knowledge-access#skills). No. Attached documents and files are listed by name and ID on every run, so the agent knows they exist, but the full content is fetched only when the agent opens one. Attaching makes a file available and visible, not resident in every run. To keep a short file in front of the agent from the start, pin it. No. A connection gives the agent tools, not data. Nothing from the app enters a thread until the agent calls one of those tools during a run, and everything it reads is visible in the thread's record. Because threads don't share history. What a tool call brought into one thread is part of that thread's record, not the agent's knowledge. If a fact should carry across runs, make it a [memory](https://www.hyperagent.com/docs/concepts/memories); if a dataset should, promote the [table](https://www.hyperagent.com/docs/knowledge/documents-and-tables). --- # Run, stop, and fork a thread Source: https://www.hyperagent.com/docs/concepts/threads/running > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. A run is the agent working through your request. It keeps going after you leave, ends when the work is done or when you stop it, and can be forked from any point without losing the original. A **run** is the agent working through your request, from the moment you send it until it stops. It happens inside the thread, where you can watch each step, leave and come back, or end it yourself. ## A run keeps going after you leave [#a-run-keeps-going-after-you-leave] Once the agent is working, the run lives on the server, not in your browser tab. Closing the tab, navigating away, switching devices, or losing your connection does not stop it. The agent works on its own until the request is done, and when you return the thread reconnects to the current state and fills in what you missed. A finished run opens on its result; an active one resumes streaming from where it is now. ## A run ends when the work is done, or when you stop it [#a-run-ends-when-the-work-is-done-or-when-you-stop-it] Most runs end on their own, when the agent finishes the request. The rest end for a reason you can see in the thread. | How it ends | What happens | | ----------------------- | ------------------------------------------------------------------------------------------------------------- | | **Finished** | The agent completed the request and the result stays in the thread. | | **Waiting on you** | An approval request or a clarifying question pauses the run until you respond, then it continues. | | **Timed out or failed** | The run hits its turn timeout or an unrecoverable error; the messages, files, and tool results so far remain. | | **Stopped** | You chose **Stop**. Work ends immediately and everything produced so far stays in the thread. | **Stop** sits beside the live processing indicator while the agent is working. Reach for it when the direction is wrong, a source needs correcting, or the rest of the work is no longer worth running. For a run that paused or ended unexpectedly, see [Troubleshoot a stuck run](https://www.hyperagent.com/docs/reference/runtime-limits). ## A thread names itself [#a-thread-names-itself] You never have to title a thread; it names itself from the work, so a month of them stays recognizable. The name lands in two passes: a quick title near the start of a run so the thread is identifiable right away, then a fuller name, summary, and tags once the run finishes successfully. Rename it yourself anytime from the caret beside its name, and that title is authoritative, so automatic naming won't overwrite it. Between self-naming and your own titles, threads stay findable months later, whether you scan the list or search from `Cmd+K`. ## A long run compacts to stay within the context window [#a-long-run-compacts-to-stay-within-the-context-window] A run can go on for a long time, but the model's [context window](https://www.hyperagent.com/docs/concepts/threads/index#when-the-work-changes-start-a-new-thread) is finite. At the thread's auto-compact threshold, Hyperagent summarizes older messages to free room for more work, and you can trigger it yourself with **Compact context now**. Compaction doesn't end the run or erase the transcript you read. It changes only what the model carries forward directly: the older conversation becomes a summary, while the separate [Thread Context Document](https://www.hyperagent.com/docs/concepts/threads/thread-context) preserves the exact numbers, corrections, constraints, decisions, and plan the agent recorded. Compaction keeps one run going, but it isn't a reason to keep every thread going forever: when the work has genuinely changed, a [fresh thread](https://www.hyperagent.com/docs/concepts/threads/index#when-the-work-changes-start-a-new-thread) starts with the whole window available. ## Fork to branch a run without losing it [#fork-to-branch-a-run-without-losing-it] Sometimes a run is going well and you want to try a different direction without spending the one you have. **Fork from here** branches it. Hover any message in the transcript, choose **Fork from here**, and Hyperagent opens a new thread that copies the conversation up to that point, so the fork begins with the same history the original had at that message. From there the two are independent: push the fork somewhere new while the original stays exactly as it was. A fork carries some state by copy and some by reference: | Part | What the fork receives | | ------------------- | ----------------------------------------------------------------------------------------------------- | | **Messages** | The conversation through the selected message. Later messages stay only in the original. | | **Thread settings** | The model, learning, and visual choices from the original. | | **Skills** | Links to the skills the original thread was using. | | **Files** | References to the original files rather than new copies. Deleting a referenced file affects the fork. | | **Tables** | The same shared tables, so both threads can read and write the data. | Fork when you want a running start from where this thread already is; start a [new thread](https://www.hyperagent.com/docs/concepts/threads/index#when-the-work-changes-start-a-new-thread) when the next piece of work doesn't need any of this thread's history. ## FAQs [#faqs] Fork when you want a running start from where this thread already is, so you keep its history, settings, and skill links. Start a new thread when the next piece of work doesn't need any of this thread's context, or when the goal has genuinely changed and the old history would only crowd the context window. It's better to fork than to steer one thread two ways at once. Fork from the point where the paths split, and each direction gets its own thread with the shared history behind it. The original stays intact, and neither branch has to work around the other's context. No. The run continues on the server until it finishes, hits its timeout, needs an approval, errors, or you choose **Stop**. When you reopen the thread it catches you up to the current state. --- # Thread Context Document Source: https://www.hyperagent.com/docs/concepts/threads/thread-context > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. The agent's working memory for a run: the facts, corrections, decisions, and plan it keeps in a document you can read while it works. You're watching the agent work, and off to the side a panel is quietly filling in. A checklist ticks itself off as steps complete. A short list of facts grows: a number you gave it, a correction you made, a decision it settled on. That panel is the **Thread Context Document**, the agent's working memory for this run, kept where you can read it as it happens. As the agent works, it writes down the facts and the plan it needs to hold onto. That notebook lives in the thread, updates in real time, and is yours to read whenever you want to know what the agent is holding. ## Every thread has one, and the agent maintains it [#every-thread-has-one-and-the-agent-maintains-it] Every thread produces one **Thread Context Document**. It belongs to that thread alone, and the agent maintains it as the run unfolds. | Section | What the agent records | | -------------------- | ---------------------------------------------------------------- | | **Plan Tasks** | The steps in longer work, checked off as they finish. | | **Numbers & Values** | Figures that need to remain exact. | | **Corrections** | Facts or assumptions you changed during the run. | | **Constraints** | Rules, limits, and requirements the work must follow. | | **Key Entities** | The people, companies, products, or other subjects in play. | | **Decisions** | Choices the run has committed to and should not reopen casually. | | **Notes** | Other working context worth preserving for this thread. | The document updates while the agent runs. A newly recorded fact appears in the panel, and Plan Tasks advance as steps finish, so you can see the agent's current understanding without reconstructing it from the transcript. ## It survives compaction [#it-survives-compaction] When a conversation grows long, Hyperagent compacts older messages into a summary so the agent can keep working within the model's [context window](https://www.hyperagent.com/docs/concepts/threads/index#when-the-work-changes-start-a-new-thread). A summary preserves the direction of the conversation, but it can smooth over an exact number or correction. The Thread Context Document is stored separately from that message history. After compaction, the agent can read the document again and recover the exact facts, constraints, decisions, and plan it recorded. See [Run, stop, and fork a thread](https://www.hyperagent.com/docs/concepts/threads/running#long-threads-and-compaction) for when compaction happens and when a fresh thread is the better choice. ## Where you see it [#where-you-see-it] The Thread Context Document surfaces in the thread's Activity panel. A chip summarizes the current state at a glance, showing how many plan tasks are done and how many facts the agent has recorded. Open it and you get the full document: the plan checklist and every fact section, rendered in a panel you can dock beside the conversation or float over it. The panel streams live during a run. As the agent completes a task or records a fact, you see the checklist advance and the sections grow without refreshing anything. ## Thread Context Document or memory [#thread-context-document-or-memory] Holds the facts, corrections, constraints, decisions, and plan that keep one thread coherent. It survives compaction but doesn't carry into another thread. Preserves a fact or preference that should be available beyond this conversation. Future threads can retrieve it according to the agent's knowledge settings. A corrected number that only matters to this run belongs in the Thread Context Document. A reporting preference worth applying next time belongs in a [memory](https://www.hyperagent.com/docs/concepts/memories). ## Read it, and correct it in chat [#read-it-and-correct-it-in-chat] Read the document mid-run instead of reconstructing the agent's understanding from the transcript. Its facts and decisions make a wrong assumption easier to catch before it shapes the output. Tell the agent what the right value is in chat. It updates the document, and the corrected fact survives the rest of the run with the other recorded context. ## FAQs [#faqs] The reliable way to change what the agent is holding is to correct it in chat. Tell the agent what the right value is, and it updates the document to match. Because the agent maintains the Thread Context Document as it works, a correction you make in the conversation is what carries through the rest of the run. No. The Thread Context Document belongs to one thread and means nothing outside it. It's working memory for a single run, not knowledge the agent carries around. The thing that crosses between threads is a [memory](https://www.hyperagent.com/docs/concepts/memories), which is where a fact worth reusing later belongs. --- # Thread settings Source: https://www.hyperagent.com/docs/concepts/threads/thread-settings > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Every dial for one conversation in one place: the model and how hard it thinks, subagents, execution mode and turn timeout, tools, appearance, the run's cost, and what it proposes to keep. Thread settings are where you make one conversation behave the way this piece of work needs, without touching the agent everywhere else. They open from the settings control in the thread header, in three tabs: **Configuration** for what the run can do, **Usage** for what it has cost, and **Learning** for what it proposes to keep. A named agent sets the standing default; a thread setting layers on top of it for this conversation. Leave a dial untouched and it inherits the agent's value; change it and the thread's choice wins, everywhere else left alone. ## How every setting here resolves [#how-every-setting-here-resolves] One rule governs the whole Configuration tab, so it is worth learning once. Each control has an agent default and an optional thread override. When the thread override is unset, the run inherits the agent's value; when you set it, the thread value wins for this conversation. The exception is anything that latches at the thread's first run, like the runtime, which is fixed for the life of the thread once set. Two settings inherit slightly differently and are worth knowing: * **The turn timeout** can be set at three levels, agent, thread, and per turn from the composer, and the most specific one wins. * **The system prompt** is snapshotted into the thread when it starts, so later edits to the agent don't rewrite a running thread. When the agent has moved on, the panel shows **Prompt is out of date**; **Update agent config** pulls the latest prompt into this thread, and **Reset to agent** returns an overridden thread to the agent's current values. ## The Configuration tab [#the-configuration-tab] The Configuration tab is a single scrolling panel of collapsible sections. Here is the whole panel; each section is documented in full below. ### Model & compute [#model--compute] Four controls decide which model runs and how hard it works. * **Default model** picks the model for this thread. The picker offers the models compatible with the thread's runtime (see below). * **Fast inference** trades cost for speed: **Faster output, billed at 2x token cost.** Turn it on when latency matters more than token spend. * **Reasoning effort** sets how much the model thinks before it answers. Higher effort means deeper reasoning and more tokens. Not every model exposes the full ladder, and some fixed-reasoning models show no picker at all. | Level | What it's for | | -------------- | ---------------- | | **Low** | Fast responses | | **Medium** | Balanced | | **High** | Deep reasoning | | **Extra high** | Deeper reasoning | | **Max** | Maximum capacity | * **Runtime** is the execution environment that serves the model. **Default** lets Hyperagent choose the runtime that matches the selected model. The runtime latches when the thread's first run starts, and after that the model picker offers only compatible models. Start a new thread when the work needs a model on a different runtime. See [how the runtime is selected](https://www.hyperagent.com/docs/concepts/agents/models#runtime). ### Subagents [#subagents] **Subagents** controls whether this thread can dispatch short-lived subagents to work in parallel. These are temporary workers inside the run, not named agents reached through an invocation, and **Subagent model** sets which model they use. Their cost is attributed in the **Usage** tab. Delegating to named specialist agents is a separate capability, covered in [Agent delegation](https://www.hyperagent.com/docs/concepts/agents/agent-delegation). ### Autonomy & safety [#autonomy--safety] Two controls decide how freely the run acts, and for how long. **Execution mode** decides whether the agent pauses before sensitive actions. It is the same choice as the composer's Plan/Execute menu, so setting it in either place moves the other. | Mode | Behavior | | ------------- | ------------------------------------------------------------------------------------------------------- | | **Auto** | Agent runs everything end-to-end without stopping. | | **Ask first** | Agent pauses for approval before sensitive actions like sending messages or modifying external systems. | One consequence is worth knowing: a run with no one watching cannot pause for approval, so **Ask first** collapses to **Auto** on background runs (a schedule, a webhook, a one-way email). Keep a person in the loop through a channel, or a thread you're watching, when approval matters. See [Invocations](https://www.hyperagent.com/docs/concepts/agents/invocations) for which runs are attended. **Turn timeout** caps how long a single turn may run before it stops. **Max duration before the agent is stopped.** The presets and the three levels it can be set at are in [Limits that bound a run](#limits-that-bound-a-run). ### Capabilities [#capabilities] **Tools** lists the tools this thread can use. On an agent-bound thread this layers over the agent's **Tools** baseline: turning a tool off here leaves it off for this conversation without changing the agent everywhere else. For what each tool does and the full list with defaults, see [Tools](https://www.hyperagent.com/docs/tools). ### Visual [#visual] **Visual** settings change how the thread is presented to you, such as its appearance, and nothing about what the agent does. ## Limits that bound a run [#limits-that-bound-a-run] A run isn't open-ended. Three limits control how long a turn can work, when older context is summarized, and how much a message can carry. **Turn timeout** caps how long a single turn may run before it stops. The default is 60 minutes, and you can pick from preset spans: | Preset | Good for | | ----------- | ------------------- | | **10 min** | Quick tasks | | **30 min** | Standard tasks | | **60 min** | Long research tasks | | **90 min** | Extended tasks | | **4 hours** | Ambitious builds | You can set the turn timeout on the agent, on the thread, or per turn from the composer, and the most specific choice wins. **Auto-compact threshold** decides when a long thread starts summarizing older messages to free room in the [context window](https://www.hyperagent.com/docs/concepts/threads/index#when-the-work-changes-start-a-new-thread). It defaults to **Default**, which compacts once the window is nearly full, and you can move it earlier or later: | Preset | Effect | | ----------- | ---------------------------------------------- | | **Default** | Compact when the context window is nearly full | | **50%** | Compact early | | **60%** | Compact early | | **70%** | Balanced | | **80%** | Keep more context | | **90%** | Keep more context | You can also compact on demand with **Compact context now**, whose tooltip reads `Summarize the conversation so far to free up context`. For what compaction does to a run, and how the Thread Context Document survives it, see [Run, stop, and fork a thread](https://www.hyperagent.com/docs/concepts/threads/running#long-threads-and-compaction). A single message can carry up to 20 files, up to 100 MB in total. A file that's too large is refused with a note that it must be smaller and a suggestion to split it, compress it, or share a link instead. ## See what a run has cost [#see-what-a-run-has-cost] A run costs something, and the thread shows you what. The **Usage** tab reports this thread's own consumption: the total cost, a line-item breakdown of where it went, cost attributed per tool, and the cost of any subagents the run spun up. The model chip in the thread header carries a lighter, live view: its popover shows the running session cost and a context gauge, with **View detailed usage** as the link through to the full accounting. ## Review what a run proposes to keep [#review-what-a-run-proposes-to-keep] A finished run can propose a memory, skill, prompt improvement, or agent-configuration change. The **Learning** tab shows the suggestions from this conversation, where you can inspect what would change before saving, applying, or dismissing it. Nothing suggested becomes lasting knowledge until its learning level allows it. See [Suggestions and auto-learning](https://www.hyperagent.com/docs/learning/manage-suggestions) for how proposals are raised and reviewed everywhere. ## FAQs [#faqs] The most specific one. The agent sets the standing default, the thread's Autonomy & safety section overrides it for this conversation, and a per-turn choice from the composer overrides both for that single turn. Because the runtime latched when the thread's first run started, and the picker offers only models compatible with it. Start a new thread when the work needs a model on a different runtime. See [What's in a thread](https://www.hyperagent.com/docs/concepts/threads/whats-in-a-thread#the-runtime-the-thread-inherits). Because a background run has no one to approve. Ask first pauses for a human, so on unattended runs like schedules, webhooks, and one-way email it collapses to Auto rather than hang waiting. Route the run through a channel where a person can reply, or keep it in a thread you're watching, when approval matters. The agent's instructions are snapshotted into a thread when it starts, so edits you make to the agent later don't rewrite a conversation already running. When the agent has changed since, the panel shows **Prompt is out of date**; **Update agent config** pulls the latest prompt into this thread, and **Reset to agent** returns an overridden thread to the agent's current values. No. Thread settings layer over the agent's baseline for this conversation only. To change the standing default every new thread starts from, edit the agent itself. --- # What's in a thread Source: https://www.hyperagent.com/docs/concepts/threads/whats-in-a-thread > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. How a thread brings context, tools, connected apps, controls, and finished outputs together so an agent can complete a piece of work. Ask an agent to turn customer notes into a renewal brief. It reads the files you attach, recalls the account context it already knows, checks the CRM, researches anything missing, analyzes the numbers, and drafts the finished document. You review the work, correct a date, and approve an action without leaving the conversation. It gives the agent the context to understand the work, the capabilities to act, and a place to return the finished output. It gives you the controls to guide, approve, and inspect that work as it happens. Bring in the request, files, agent instructions, saved knowledge, and live data the work needs. Research, browse, use connected apps, run code, and create with Hyperagent's built-in tools. Return documents, tables, webpages, slides, media, apps, and files with the record of how they were made. ## Get the right context into the work [#get-the-right-context-into-the-work] The thread starts with the request and gathers more context as the work develops. Some context arrives immediately; other material surfaces or gets fetched only when it becomes relevant. Messages, uploaded files, and anything you @mention enter directly from the composer. A named agent brings the role and instructions that frame the job, plus the boundary that determines which saved knowledge it can retrieve. The conversation and [Thread Context Document](https://www.hyperagent.com/docs/concepts/threads/thread-context) keep the current facts, corrections, decisions, and plan connected to this job. Search results, integration records, browser activity, documents, tables, and tool output join the thread when the agent retrieves them. The agent can reach more than it carries in the model's context window. See [How context gets into a thread](https://www.hyperagent.com/docs/concepts/threads/loading-context) for what arrives up front, what surfaces when relevant, and what is fetched on demand. ## Take action with tools and connected apps [#take-action-with-tools-and-connected-apps] Once the agent understands the job, it can act through built-in tools and the integrations available to the thread. Code execution is one part of that capability set, alongside research, browser work, connected apps, and creation tools. Search the web, search past threads, and control a live browser on sites that require navigation or an authenticated session. Read and act in services such as Slack, a CRM, or a spreadsheet through the integrations, credentials, and permissions available to the run. Use Python, Node.js, and standard command-line tools in a private run environment. Files written there persist across turns in this thread. Build Documents, Tables, Slides, Webpages, HyperApps, Images, Video, Audio, Avatar clips, Transcriptions, Maps, and files. For every built-in capability, when to use it, and how tools differ from integrations, see [Tools and integrations](https://www.hyperagent.com/docs/tools). ## Stay in control while the agent works [#stay-in-control-while-the-agent-works] A thread remains interactive while the run is active. You can add information, handle protected actions, change direction, or adjust this conversation without changing the agent everywhere else. **Bring the right material into the thread** Upload files, @mention a document, table, skill, or memory, and point the agent at exactly what it should read. You can also highlight text in a reply or output and reference that passage in your next message. See [how context gets into a thread](https://www.hyperagent.com/docs/concepts/threads/loading-context). **Change direction without waiting for the turn to finish** Send another message while the agent is working. Leave it in the queue, edit it before it sends, or steer it into the active turn when it should change what the agent is doing now. **Keep protected actions in your hands** Protected actions pause for your approval. A live browser session can also be handed to you for a login or anything you would rather do yourself. Built-in search and browser tools can reach the web as part of their job; code asks before reaching a new domain. A network grant applies only to this thread. Later requests to the same domain can continue without asking again; another thread starts with its own grants. **End the run or branch from a decision point** Correct the agent mid-run, Stop an active turn, or Fork from here on any message to try a different direction. See [run, stop, and fork](https://www.hyperagent.com/docs/concepts/threads/running). **Tune this conversation without changing the agent** Change the model, tools, or timeout for this conversation without touching the agent's defaults, from [Thread settings](https://www.hyperagent.com/docs/concepts/threads/thread-settings). ## Keep the output and the record behind it [#keep-the-output-and-the-record-behind-it] The result does not disappear into the last message. The finished work, the visible history of the run, and the context needed to continue all remain attached to the thread. Documents, tables, webpages, slides, images, media, apps, and saved files appear as cards in the transcript and entries in the Library. Messages, tool activity, approvals, corrections, and output cards remain in order so you can inspect how the result was reached. Working files persist across turns, and the Thread Context Document keeps the facts and plan the agent needs to continue this thread. A finished run may suggest a memory, skill, prompt improvement, or configuration change. A suggestion is not lasting knowledge until its learning mode allows it to be saved or you approve it. See [Suggestions and auto-learning](https://www.hyperagent.com/docs/learning/manage-suggestions). ## Know the boundaries of a run [#know-the-boundaries-of-a-run] 60 minutes by default, adjustable from 10 minutes to 4 hours on the agent, the thread, or per turn from the composer. The most specific choice wins. By default a long thread compacts older messages when the context window is nearly full; you can move the threshold as low as 50% or compact on demand. 100 MB in total. A larger source set needs to be split, compressed, or shared by link. The runtime latches on the thread's first run; after that the model picker offers only compatible models for this conversation. The controls for all four live in [Thread settings](https://www.hyperagent.com/docs/concepts/threads/thread-settings), with the full preset tables. Changes there apply to this conversation without changing the named agent's standing defaults. ## Go deeper [#go-deeper] ## FAQs [#faqs] Because running code is part of how the agent works, not an optional add-on. It writes and runs code in the thread to analyze data, transform files, and assemble results, so execution is always available and has no on/off switch. The other tool groups are toggleable; this one isn't. No. Network grants are per thread, so a domain you allowed here still prompts in a different thread. Within this thread, later requests to an allowed domain go through without asking again. No. A run environment that has been sitting idle sleeps and takes a moment to wake on your next message, so the first reply can be a little slower than usual. Nothing is lost while it sleeps: your files and the run's state are still there once it's awake. A working file stays in the thread's run environment so the agent can keep using it across turns. A saved output appears as a card in the transcript and in the Library, where you can find and reuse it later. --- # Start here Source: https://www.hyperagent.com/docs/get-started > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Agents carry the job, threads hold the work, and everything they learn stays with them. Hyperagent is where you work with AI agents that do real work. Not chatbots that answer questions and forget you. Agents with names, instructions, tools, and knowledge that stays. The whole product fits in one loop: ## Your path [#your-path] Four short lessons, each ending where the next begins. An hour, start to finish. ### Your first thread [#your-first-thread] Do real work in five minutes with nothing configured. [Start a thread](https://www.hyperagent.com/docs/get-started/your-first-thread). ### Your first agent [#your-first-agent] Turn a job worth repeating into a teammate. [Make an agent](https://www.hyperagent.com/docs/get-started/your-first-agent). ### Teach it something [#teach-it-something] Save your first memory and feel the product learning with you. [Teach it](https://www.hyperagent.com/docs/get-started/teach-it-something). ### Put it where you work [#put-it-where-you-work] Move the agent to Slack, a schedule, or your inbox. [Pick a surface](https://www.hyperagent.com/docs/get-started/put-it-where-you-work). ## Three words you'll see everywhere [#three-words-youll-see-everywhere] * A **thread** holds one piece of work: the conversation, the tools that ran, and everything produced. [Threads →](https://www.hyperagent.com/docs/concepts/threads) * An **agent** is a teammate you configure once: name, instructions, tools, knowledge. The same agent shows up in a thread, in Slack, or on a Monday schedule. [Agents →](https://www.hyperagent.com/docs/concepts/agents/configuration) * **Learning** is how agents get better: they propose memories and skills from real runs, and you decide what sticks. [Learning →](https://www.hyperagent.com/docs/learning) Curious how all the pieces connect before you start? [How Hyperagent fits together](https://www.hyperagent.com/docs/concepts/how-hyperagent-fits-together) draws the whole system. --- # Put it where you work Source: https://www.hyperagent.com/docs/get-started/put-it-where-you-work > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Move the agent to Slack, a schedule, or your inbox, so the work starts without you. So far, every run started with you opening a thread. The last step is making the work start where it actually shows up: a teammate's question in Slack, a Monday morning, an email landing in an inbox. Don't wire up every channel on day one. Ask where this job comes from today, and put the agent exactly there. One surface, done well, changes your week. ## The three most people start with [#the-three-most-people-start-with] The job is calendar-shaped: "every Monday at 7, the report should exist." The agent runs before you're online and the result is waiting. [Schedules →](https://www.hyperagent.com/docs/concepts/agents/invocations/schedules) The team asks for this work in a channel. Deploy the agent there and they mention it like a coworker; answers land in the same conversation. [Slack →](https://www.hyperagent.com/docs/concepts/agents/invocations/slack) The work arrives as messages: forwarded contracts, requests, reports to digest. Give the agent an address and forwarding becomes delegating. [Email →](https://www.hyperagent.com/docs/concepts/agents/invocations/email) There are more doorways when you need them: webhooks from your systems, your coding agent over MCP, Telegram, even other agents handing off work. [Every surface, compared →](https://www.hyperagent.com/docs/concepts/agents/invocations) ## What one looks like running [#what-one-looks-like-running] Whatever the surface, the shape is the same: the trigger starts a run, the agent brings its instructions and knowledge, the work happens in a thread you can open, and the result goes where you pointed it. ## Automate on the agent's Invocations tab [#automate-on-the-agents-invocations-tab] Open your agent and go to its **Invocations** tab. Each surface is a card: add a schedule with its message and delivery, connect a Slack channel, or turn on an email address. Every invocation is configured, trusted, and paused on its own. Two habits keep automation safe: * **Shape the job in threads first.** Automate once the output is right more often than not, not before. * **Start with less trust.** Scheduled runs default to read-only in your connected apps; widen it after you've watched a few runs succeed. ## FAQs [#faqs] The one the work already arrives on. If you'd put the result in Slack anyway, deploy to Slack. If it's a standing deliverable, schedule it. Matching the surface to the job beats any general ranking. The run is the same: a thread, with the agent's instructions and knowledge. What changes is who can start it and how much trust it starts with. Outside-triggered runs begin more conservative, and you loosen each surface on its own terms. It pauses and asks: approvals and questions land in your [Inbox](https://www.hyperagent.com/docs/learning/manage-suggestions) and the thread. Nothing sensitive happens silently just because you weren't watching. That's the loop: work in threads, promote the job to an agent, teach it what you're tired of repeating, and put it where the work arrives. From here, the [Platform docs](https://www.hyperagent.com/docs/concepts/threads) go deep on any piece you want to master. --- # Teach it something Source: https://www.hyperagent.com/docs/get-started/teach-it-something > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Save your first memory and feel the product learning with you. Your agent did the job, and somewhere in the thread you corrected it: the report should open with the number, the deadline is Thursday, the client's name is spelled Kaczmarek. Say it once more next week and you're training a goldfish. Save it, and you never say it again. A memory is a fact the agent carries into every future run. Teach it the things you're tired of repeating and each thread starts further ahead. ## Save your first memory [#save-your-first-memory] In the thread where you made the correction, just ask: ``` Remember this: reports for the exec team always open with the headline number. ``` The agent posts a draft card showing exactly what it will save. Edit the wording if you like, then press **Save**. From now on, every thread with this agent starts knowing it. ## Or let the agent do the noticing [#or-let-the-agent-do-the-noticing] Work naturally and the agent notices lessons on its own: corrections you made, preferences you stated, methods that worked. Its proposals appear as **Suggested learnings** under its replies, and nothing saves until you accept. Methods can be saved too: a repeatable procedure becomes a **skill** any of your agents can follow. When the agent proposes one, accepting it builds the skill for you. [Skills →](https://www.hyperagent.com/docs/concepts/skills) ## Where this goes [#where-this-goes] This loop, correct → save → never repeat, is the whole learning system in miniature. When you're ready to tune how much the agent learns on its own, or to review a queue of its proposals, the [Learning docs](https://www.hyperagent.com/docs/learning) cover it. ## FAQs [#faqs] A memory preserves a fact, preference, decision, or piece of context: the client's spelling, the Thursday deadline, the way leadership wants risk framed. A skill preserves a method: the steps, format, decision rules, or script behind work the agent should perform the same way again. No. A suggested learning is a draft until you accept it. If you later allow a trusted agent to save a learning type automatically, proposals of that type can become knowledge without review. See [Manage learning behavior](https://www.hyperagent.com/docs/learning/manage-learning-behavior) for those controls. Its save destination decides. A shared memory can be available to your other agents; an agent-private memory stays with that agent. The agent's knowledge profile controls what it can read and where new memories land. See [Knowledge access](https://www.hyperagent.com/docs/concepts/agents/knowledge-access). **Next:** the agent knows the job. Put it where the work happens. [Put it where you work →](https://www.hyperagent.com/docs/get-started/put-it-where-you-work) --- # Your first agent Source: https://www.hyperagent.com/docs/get-started/your-first-agent > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Turn a job worth repeating into a teammate. You just ran a job in a thread and steered it right. An **agent** makes that the starting point instead of something you rebuild: a named teammate carrying the instructions, tools, and knowledge the job needs, into every future run. The best first agent already exists: it's the thread where you just corrected the work into shape. Hyperagent reads that conversation and drafts the agent from it, so the briefing you refined becomes the agent's standing instructions. ## Promote the thread [#promote-the-thread] ### Save the thread as an agent [#save-the-thread-as-an-agent] In the thread where the work went well, open the **…** menu in the header and choose **Save as agent**. Hyperagent reads the conversation, analyzes the patterns, and generates a draft: name, description, and instructions, all taken from how the work actually went. ### Review what it wrote [#review-what-it-wrote] The draft opens in the agent editor with everything pre-filled and everything editable. Read the instructions like a job description: is this what you'd tell a new hire doing this job? ### Create it, then run it once [#create-it-then-run-it-once] Click **Create Agent**, then start a new thread with the agent and give it the same kind of job. It should land close to where your corrected thread ended up, without the corrections. Starting from scratch works too: **New agent** from the Agents list gives you the same editor, blank. Reach for it when the job exists only in your head, not in a thread yet. ## What makes a good first agent [#what-makes-a-good-first-agent] * **A job you did this week and will do again.** A weekly summary, a report format, a research routine. Recurrence is what pays for the setup. * **One job, not a department.** "Writes renewal briefs" beats "handles customer stuff." You can always make a second agent. * **Instructions that would brief a person.** The draft gives you a start; sharpen it with the two or three rules you found yourself repeating in the thread. ## What the agent carries, and what it doesn't [#what-the-agent-carries-and-what-it-doesnt] The agent brings its identity, instructions, tools, and knowledge into every new thread. It doesn't bring the old thread's conversation: each run starts clean, which is what keeps run fifty as sharp as run one. What should persist between runs becomes a memory or a skill, and that's the [next lesson](https://www.hyperagent.com/docs/get-started/teach-it-something). ## FAQs [#faqs] No. **Save as agent** is the strongest starting point when you've already shaped a real piece of work, because the draft comes from decisions you actually made. If the role only exists in your head, choose **New agent** from the Agents list and write the brief directly. Check that it owns one clear responsibility, knows what a good result looks like, and has the judgment rules you found yourself repeating in the thread. Keep durable facts in memories and repeatable methods in skills rather than packing everything into the instructions. See [Agent configuration](https://www.hyperagent.com/docs/concepts/agents/configuration). It uses the thread to draft its configuration, but it doesn't carry the conversation into future runs. Each new thread starts clean with the agent's instructions, tools, and knowledge. Save facts or preferences as memories and methods as skills when they should persist. **Next:** teach it something it'll never forget. [Teach it something →](https://www.hyperagent.com/docs/get-started/teach-it-something) --- # Your first thread Source: https://www.hyperagent.com/docs/get-started/your-first-thread > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Do real work in five minutes with nothing configured. Describe what you need the way you'd brief a capable new teammate, and the agent researches, builds, and delivers. The specificity of what goes in sets the quality of what comes out. ## Do the work [#do-the-work] ### Describe the job [#describe-the-job] On the home page, type what you need into the composer. Bring a real task, and give it what a teammate would need: the goal, the audience, and any files, attached with **+**. ### Watch it work, or don't [#watch-it-work-or-dont] Send it, and the agent gets to work: researching, browsing, running code, writing. The transcript shows every step as it happens, and the **Live** pill in the header means it's still going. The thread runs on the server, so closing your laptop changes nothing. ### Steer with specifics [#steer-with-specifics] When the draft lands, correct it like you would a person: "shorter, lead with the number, drop the third section." Point at what's wrong and say what right looks like. Each correction sharpens everything after it. ### Open the finished work [#open-the-finished-work] Outputs arrive as cards in the conversation. Click one and it fills the canvas beside the chat, ready to read, edit, or share. Everything also lands in your [Library](https://www.hyperagent.com/docs/concepts/library), findable long after you've forgotten which thread made it. ## Why threads work this way [#why-threads-work-this-way] * **Each thread starts fresh.** No stale context from last week steering this week's work. What the agent should carry forward is explicit: memories, skills, and files you attach. [Threads →](https://www.hyperagent.com/docs/concepts/threads) * **Everything in the thread stays available.** Every message, file, and result builds on the last, so a thread gets smarter about its own job as it goes. * **When the work changes, start a new thread.** It costs nothing, because the finished work lives in your Library and the knowledge lives with the agent. ## FAQs [#faqs] Something you actually need this week, with a real artifact at the end: a brief from your notes, a comparison table of vendors, a summary of a long document. Real stakes teach you the product faster than a toy prompt. By design: each thread starts clean so nothing stale leaks in. When something should carry forward, save it as a memory, and it will be there in every thread. That's [lesson three](https://www.hyperagent.com/docs/get-started/teach-it-something). Yes. The thread runs on the server, not in your browser tab. Come back on any device; it pauses only when it needs your input. **Next:** the job was worth doing once, so make it repeatable. [Your first agent →](https://www.hyperagent.com/docs/get-started/your-first-agent) --- # Integrations Source: https://www.hyperagent.com/docs/integrations > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. The apps and services Hyperagent agents can connect to, and how to connect them. Your agents can read and act in the tools your team already runs on. Connect an app once, and it is available wherever that agent runs: in a thread, on a schedule, in Slack, or over email. This page is the full catalog. Search it, group it, and open the one you want. ## How integrations work [#how-integrations-work] Most integrations are one click. Find the card on **Settings → Integrations**, click **Connect**, approve access, and it is ready. The vendor confirms you meant to connect it, and Hyperagent holds the access so your agents can use it wherever they run. There are three ways to get an agent working with an app: The integrations in the catalog below are ready to connect. Find the card, click **Connect**, approve access, and enable it on your agent. [Browse the catalog](#the-catalog). Point Hyperagent at a remote MCP server your company or a vendor runs, and your agents get its tools the same way. [Set up a custom server](https://www.hyperagent.com/docs/integrations/custom-mcp). Teach the agent a repeatable method for a tool, including how to call its API with the right credentials. [Learn about skills](https://www.hyperagent.com/docs/concepts/skills) and [work with APIs and credentials](https://www.hyperagent.com/docs/concepts/skills/apis-and-credentials). Whichever you reach for, getting it working takes two steps: ### Connect the account [#connect-the-account] Open **Settings → Integrations**, find the card, and click **Connect**. Approve access with the vendor. This links the account to Hyperagent. No agent can use it yet. ### Attach it to an agent [#attach-it-to-an-agent] Enable the connected app on the thread or named agent that should use it. Open the agent's settings and add the integration, or enable it in the thread. Only then can the agent act with it. ## What a connection puts in a run [#what-a-connection-puts-in-a-run] Enabling an integration gives the agent authorized actions, not a copy of your account. The run receives descriptions of the actions it may call; your data stays in the service until the agent calls one. Each call is checked against the integration, its resource scope, and the run's permissions before the request goes out, and only the requested result comes back: a small result lands directly in the thread, while a large one can be saved as a file in the workspace and read selectively. The stored connection itself, the OAuth token or credential Hyperagent holds, never enters the agent's working environment. Scripts and processes in the run can't read, copy, or forward it; Hyperagent attaches it to the outbound request on the agent's behalf. A [custom MCP server](https://www.hyperagent.com/docs/integrations/custom-mcp) follows the same pattern: the agent gets tool definitions, Hyperagent sends authorized calls to the remote server, and the response returns to the run. ## Integrations [#integrations] Currently supported integrations are listed below. If you don't see a tool you need, you can connect a custom MCP server, create an API Skill, or request the integration. ## Setup guides [#setup-guides] Most integrations work out of the box. The ones below ask for a little more: a vendor-side setting to flip, credentials to gather, or an access level to choose. These guides walk through them. Add a secure remote MCP endpoint, configure its authentication, and attach it to an agent. [Open the Custom MCP guide](https://www.hyperagent.com/docs/integrations/custom-mcp). Set up bot identity, channel scope, and how agents respond in Slack. [Open the Slack guide](https://www.hyperagent.com/docs/integrations/slack). Connect a HubSpot account, approve its permissions, and test it with live CRM data. [Open the HubSpot guide](https://www.hyperagent.com/docs/integrations/hubspot). Find the workspace host, SQL warehouse ID, and credentials for the connection form. [Open the Databricks guide](https://www.hyperagent.com/docs/integrations/databricks). ## Manage connections [#manage-connections] Once an app is connected and attached, you manage the connection from **Settings → Integrations** and the agent's settings. Connect the app again to add another account, or reconnect one whose access lapsed. Agents keep the accounts separate. Use the controls the integration provides to limit the channels, resources, or accounts an agent can reach, and review what it called in the run's tool trail. For agents on a schedule or in Live Mode, decide whether an unattended run may write to the app or only read. Set this on the invocation. [Tools and integrations](https://www.hyperagent.com/docs/concepts/tools-and-integrations) covers how connections differ from built-in tools and how access flows from your account to an agent. [Invocations](https://www.hyperagent.com/docs/concepts/agents/invocations) covers how unattended runs gate external writes. ## Request an integration [#request-an-integration] The integration catalog grows with what teams ask for, so if the tool you need is not here, ask for it right from the integrations page. Open **Settings → Integrations** and click **Request an integration**. If you searched the catalog and found nothing, the same card appears as **Request "your search"** so you can request it in one tap. When you submit, the request goes to the team. If the tool you're looking for isn't listed, you can connect the tool yourself with a [custom MCP server](https://www.hyperagent.com/docs/integrations/custom-mcp), or create a skill that works with it. ## FAQs [#faqs] Connecting and enabling are separate steps. Connecting links your account under Settings → Integrations; enabling is what lets a specific thread or named agent use it. Open the agent's settings and add the integration, or enable it in the thread, and try again. With Hyperagent, never in the agent's working environment. The run gets action descriptions and results; when the agent calls an action, Hyperagent checks the scope and attaches the stored credential to the outbound request itself. Nothing running in the thread can read or forward the token. Yes. Connect the app again for each account. Agents keep the accounts separate, and you choose which account backs each agent when you enable the integration on it. Only if you allow it. Unattended runs in Live Mode and on schedules can block external writes until you enable them in the invocation's settings, so a scheduled agent reads and reports without changing anything unless you say otherwise. Connecting gives the agent access to the app. A [skill](https://www.hyperagent.com/docs/concepts/skills) teaches the agent a repeatable method to follow with that access. Connect for access; add a skill when you want the same job done the same way every time. Two paths: [connect a custom MCP server](https://www.hyperagent.com/docs/integrations/custom-mcp) if the vendor or your team runs one, or [request the integration](#request-an-integration) and we will tell you whether it is on the roadmap. --- # Custom MCP Source: https://www.hyperagent.com/docs/integrations/custom-mcp > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Connect an internal or vendor MCP server so an agent can use its tools. Custom MCP's allow you extend Hyperagent's integration capabilities. Any tool or service that offers a remote MCP server can be connected to Hyperagent. Once connected, any agent you attach to the server can call its tools as the work develops. The server stays responsible for its tools and authentication. Hyperagent connects to its endpoint, reads the available tool definitions, and lets an attached agent call them as the work develops. ## Before you start [#before-you-start] Have two things ready from the server's operator or vendor: * The server's **remote HTTPS URL** (for example `https://mcp.typeui.sh/mcp`). * How the server handles OAuth. Most servers can create the OAuth connection for Hyperagent automatically. Vendors call this **Dynamic Client Registration (DCR)**. If the server does not support it, check whether the service lets you create an OAuth app. You will need its **Client ID** and, for a confidential app, its **Client Secret**. If you cannot create an app yourself, ask the vendor or your workspace administrator for one. ## Connect a server [#connect-a-server] ### Open the Add MCP server dialog [#open-the-add-mcp-server-dialog] Go to **Settings > Integrations**. Under the add-integration menu, choose **Add custom MCP server**. ### Name the server and enter its URL [#name-the-server-and-enter-its-url] Enter a display **Name** and the server's **URL**. The connection uses streamable HTTP transport with OAuth authentication. ### Connect with OAuth [#connect-with-oauth] Start with the standard connection. If the server supports Dynamic Client Registration, it creates the OAuth connection for Hyperagent during setup. You do not need to create an OAuth app or enter a Client ID. Use this path only when the service does not support automatic OAuth registration. ### Create or request an OAuth app [#create-or-request-an-oauth-app] Open the service's developer, integration, or app settings and look for an option to create an OAuth app. If the service does not let you create one, ask the vendor or your workspace administrator for a pre-registered app. ### Add Hyperagent's redirect URI [#add-hyperagents-redirect-uri] In Hyperagent, check **Bring my own OAuth app** and copy the **Redirect URI** shown in the form. Add it to the OAuth app's allowed redirect URLs in the service. ### Enter the app credentials [#enter-the-app-credentials] Copy the OAuth app's **Client ID** into Hyperagent. Add the **Client Secret** if the service created a confidential app. Leave it blank for a public client that uses PKCE. ### Add OAuth endpoints only when needed [#add-oauth-endpoints-only-when-needed] If the server does not publish OAuth discovery metadata, open **Advanced** and enter its **Authorization endpoint**, **Token endpoint**, and any **Scopes**. Scopes should be separated by spaces. Provide both endpoints or neither. ### Confirm you trust the server [#confirm-you-trust-the-server] Check **I trust this server**. Custom MCP servers are not verified by Hyperagent, and an attached server receives the tool calls and inputs the agent sends it. Only connect servers you trust, then select **Connect**. ### Authorize in the server's OAuth flow [#authorize-in-the-servers-oauth-flow] You're redirected to the server to authorize access, then returned to Hyperagent. Once it completes, the server shows as connected under **Settings > Integrations**. ### Attach the server to an agent [#attach-the-server-to-an-agent] Connecting adds the server to your account; it doesn't make it available to any agent by itself. Open the agent's **Integrations** settings (the agent's page, `#tools`) and enable the server so that agent can call its tools. A connected server that isn't attached to the agent won't be available during that agent's runs. ### Test one tool in a thread [#test-one-tool-in-a-thread] Start with an interactive request that clearly calls for one of the server's tools. Confirm the agent can find the tool, authenticate, and return the expected result before you rely on it in a schedule or Live Mode run. ## What's supported [#whats-supported] * **Remote servers over streamable HTTP transport.** Hyperagent connects to the server's HTTPS endpoint and reads its tool definitions. * **OAuth authentication.** Authorization happens in the server's own OAuth flow. * **Three OAuth setup paths**, chosen automatically or by you: * **Automatic registration (Dynamic Client Registration).** The MCP server creates an OAuth connection for Hyperagent during setup. You do not need a Client ID or Client Secret. * **Automatic setup from published details (Client ID Metadata Document).** Hyperagent uses the OAuth details published by the server. No setup is required from you. * **Bring your own OAuth app.** For vendors that don't support either of the above, supply a pre-registered Client ID and optional Client Secret, plus manual endpoints when the server publishes no discovery metadata. * **Per-agent access.** Connect once at the account level, then attach the server to each agent that should have its tools. * **Public clients (PKCE-only).** Leave Client Secret blank when you bring your own public app. ## What an agent receives [#what-an-agent-receives] Attaching a server expands the tools the agent can call. It doesn't replace the agent's instructions, skills, knowledge access, or other integration settings. The agent can inspect the server's tool names, descriptions, and input schemas as the request calls for them. Hyperagent sends tool calls to the configured remote endpoint and returns the server's response to the run. Calls use the authentication configured for that connection. The server still decides what those credentials may read or change. ## Tool discovery and context [#tool-discovery-and-context] MCP servers can expose many tools, and their schemas can be large. The agent discovers relevant tools as needed instead of carrying every tool definition in the opening context. After a long run is compacted, the agent may need to inspect the server's tools again. If it loses the exact input shape, ask it to rediscover the tool before assuming the connection has failed. Clear tool names, descriptions, and schemas make the server easier for an agent to use correctly. Treat those definitions as part of the interface, not only implementation detail. ## What's not supported [#whats-not-supported] * **Local and stdio servers.** Servers that run as a command on your machine aren't reachable from Hyperagent. Only remote HTTPS endpoints work. * **Non-OAuth authentication.** There's no field for a static bearer token or custom request headers. The server must authenticate with OAuth. * **Private, loopback, or IP-literal hosts.** The URL must be a public, DNS-resolvable hostname over `https://`. URLs with embedded usernames or passwords are rejected. * **Unverified servers.** Custom MCP servers aren't reviewed by Hyperagent. Connecting one is a trust decision, and the server's credentials still govern what its tools may read or change. ## FAQs [#faqs] Confirm the server is attached to this agent and currently reachable. Then ask the agent to inspect or rediscover the server's available tools. Reconnect or refresh its credentials, then confirm the configured authentication fields still match what the server expects. Check for expired credentials, server rate limits, or a long-run context compaction. If the connection is healthy, ask the agent to rediscover the tool schema before retrying. Review unattended-write restrictions and the remote server's IP, network, or allow-list requirements. A scheduled run may have less permission to change an external system. Teammates may cause a shared agent to call the server according to the agent's sharing model and the server credentials in use. Review both layers before sharing the agent. Prefer the pre-configured integration unless the Custom MCP server exposes tools or controls it doesn't provide. Pre-configured integrations have the most direct connection and configuration experience. --- # Databricks Source: https://www.hyperagent.com/docs/integrations/databricks > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Find the credentials you need to connect your Databricks workspace. Connecting Databricks takes four pieces of information from your workspace: the host, a SQL warehouse ID, credentials, and (optionally) a default catalog and schema. Here's where to find each one. ### Find your workspace host URL [#find-your-workspace-host-url] Log in to your Databricks workspace and look at the URL in your browser's address bar. It will look like: ``` https://dbc-abc123-def4.cloud.databricks.com ``` Copy the host portion **without** `https://` — for example `dbc-abc123-def4.cloud.databricks.com`. If your workspace uses Azure Databricks, the host will look like `adb-1234567890123456.7.azuredatabricks.net`. ### Find your SQL warehouse ID [#find-your-sql-warehouse-id] 1. In the Databricks sidebar, click **SQL Warehouses** (under the "SQL" section). 2. Click the warehouse you want to use. If you don't have one, create a new SQL warehouse first. 3. Go to the **Connection details** tab and find the **HTTP Path** field. It will look like: ``` /sql/1.0/warehouses/a1b2c3d4e5f67890 ``` The warehouse ID is the last segment after `/warehouses/` — here, `a1b2c3d4e5f67890`. ### Set up authentication [#set-up-authentication] Choose one of the two methods: 1. Click your **profile icon** (top-right corner) and select **Settings**. 2. In the left sidebar, go to **Developer → Access tokens**. 3. Click **Generate new token**. 4. Give it a descriptive name (e.g., "Hyperagent"), set an expiration, and click **Generate**. 5. **Copy the token immediately** — it will only be shown once. The token starts with `dapi`. 1. In your Databricks **Account Console**, go to **Settings → App connections**. 2. Click **Add service principal** or use an existing one. 3. Under the service principal, go to **Secrets** and click **Generate secret**. 4. Copy the **Client ID** (UUID format) and the **Client Secret** (starts with `dose`). 5. Make sure the service principal has access to the SQL warehouse you want to use. ### Optional: catalog and schema [#optional-catalog-and-schema] If you use **Unity Catalog**, you can specify a default catalog and schema to scope queries. To find your catalogs, go to **Data** in the Databricks sidebar and browse the catalog tree. These fields are optional — if left blank, queries use the warehouse's default catalog and schema. Once you have your credentials, return to the Databricks settings page in Hyperagent and enter them in the connection form. --- # HubSpot Source: https://www.hyperagent.com/docs/integrations/hubspot > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Connect HubSpot so your agents can read and update contacts, companies, deals, and tickets. With HubSpot connected, your agents can read and update your contacts, companies, deals, and tickets: * **Keep your pipeline clean** — update deal stages, log notes, and fix stale records by asking, not clicking. * **Get answers instead of building reports** — ask questions about your pipeline and get live answers from your CRM data. * **Turn scattered context into records** — paste meeting notes or emails and have the agent create the contacts and deals. * **Triage support tickets** — summarize open tickets and create follow-up tasks. **You'll need:** a Hyperagent account and a HubSpot user with permission to connect apps to your HubSpot account. ## Connect HubSpot [#connect-hubspot] The connection starts from Hyperagent — if you found us in the HubSpot App Marketplace, sign in to Hyperagent first and follow the steps below. ### Open Settings → Integrations [#open-settings--integrations] Sign in at [hyperagent.com](https://hyperagent.com), then open **Settings → Integrations**. ### Connect the HubSpot card [#connect-the-hubspot-card] Find the **HubSpot** card and click **Connect**. ### Choose your HubSpot account [#choose-your-hubspot-account] A HubSpot window opens. Sign in to HubSpot if you aren't already, and choose the account you want to connect if you belong to more than one. ### Approve access [#approve-access] Review what Hyperagent can access. Keeping the defaults is recommended — deselecting optional permissions limits what your agents can do. Tick the confirmation checkbox at the bottom and click **Connect app**. ### Done [#done] The window closes and the HubSpot card shows as **connected**. That's it — there's no further configuration. **More than one HubSpot account?** Repeat these steps to connect additional accounts. Agents keep the accounts separate. ## Confirm it works [#confirm-it-works] Start a new thread and ask something only your live CRM can answer, like `List my open deals in HubSpot`. The agent should reply with real records from your account. If it asks you to connect HubSpot instead, head back to **Settings → Integrations** and retry the connection. ## Put it to work [#put-it-to-work] Any agent you use can work with HubSpot once it's connected — just describe the task. Some things to try: * `Move the Acme Corp deal to Contract Sent and add a note about today's call` * `Which deals in my pipeline haven't been touched in two weeks?` * `Turn these meeting notes into a new contact and deal` * `Summarize my open support tickets and draft follow-ups for the urgent ones` This also works everywhere your agents run — scheduled tasks, Slack, and email — not just in the Hyperagent app. ## Disconnect [#disconnect] You can disconnect from either side: * **From Hyperagent:** go to **Settings → Integrations**, find the HubSpot card, and disconnect. Hyperagent revokes its access tokens with HubSpot immediately. * **From HubSpot:** click the **settings icon** in HubSpot, then **Integrations → Connected Apps**, find Hyperagent, and choose **Actions → Uninstall**. **What happens to your data:** disconnecting stops all agent access to your CRM immediately. Nothing is deleted from HubSpot. Your past threads in Hyperagent are kept. Disconnecting from Hyperagent alone leaves the app listed on your HubSpot account — to remove it entirely, also uninstall it from HubSpot's Connected Apps page. ## Uninstall from HubSpot [#uninstall-from-hubspot] To fully remove Hyperagent from your HubSpot account, uninstall it from **Settings → Integrations → Connected Apps**. HubSpot's [How to uninstall an app](https://knowledge.hubspot.com/marketplace/install-apps-in-the-hubspot-marketplace#how-to-uninstall-an-app) guide walks through the steps. --- # Slack Source: https://www.hyperagent.com/docs/integrations/slack > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Connect Slack, deploy an agent to your workspace, and work with it in channels and DMs. Slack is the deepest integration in Hyperagent, because it isn't only a connection. It's also a way to invoke agents. When an agent is deployed to Slack, it can read and post in your workspace's channels, and your team can hand it work without leaving Slack. The AI assistant functionality in this integration requires a Slack workspace on a paid plan. It does not work in workspaces on Slack's free plan. ## Working with Slack in Hyperagent [#working-with-slack-in-hyperagent] In Hyperagent, Slack is a three-step process: connect your account, deploy an agent, and then use it day to day with your team right from slack. Link your Slack account to Hyperagent from Settings. This is the account connection. It doesn't put any agent in Slack yet. Give a specific agent its own bot identity, channel and DM access, and a way to respond. This is what makes the agent reachable in Slack. @mention the agent, follow up in threads, and schedule updates to land in a channel. This is the ongoing work. ## Connect Slack [#connect-slack] This links your account. It does not put any agent in Slack yet. ### Open Settings → Integrations [#open-settings--integrations] Sign in at [hyperagent.com](https://hyperagent.com), then open **Settings → Integrations**. ### Connect the Slack card [#connect-the-slack-card] Find the **Slack** card and click **Connect**. A Slack window opens. ### Authorize Hyperagent [#authorize-hyperagent] Choose your workspace, review the permissions, and click **Allow**. If your workspace requires admin approval for apps, the request goes to your Slack admin. ## Deploy an agent to Slack [#deploy-an-agent-to-slack] Once you've connected your Slack integration to your account, you can deploy an agent to Slack. When you deploy an agent, you give it a bot identity, set which channels it's allowed to read and write from, whether it should have DM access, and a way to respond. The following deployment configuration is what makes the agent reachable in Slack. Required. The agent's own name and avatar in your workspace, and what makes it reachable in Slack at all. Connect yourself so the agent can read and search Slack as you, only on runs you drive. Which channels the agent can read, and which it can post in, set separately. Separate read and write switches for direct messages, independent of the channel settings. Each one is a separate decision, set up in turn below. ### Set the bot identity [#set-the-bot-identity] The bot identity is the agent's face in Slack: its name and avatar, and what people @mention. An agent that should respond in Slack needs one. ### Open the agent's Invocation settings [#open-the-agents-invocation-settings] Open your agent's configuration, go to its invocation settings, and find the Slack section. ### Add the agent's bot with Add to Slack [#add-the-agents-bot-with-add-to-slack] The Bot identity step shows a dedicated bot for this agent, ready to install in your workspace. Click **Add to Slack**, then review the permissions in the Slack window that opens and click **Allow**. That's the whole setup: the agent gets its own bot, and teammates can @mention it by name in any channel it's been invited to. The bot takes its name and avatar from the agent itself. Changes to the agent's name, description, and logo carry over to Slack automatically, so there is nothing extra to configure in Slack. Some Slack workspaces need an admin to approve new apps first. If that's your workspace, clicking **Add to Slack** sends the request to your Slack admin. If the request is declined, see [Troubleshooting](#troubleshooting). Use your own Slack app when your workspace only allows apps you create and control yourself. Instead of the bot Hyperagent creates and manages for you, you create the Slack app with a configuration token, and you manage its name and icon in Slack rather than in Hyperagent. If you just want this agent in Slack, use **Add to Slack** above. It does the same thing in one click. ### Open the setup dialog [#open-the-setup-dialog] In the agent's Bot identity settings, expand **Alternative options** and select **Use your own Slack app**. This opens the **Set up your own Slack app** dialog, which walks you through creating a Slack app that you control. ### Open Slack App Management [#open-slack-app-management] In the setup dialog, click **Slack App Management**. Slack opens in a new tab, where you can create a configuration token for Hyperagent. ### Generate and copy an access token [#generate-and-copy-an-access-token] In Slack, scroll to **Your App Configuration Tokens** and click **Generate Token**. Find your workspace, then copy its **Access Token**. Do not copy the refresh token. The access token expires after 12 hours, so complete the remaining setup before it expires. ### Paste the token into Hyperagent [#paste-the-token-into-hyperagent] Return to the setup dialog, paste the access token into **Configuration token**, and click **Next**. Configuration tokens begin with `xoxe.xoxp-`. Treat the configuration token like a password. Paste it only into this Hyperagent setup field. ### Name the Slack app [#name-the-slack-app] The **Bot name** field is prefilled from the agent's name. Keep it, or enter the name teammates should see when they @mention the agent, then click **Create Slack app**. Choose a name that makes the agent's role clear in channels and threads. ### Install the app to your workspace [#install-the-app-to-your-workspace] After Hyperagent creates the app, click **Install to workspace**. This starts Slack's authorization flow for the workspace you choose. ### Review and allow access in Slack [#review-and-allow-access-in-slack] Confirm the correct workspace, review the permissions the app requests, and click **Allow**. Slack returns you to Hyperagent when authorization is complete. ### Set the bot's DM access [#set-the-bots-dm-access] Decide whether the agent should be able to open and send direct messages. If you leave this off, the agent can only read and post in channels. There are two options for DM access: * **Send direct messages**: The agent can open and send DMs to teammates. * **Respond when teammates DM this app**: The agent can respond when a teammate sends it a direct message. This requires the first option to be enabled. Additionally, this allows all teammates in Slack to DM the agent, not just yourself. Responding to direct messages requires a bot identity dedicated to this agent. If the agent responds as the shared @Hyperagent bot, give it its own bot with **Add to Slack** to enable DM replies. ### Set channels where your agent can read and post [#set-channels-where-your-agent-can-read-and-post] Once you add your bot to your slack workspace, you can choose the permissions for the channels it can read and post in. There are three options for default channel access: * **No permissions**: The agent cannot read or post in any channels that you do not give it specific permissions for. You can add **channel-specific overrides** to allow access to specific channels. * **Read only**: The agent can read messages in all public channels, but cannot post. * **Read and write**: The agent can read and post messages in all public channels. Agents cannot read private channels by default. If you want the agent to read a private channel, you must add it to that channel and give it the appropriate permissions using Channel Overrides. ### Set channels where your agent can be invoked [#set-channels-where-your-agent-can-be-invoked] To invoke your agent in a channel, you must specifically add it to that channel, and determine how it should respond in the Channel Overrides section. You can invoke your agent in three different ways: * **@mentions**: The agent will only respond when it is mentioned in a message. * **Thread replies**: The agent will respond when it is mentioned in a message, and it will also respond to messages in threads that it has already been mentioned in. * **All relevant messages in the channel**: The agent will respond to any message in the channel that it deems relevant. For this invocation, you can optionally provide a Filter Prompt to help the agent determine what is relevant to respond to. Use this option with care on busy channels. You can also set how the agent should respond, either streaming its work as it goes, posting only a final answer, or letting the agent decide whether to reply, react, or stay quiet. Lastly, you can choose whether your agent should respond to automated messages from other apps or agents in the channel. By default, the agent will not respond to automated messages. #### Setup Agent Invocation [#setup-agent-invocation] * Select the **Add channel** button to add a channel to the agent's list of connected channels. * Choose the channel you want to add from the channel picker. * Set the agent's permissions for that channel, then set its respond mode. ### Save your changes [#save-your-changes] Once you have set the bot identity, DM access, and channel access for your agent, make sure to save your changes. This will ensure that your agent is properly configured to work in Slack. ### Set a user identity Optional [#set-a-user-identity-optional] A user identity lets the agent read and search Slack with your access, including the channels you belong to and, optionally, your direct messages. It's owner-locked: the agent only acts as you when you're the one running it. For everyone else, the agent acts as its bot identity. The bot still does all the posting; it never posts as you. #### When does the agent act as you? [#when-does-the-agent-act-as-you] The agent uses your identity only when you're verifiably the one driving the run: * **Your own chats** in the Hyperagent app. * **Schedules you created** yourself. * **Slack messages you send** yourself, verified by your Slack workspace and user ID. Everything else falls back to the bot identity: runs started by teammates, and runs triggered by email, webhooks, tasks, or meetings. If a run driven by someone else needs an action that strictly requires your identity, that action fails with a clear error instead of using your access. Agents in a team workspace cannot have a user identity. Moving a personal agent into a team disconnects any user identity it had; the agent keeps working through its bot identity. ### Select a user identity when adding the agent to Slack [#select-a-user-identity-when-adding-the-agent-to-slack] When you add a bot identity, you can also choose to bind a user identity by selecting **User Identity**. ### Choose the workspace and person to bind [#choose-the-workspace-and-person-to-bind] Choose the workspace and connect yourself as the user identity. The bot identity still posts, but on runs you drive, the agent can read and search Slack as you. ### Set channel and DM access [#set-channel-and-dm-access] Choose whether the agent can read all channels available to you or only specific channels. Then decide whether it can read your direct messages. Leave DM access off unless the agent's work requires that context. These settings expand what the agent can read and search on runs you drive yourself. Posting still goes through the bot identity. ### Save your changes [#save-your-changes-1] Once you have set the user identity, channel access, and DM access for your agent, make sure to save your changes. This will ensure that your agent is properly configured to read and search Slack as you on the runs you drive. ## Interact with your agent in Slack [#interact-with-your-agent-in-slack] Once it's deployed, an agent can start work from an @mention, deliver a recurring report on a schedule, or monitor a job in Live Mode. Agent responses are AI-generated and may be inaccurate or incomplete. Review important output before you act on it. ### Invoke an agent with an @mention [#invoke-an-agent-with-an-mention] In a channel where the agent is deployed, @mention its bot identity and include the request in the same message. The mention starts a run with the message and the Slack context the agent is allowed to read. The agent does the work and posts its response from its bot identity. Follow-up messages stay together in the Slack thread, and the agent continues responding according to the channel's thread-response setting. Any artifacts the agent includes in its Slack response are published to public links. ### Deliver Scheduled and Live runs to Slack [#deliver-scheduled-and-live-runs-to-slack] Scheduled and [Live Mode](https://www.hyperagent.com/docs/concepts/agents/invocations/live-mode) runs use the same setup for cadence, threads, Slack delivery, replies, and unattended writes. The difference is what the agent does each time it runs: * **Scheduled** runs produce a recurring deliverable on a fixed cadence, such as a Monday pipeline report or daily support summary. * **Live** runs check a situation on a rolling interval and can stay quiet when nothing needs attention. ### Choose the run mode and cadence [#choose-the-run-mode-and-cadence] Select **Scheduled** for a recurring deliverable or **Live** for a rolling check. Set when it runs and provide the standing instructions. Live runs also let you choose a heartbeat model and leave the actions empty when the agent's defaults already describe what to monitor. ### Choose the thread and Slack destination [#choose-the-thread-and-slack-destination] Choose whether runs create a new thread or continue an existing one. Under **Deliver result to**, select the Slack DM or channel that should receive each successful result. A Slack delivery destination routes the report. It does not give the agent general Slack write access. ### Configure replies and notification behavior [#configure-replies-and-notification-behavior] Decide which replies in the Slack thread should invoke the agent, such as **@mentions only** or **All messages**. For a Live run, turn on **Only deliver when something needs attention** when routine checks should stay quiet. A scheduled result is delivered after every successful run. A Live check still runs on every interval when attention-only delivery is enabled, but Slack receives a result only when the agent finds something that requires attention. ### Set unattended write access [#set-unattended-write-access] Choose **Read-only** when the agent should monitor connected apps without changing them. Choose **Allow writes** only when the Live run should be able to send messages, edit files, or update records on its own. ### Review the estimate and enable [#review-the-estimate-and-enable] Review the estimated cost before enabling the run. Live heartbeat checks are billed even when everything is quiet. If a check finds work to do, the follow-up work on the agent's main model costs extra. ## Disconnect an agent from Slack [#disconnect-an-agent-from-slack] Remove Slack from an individual agent when it should no longer read, respond, or deliver results in your workspace. ### Open the agent's Integrations section [#open-the-agents-integrations-section] Open the agent's configuration, go to **Integrations**, and find its Slack card. ### Remove Slack from the agent [#remove-slack-from-the-agent] Click the three-dot menu on the Slack card and choose **Remove**. The agent loses its Slack access and stops responding there. Removing Slack from one agent does not disconnect your account-level Slack integration or remove Slack from your other agents. ## Troubleshooting [#troubleshooting] Adding the agent to a channel with `/invite`, or @mentioning it before setup is complete, only adds or addresses its Slack bot. It does not configure the channel permissions, response trigger, or reply behavior the agent should use. In Hyperagent, open the agent's **Invocations** settings and find Slack. Add the channel under **Channel Overrides**, choose what the agent can do there, set when and how it should respond, and save your changes. Then return to Slack and invoke the agent using the response trigger you selected. The most common cause is the deploy step, not the connection. Confirm the agent has a bot identity, that it's added to the channel, and that the channel is in its read or write scope. If it reads but never posts, check the channel's write access and the trigger mode. Your workspace requires admin approval for new Slack apps, and the admin declined the Add to Slack request. Ask them to approve the app in Slack's app management settings, then click **Add to Slack** again. If your workspace only allows apps that members create and control themselves, use your own Slack app instead: in the agent's Bot identity settings, expand **Alternative options** and select **Use your own Slack app**. Apps you create yourself may be allowed without this approval. Changing an agent's Slack identity disables its existing channel configurations. Re-enable them after the change. Treat identity changes as disruptive. Connect again and choose the other workspace in the account picker. Agents keep accounts separate, and you choose which account backs each agent when you add the integration to it. This appears when someone other than the identity owner triggers a run that needs the agent's user identity. User identities are owner-locked: the agent only reads Slack as the connected person when they are the one running it. To resolve it, have the identity owner run the agent themselves, or rely on the bot identity's own channel and DM permissions instead. Still stuck? See [Get support](#get-support). ## FAQs [#faqs] Yes, if you want people to invoke the agent from Slack. A bot identity is what makes the agent reachable. A user identity is optional and only widens what the agent can read on runs its owner drives; every other run uses the bot identity. The agent acts as its bot identity. It never reads or searches Slack as you on runs you aren't driving yourself. If the run needs something only your identity could do, that action fails with a clear error instead. The person who deployed the agent. Slack runs count against the deployer's usage no matter who triggers them. When the usage limit is reached, the agent says so in Slack and asks teammates to contact the agent's owner. No. The AI assistant functionality requires a workspace on a paid Slack plan. If your workspace is on the free plan, upgrade it in Slack before connecting. Yes. Connect Slack again and pick the other workspace. Agents keep the accounts separate. Yes, as long as each agent has its own bot identity. A single identity can only be linked to a channel once. Agents ignore their own messages and, by default, messages from other bots and agents, so they won't trigger each other unless you turn on responses to automated messages. No. The bot identity always posts. A bound user identity only lets the agent read and search as that person, never write as them. Yes. Ask it to update or delete one of its earlier replies and it will. It can only change messages it posted itself; messages from you, teammates, or other apps are off limits. Changing the identity disables its channel configurations. Re-enable the channels after the change. Yes. For a bot added through Add to Slack, name and avatar changes sync to Slack automatically within about a minute. If you use your own Slack app, manage its name and avatar in Slack's app settings instead; Hyperagent won't overwrite them. Only if you allow it. Unattended runs can block external writes until you enable them on the invocation, so a scheduled agent reads and reports without posting unless you say otherwise. Not by default. The agent reads channel messages as context for the task in front of it, but it doesn't save long-term memories from teammates' messages unless you enable that in the agent's settings. ## Get support [#get-support] If you hit something these docs don't cover, contact support from within Hyperagent: click your name in the sidebar and choose **Help → Support**. Including the thread link and a screenshot helps us resolve issues faster. If you can't access the product, email [support@hyperagent.com](mailto:support@hyperagent.com). --- # Knowledge Source: https://www.hyperagent.com/docs/knowledge > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. The facts, methods, and reference material agents can use across work, and the controls that decide where each belongs. A Customer Success agent preparing a renewal brief should not need the same setup every time. It can remember how leadership wants risk framed, follow the team's account-review method, and open the customer history and usage table when the work calls for them. **Knowledge** is the material that lets an agent begin from what your team has already established. Preserve the facts, methods, and reference material worth using again. The next thread can retrieve the right context without carrying every prior conversation with it. ## Three kinds of knowledge [#three-kinds-of-knowledge] Preferences, decisions, definitions, relationships, and other standing context the agent should be able to recall in future work. Repeatable ways of doing work: the checklist, format, decision rules, scripts, and when-to-use guidance behind a reliable result. Written material and structured records the agent reads, updates, and reuses across threads, such as a brand guide, research brief, account tracker, or dataset. ## Knowledge is what you give an agent to work from [#knowledge-is-what-you-give-an-agent-to-work-from] Knowledge is the material an agent begins from instead of rediscovering: a memory it recalls, a skill it follows, a document or table it reads. Some of it you lift out of real runs, a fact you corrected or a method that worked. Just as much of it you bring in from outside: upload a brand guide, write a memory by hand, attach a dataset the agent should treat as ground truth. Either way, giving an agent knowledge is deliberate. That is also the property that separates knowledge from a thread's own history. A [thread](https://www.hyperagent.com/docs/concepts/threads) keeps the conversation and tool results for one piece of work, and the next thread does not inherit them. Knowledge is what you deliberately keep or provide so the next run can use it, there for work that hasn't started yet. ## Work creates knowledge, and you decide what lasts [#work-creates-knowledge-and-you-decide-what-lasts] A run often reveals something worth keeping: a fact you corrected, a method that worked, reference material worth keeping current. The agent proposes a memory, skill, or prompt improvement, and nothing becomes standing knowledge until you accept it, unless you've allowed a trusted agent to save that kind on its own. Documents and tables the agent builds are editable outputs that live in the Library. See [Learning](https://www.hyperagent.com/docs/learning) for how proposals are raised and reviewed. ## The agent loads only what a run needs [#the-agent-loads-only-what-a-run-needs] Saved knowledge is not poured into every run. A small amount of pinned context arrives up front; the rest surfaces or is fetched when the conversation makes it relevant, so the [context window](https://www.hyperagent.com/docs/concepts/threads/index#when-the-work-changes-start-a-new-thread) stays free for the work itself. This is why what an agent *can* reach and what it *loads* on a given run are different things. See [How context gets into a thread](https://www.hyperagent.com/docs/concepts/threads/loading-context). ## Choose the right home [#choose-the-right-home] Match what you are preserving to the question it answers. This keeps one fact from becoming a document, one process from becoming a memory, and one run's temporary state from leaking into every future job. | You need to preserve | Put it here | Example | | --------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | | A standing fact, preference, correction, or relationship | A [memory](https://www.hyperagent.com/docs/concepts/memories) | “Renewal briefs should lead with risk and next action.” | | A repeatable process or quality standard | A [skill](https://www.hyperagent.com/docs/concepts/skills) | “How to prepare and review a renewal brief.” | | Written material the agent reads or maintains | A [document](https://www.hyperagent.com/docs/knowledge/documents-and-tables) | A living customer brief or brand guide. | | Structured records with reusable columns | A [table](https://www.hyperagent.com/docs/knowledge/documents-and-tables) | Account health, owners, renewal dates, and status. | | Facts, corrections, decisions, and plan details for this conversation | [Thread Context Document](https://www.hyperagent.com/docs/concepts/threads/thread-context) | “For this run, use the corrected renewal date of October 12.” | | Data that already belongs in another system | Keep it in the connected system | Current CRM fields, support tickets, or calendar events the agent can retrieve when needed. | ## Control who can use and change knowledge [#control-who-can-use-and-change-knowledge] [Knowledge and learning](https://www.hyperagent.com/docs/concepts/agents/knowledge-access) controls which memories the agent can read, whether it can discover skills, which context files travel with it, and where new learning is saved. [Learning](https://www.hyperagent.com/docs/learning) collects proposed memories, skills, prompt improvements, and configuration changes. Review the suggestion before it becomes lasting knowledge, or allow trusted personal agents to save selected types automatically. ## FAQs [#faqs] Use a memory for a fact or preference, a skill for a reusable method, and a document or table for material the agent should read or maintain. Leave temporary facts and the current plan in the Thread Context Document. If the information already has an authoritative home, such as a CRM or support system, keep it there and let the integration retrieve it. Each agent has its own knowledge boundary. The memory may belong to agent A, the skill may not be attached or discoverable to agent B, or the material may still live only in the original thread. Open agent B's [Knowledge and learning](https://www.hyperagent.com/docs/concepts/agents/knowledge-access) settings to check its access. No. Agents can propose memories, skills, and other improvements as they work, and trusted agents can auto-save selected learning types. Review remains important: keep stable, reusable context and dismiss chatter, temporary facts, and duplicates. See [Suggestions and auto-learning](https://www.hyperagent.com/docs/learning/manage-suggestions). --- # Documents and tables Source: https://www.hyperagent.com/docs/knowledge/documents-and-tables > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Reference material an agent reads and maintains: documents for writing that grows, tables for records with typed columns, shared across threads. Some knowledge is too alive to be a memory. The strategy doc that grows a section every week. The pipeline table that looks different every day. A memory is a settled fact; this material keeps moving, and it needs somewhere to live between runs. **Documents** and **tables** are that somewhere: the reference material an agent reads from, edits in place, and carries from one thread to the next. A memory is one fact the agent recalls. A document or table is a body of material the agent reads and keeps current: structured, versioned, and available across every thread that should see it. ## A document is named sections, edited one at a time [#a-document-is-named-sections-edited-one-at-a-time] A document is not one block of text. It is a set of named **sections**, each holding Markdown, and the agent works on them one at a time. That structure is what lets an agent update a document without rewriting it. When an agent maintains a document, it can: * **Append to a section**, adding this week's findings to the Research section without touching anything else. * **Replace a section**, swapping stale content for current content in place. * **Insert a new section** where the document has grown a new concern. Because each edit targets a section rather than the whole file, the surrounding sections stay exactly as they were, and every change is recorded. A document keeps **full version history**: each update is a snapshot you can read back or roll the document to, so a report an agent has maintained for months still carries the record of how it got here. ### Document scopes [#document-scopes] A document is visible to as much or as little as you decide. You choose that reach with its scope: The document belongs to the thread it was made in and travels no further. Use it for material that only this piece of work needs. Shared across all the threads in a project, so a brief written once is present wherever that project's work happens. Available to every thread, for material an agent should always be able to reach: a brand guide, operating principles, a customer brief. Documents you create this way live on the [Documents page](https://www.hyperagent.com/docs/concepts/library) and in the Library alongside everything else your agents produce, searchable across threads. Every thread quietly gets its own document, created automatically to hold that conversation's working state. It runs on the exact same sections-and-history machinery, but it is a working note for one thread, so it stays out of the Library rather than joining your reference material. See [Thread Context](https://www.hyperagent.com/docs/concepts/threads/thread-context). ## A table is typed columns and rows [#a-table-is-typed-columns-and-rows] A table is structured records: columns you define and rows the agent fills. Each column has a **type**, and the type is what keeps the data clean enough to reuse. | Column type | Holds | | ----------- | ------------------------------------------ | | **Text** | Names, labels, free notes | | **Number** | Counts, amounts, scores | | **Date** | A calendar date | | **URL** | A link to a source or record | | **Boolean** | A true or false state, such as done or not | A table is born in the thread where the agent first builds it. From there you decide how far it reaches: * **Promote it to an agent**, so that agent can reach the table in any of its threads. * **Make it global**, so it is available broadly, the way a pricing table or a shared lead list should be. Whether an agent can actually see global tables is governed by that agent's **global tables** setting, so global reach and the agent's permission to use it are two separate switches. To pull an existing table into a conversation, **@mention** it in the thread, the same way you would point a teammate at the right file. And when you need the data elsewhere, **export it as CSV or JSON**. This is the one place tables and documents diverge. A document records every version and can be rolled back; a table holds only its current state. Before a change you might want to undo, export the table to CSV or JSON so you keep a copy of where it stood. ## Bring existing material into a thread [#bring-existing-material-into-a-thread] A document or table does not fill the context window merely because the agent is allowed to reach it. The agent opens the material when the request calls for it, or you can point to it directly with an **@mention**. The resulting read or update appears in the thread's tool activity, so the source and change remain connected to the run. Scope and direct mention solve different problems. Scope makes the material eligible for a thread or agent to use; an @mention tells the agent that this specific request should use it now. See [How context gets into a thread](https://www.hyperagent.com/docs/concepts/threads/loading-context#fetched-when-the-work-calls-for-it) for how retrieved material enters the run. ## Documents hold writing, tables hold records [#documents-hold-writing-tables-hold-records] You don't have to decide between a document and a table; ask for what you need and the agent picks the shape the material wants. The distinction is worth knowing so you can read what it made, and steer it when you have a preference: A brief, a plan, a research write-up, a set of operating principles. Anything you'd read top to bottom, that gains sections as the work goes on. A lead list, an account tracker, a comparison, a dataset. Anything with rows the agent fills in, sorts, and queries. Ask for "a tracker of these accounts" and you'll get a table; ask for "a brief on this account" and you'll get a document. Name the shape yourself ("keep this as a table") when you want to override the call. The other two kinds of knowledge live elsewhere, and it is worth being clear about the line. A settled fact the agent should be able to recall in future work is a [memory](https://www.hyperagent.com/docs/concepts/memories), not a line in a document. A method the agent should follow every time is a [skill](https://www.hyperagent.com/docs/concepts/skills), not instructions buried in a document. Documents and tables are for the reference material in between: the things the agent reads, updates, and cites. If you find yourself pasting the same set of records into the conversation run after run, or the agent keeps rebuilding the same list from scratch, that list is asking to be a table. Save it once with typed columns and the agent reads it directly instead of reconstructing it every time. ## FAQs [#faqs] Yes. A table starts in one thread, but you can promote it to an agent so it reaches every thread that agent works in, or make it global so it is available broadly. To bring it into a specific conversation, @mention it in that thread. For a global table, remember the agent also needs its global tables setting on to see it. Yes. Documents keep full version history. Every update is a snapshot, so you can read an earlier version or restore the document to it. A report an agent has maintained for weeks carries its whole record of change. Tables do not keep version history, so there is no earlier version to restore. A table holds only its current state. If you are about to make a change you might want to reverse, export the table to CSV or JSON first so you keep a copy of where it stood. Two things gate it. A table is scoped to the thread it was made in until you promote it to an agent or make it global, so by default other threads cannot reach it. And even a global table is only visible to an agent whose global tables setting is on. If both are in place and the agent still doesn't see it, @mention the table in the thread to bring it in directly. In the Library, alongside everything else your agents produce, searchable across all your threads. The one exception is the Thread Context Document each thread creates for its own working state. That one is a working note for a single conversation, so it stays out of the Library. --- # Learning Source: https://www.hyperagent.com/docs/learning > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. How agents get better at your work: they propose what they picked up from a run, you accept or dismiss it, and what you keep becomes standing knowledge. An agent starts every run with what you gave it. **Learning** is how it gets better than that: it notices what a run teaches and offers to keep it, and you decide what sticks. Each lesson is minor on its own. A month of them is the difference between an assistant you brief every time and one that already knows the threshold, the format, and who owns the process. ## How a lesson becomes knowledge [#how-a-lesson-becomes-knowledge] The agent works, notices a correction you made or a method that worked, and files a proposal. Nothing changes what it knows until you accept it. Where a proposal waits depends on how it was raised: * **Background proposals** collect in the review queue, which you can reach from the thread's Learning panel, the Inbox, or the Learning page above. * **Draft cards in the chat** appear when you ask an agent to reflect on a conversation, so you can edit exactly what would be saved. * **Rubric proposals** go to the Rubrics page, kept separate because measuring quality is its own practice. Each kind of learning is set per agent to Off, Suggested, or Auto-saved. Suggested is the default, so a new agent always asks first. ## What an agent can learn [#what-an-agent-can-learn] Facts and preferences worth carrying forward: a threshold you set, how you like a report opened. Saved as [memories](https://www.hyperagent.com/docs/concepts/memories). A repeatable method, like pulling the weekly report from a connected app. Saved as a [skill](https://www.hyperagent.com/docs/concepts/skills). A refinement to the agent's instructions, added below what you wrote. A definition of what good output looks like, so quality can be measured rather than argued. An agent can also propose a change to its own configuration, which waits in the same queue. ## Go deeper [#go-deeper] --- # Give feedback to your agent Source: https://www.hyperagent.com/docs/learning/give-feedback > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Teach the agent on purpose instead of waiting for it to notice. During a thread, something fell short, or landed exactly right, and you want the agent to learn from it. You can respond directly, start a feedback interview, or ask the agent what from the conversation is worth keeping. Tell the agent what was off and it turns your answer into a memory, a method, or a standard it gets scored against. The next run starts from the corrected version. ## Four ways to teach your agent [#four-ways-to-teach-your-agent] Tell the agent what missed the mark and what to change. Use it for immediate, one-off direction while the work is in front of you. The agent interviews you about the output, then acts on your answer. Use it the moment something matters. The agent reflects on the conversation and proposes what to remember. Use it after a session that went well. A background pass reads the thread and files what it finds for you to review later. Use it when you'd rather skim a list than have a conversation. ## Give direct feedback in the thread [#give-direct-feedback-in-the-thread] When the fix is clear, say it directly in the conversation. Point to what missed the mark, say what should stay, and describe the revision you want. The agent applies that direction to the current thread without starting an interview. For example: ``` Keep the research, but rewrite the recommendation for the CFO. Lead with the cash impact, show the assumptions, and keep it to five bullets. ``` Use direct feedback for quick iteration and one-off direction. The correction stays in the thread's working context, but it doesn't automatically become standing knowledge. If the lesson should carry into future runs, choose **Give feedback**. If the conversation revealed several patterns worth keeping, choose **Suggest learnings**. ## Give feedback when the lesson should last [#give-feedback-when-the-lesson-should-last] Direct feedback fixes this output. The interview turns the same correction into something every future run inherits. ### Open the actions menu [#open-the-actions-menu] In the composer, where you type, click the **Execute** button to open the menu. Under **Actions**, choose **Give feedback**. ### Answer its questions [#answer-its-questions] The agent replies in the thread, opening broad and then probing whatever you raise. Expect it to ask: * What you expected, and how close it came * What specifically was missing * What the ideal version looks like * How much this dimension matters ### Confirm what it heard [#confirm-what-it-heard] When it has enough, the agent posts a summary: what worked, what needs improvement, and the key insight it took away. Read it and correct anything it misheard, in the thread, before it acts on any of it. ### Choose the outcome [#choose-the-outcome] In the same message, the agent offers four. Reply with the number you want, or several at once, like "1 and 3": * **Revise now** redoes the output with your corrections * **Learn from it** saves a memory or proposes a skill * **Create eval rubric** turns your standard into scoring criteria * **All of the above** runs them in order A thumbs up or thumbs down on any message opens the same interview, already pointed at that message. Use it when your reaction is about one reply rather than the whole run. ## Suggest learnings after a session that went well [#suggest-learnings-after-a-session-that-went-well] A run that goes right is worth keeping. Open the same **Execute** menu in the composer and choose **Suggest learnings**. The agent reads back over the conversation and posts what it should remember as draft cards in the chat, with its reasoning attached. Every card is yours to shape before it saves: * Rewrite the content in your own words * Change a memory's category or importance * Adjust when the agent should reach for it * Press **Save** to persist it immediately, or **Dismiss** to let it go ## Ask it to look for lessons on its own [#ask-it-to-look-for-lessons-on-its-own] Suggest learnings has the agent think out loud, in the thread, where you can push back on its reasoning. Sometimes you'd rather not have that conversation. You want the thread read, the lessons found, and a list you can work through later. Open the thread's side panel and select the **Learning** tab, then expand **Generation** and click **Generate Now**. A separate pass reads the conversation while you carry on. What it finds appears under **Insights** in the same panel, and in your [Learning queue](https://www.hyperagent.com/docs/learning/manage-suggestions), each proposal carrying Accept and Dismiss. ### Choosing a model [#choosing-a-model] **Model** in the same section decides which model reads the thread, and it applies to the pass you're about to run, nothing else. Pick a stronger one for a long or subtle conversation, a faster one when you just want the obvious lessons caught. The choice doesn't carry: the next thread starts at **Opus (Latest)** again, and the suggestions that appear automatically after a turn always use Opus regardless of what you pick here. This is the one path where the work happens away from you, so it suits a long thread you'd rather not reread, or any time clearing a queue later beats having the conversation now. ## What makes a reaction stick [#what-makes-a-reaction-stick] Whichever action you use, your feedback becomes one of the same kinds of knowledge everything else uses, so future runs find it: * A **correction of fact or preference** becomes a [memory](https://www.hyperagent.com/docs/concepts/memories), recalled whenever the topic comes back * A **better way of doing the job** becomes a [skill](https://www.hyperagent.com/docs/concepts/skills) any of your agents can follow * A **standing expectation** becomes a prompt refinement, appended below your instructions * A **quality bar** becomes a [rubric](https://www.hyperagent.com/docs/learning/rubrics-and-evaluations), so the standard is measured rather than argued ## FAQs [#faqs] Correct in chat when you want this output fixed. Use **Give feedback** when the lesson should apply to every run after this one: the interview pins down what you actually wanted and ends with a saved memory, skill, prompt refinement, or rubric. Have it reflect in the chat, with **Suggest learnings**, when you have an opinion: the agent reasons out loud and you can argue with it there. Send it off on its own, with **Generate Now**, when you want a long thread read without the discussion. Those proposals wait in the queue rather than the chat. It depends which action raised them. Cards from Give feedback and Suggest learnings appear in the chat and save directly when you press Save, because you're already reviewing them. The background pass files its proposals in the [Learning queue](https://www.hyperagent.com/docs/learning/manage-suggestions) instead, alongside everything else raised for you. Yes, and it's underrated. Run Suggest learnings after a session that went well and the agent writes down what made it work, so the win becomes the default. Yes. Each thread row there carries **Feedback**, **Suggest Learnings**, and **Generate Now**, so you can run any of them against a thread without opening it. Useful when you're working through several runs at once. No. It applies to that one pass. The next thread starts at **Opus (Latest)**, and suggestions raised automatically after a turn always use Opus whatever you chose. --- # Manage learning behavior Source: https://www.hyperagent.com/docs/learning/manage-learning-behavior > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Decide how much your agent can change on its own: propose and wait for you, save without asking, or nothing at all. Your agent picks things up as it works. You decide what happens next: it waits for your approval, saves on its own, or lets it go. Let an agent save small facts on its own while changes to its instructions still wait for you. Mixed setups are the normal ones, and no level moves unless you move it. ## Set how much it learns [#set-how-much-it-learns] Open your agent and go to its **Knowledge** tab. The **Self-learning** section holds one row per kind of change, and each row takes a level. * **Suggested** proposes and waits. New agents start here. * **Auto-saved** skips the approval step, so small, obvious lessons land on their own. * **Off** keeps that type out of the agent's hands. You can still ask for one directly. Raise a type to Auto-saved once the agent has proven itself there. Nothing changes the level but you. ### Which level to use [#which-level-to-use] * **An agent you use yourself, every day.** Memories on Auto-saved. It picks up your standing preferences as it works, and you keep reviewing the changes that reach further. * **An agent your team runs.** Leave everything at Suggested. Its lessons land in the team's knowledge, so one review keeps the shared brain clean for everyone. * **An agent in a channel you don't control.** Curated, the knowledge profile that turns learning off and narrows what it reads. Hyperagent applies it for you the first time an agent joins a Slack channel. ## What it can change [#what-it-can-change] A fact or preference worth keeping: a threshold you set, how you like a report opened. A method worth repeating. On a team agent, the skill belongs to the team, so this one always waits for you. An addition to the agent's instructions, appended below what you wrote. The agent editing its own setup: instructions, tools, skills, model, schedules. Agent configurations is the one row without a Suggested option. A configuration change happens while the agent works, so it arrives as a card in the conversation. Auto-saved tells it not to wait for your click. ## Let a Slack channel teach it [#let-a-slack-channel-teach-it] By default only you teach your agent. On the same **Knowledge** tab, just below **Thread search**, turn on **Learn from others in Slack** and the channel's members do too. Worth doing when you trust the room. Even then, nothing from a channel auto-saves, so no one's message becomes standing knowledge without your review. ## What never saves without you [#what-never-saves-without-you] Three things stay in your hands whatever the levels say: * **Anything the team shares.** A skill on a team agent, or a configuration change saved into a team's workspace. A shared skill's instructions, scripts, and credentials affect every member at once. * **Anything from outside.** Runs that arrive through Slack, email, or a webhook. * **Anything that widens the agent's reach.** Keeping a browser session signed in, or letting a schedule write to your connected apps. Everything held for review waits in one queue. See [Manage suggestions](https://www.hyperagent.com/docs/learning/manage-suggestions). ## Undo anything [#undo-anything] Open any memory or skill and **Version History** sits at the bottom of its detail page. Each entry says whether you or the agent made the change. Restoring is itself reversible: your current version is saved to the history first. Instructions are safer still, since the agent appends below what you wrote and never over it. ## FAQs [#faqs] Turn **Learns automatically** off on the agent's Knowledge tab, or pick the **Curated** knowledge profile, which also narrows what the agent reads. A prompt suggestion only adds to the instructions, and it comes after a conversation, from an analysis of how the work went. A configuration change happens during a run, when the agent is working on its own setup, and instructions are one of several things it can touch there. Yes. A thread's **Learning** popover narrows what that conversation may propose, and runs the analysis on demand instead of waiting. It changes that thread only. A conversation can also propose a **rubric**, which agent settings don't cover; see [Rubrics and evaluations](https://www.hyperagent.com/docs/learning/rubrics-and-evaluations). No. A memory can belong to one agent, but every skill belongs to a workspace, yours or a team's. That's why skill learning on a team agent is always a shared change. Less than it sounds. It applies only to the types you raise, wide changes wait for review anyway, and everything saved can be restored. The real risk is accumulation, so look over what the agent has kept now and then. --- # Manage Learnings Source: https://www.hyperagent.com/docs/learning/manage-suggestions > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Review and approve new learnings your agent proposes. Your agent files a proposal whenever it picks something up. Every one waits for you, and nothing changes what the agent knows until you accept it. Proposals collect out of the way until you have five minutes for them. Accept what's right, clear the rest in a couple of clicks, and the agent knows exactly what you approved. ## Where you'll see them [#where-youll-see-them] Proposals collect quietly rather than interrupting the work, which means you need to know where they went. They show up in three places, each suited to a different moment. ### Catch them alongside everything else waiting [#catch-them-alongside-everything-else-waiting] The Inbox is the single list of things that need you: approvals, failing schedules, and one row for pending learnings. It won't let you accept from there, deliberately, since a lesson deserves reading in context. Clicking through opens the Learning page. ### Review a lesson while the run is fresh [#review-a-lesson-while-the-run-is-fresh] The **Learning** tab in the thread's side panel carries a count of what this conversation proposed. This is the best place to judge a proposal, because the work that produced it is right there. Open **Insights** and act on each card in place. Memories offer Accept and Dismiss; skills offer **Quick** or **Interactive** instead of a plain Accept. ### Clear a backlog across every thread [#clear-a-backlog-across-every-thread] The Learning page gathers proposals from all your threads, grouped by the run that produced them. Filter by agent, or click a type to see every suggestion of that kind across threads at once, which is how near-duplicate ideas become obvious. Rubric proposals are the exception to all three. They wait on the [Rubrics surfaces](https://www.hyperagent.com/docs/learning/rubrics-and-evaluations) instead, because measuring quality is its own practice. ## Edit the card before you save it [#edit-the-card-before-you-save-it] A draft card is the record itself, not a summary of it. Every field is editable, so what saves is what you approved rather than what the agent guessed. ## What accepting does [#what-accepting-does] | Kind | What accepting it does | Where it lands | | ----------------------- | ---------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | **Memory** | Saves the memory, or refines the existing one it updates | Your memories, this agent's memories, or the team's shared memories, according to [Knowledge access](https://www.hyperagent.com/docs/concepts/agents/knowledge-access) | | **Skill** | **Quick** researches and builds the skill on its own; **Interactive** opens a guided skill-building conversation | Your [skills](https://www.hyperagent.com/docs/concepts/skills) library | | **Prompt** | Adds the refinement below your existing instructions | The agent's brief, or the thread's own instructions when no agent is attached | | **Agent configuration** | Applies the proposed change to the agent | The agent's configuration | A prompt suggestion can never erase what you wrote. It's appended below your instructions, and you see the full updated brief immediately. ## Clear a backlog quickly [#clear-a-backlog-quickly] Three controls clear proposals in bulk, so a busy week stays easy to work through: * On the Learning page, expand a thread and click **Select** above its suggestions to turn on checkboxes. Pick your rows, shift-click for a range, then **Dismiss**. * Filter to one agent and **Clear *N* suggestions** appears at the top of its panel, clearing everything pending for that agent across every thread. It asks first, and it leaves anything you already accepted alone. * Click a type badge to switch to the grouped view. Where the same idea arrived from several threads, that group carries **Dismiss All Variations**, which retires the whole cluster at once. ## Dismissing is final [#dismissing-is-final] A dismissed proposal won't come back, and that's what makes the queue safe to clear fast. Nothing you dismiss will nag you twice, so you can be decisive. If a dismissed idea turns out to be good, run **Suggest learnings** on a thread where it applies and the agent proposes it fresh. ## Manage what you've kept [#manage-what-youve-kept] Accepting is half the job. A tidy library keeps the agent sharp, because fewer and fresher memories mean the right one surfaces at the right moment. Three habits keep it that way. ### Archive rather than delete [#archive-rather-than-delete] Archiving takes something out of the agent's recall and keeps the record, so you can retire anything you're unsure about and get it back later. * Open the item's row menu, or its detail page, and choose **Archive**. Memories, skills, agents, rubrics, and threads all work this way * **Restore** returns an archived item to recall * On the Memories page, select several rows and use **Archive** in the bar that appears at the bottom * **Deleting** is the deliberate second step, available once something is archived You can also archive without leaving the conversation. When an agent saves a memory on its own, the chip it posts in the chat carries an archive button, so a lesson you disagree with can be retired the moment you read it. ### Merge duplicates so one fact has one home [#merge-duplicates-so-one-fact-has-one-home] * On the Memories page, select two or more rows and choose **Merge** from the bar at the bottom. You pick which memory survives and edit the combined content; the rest are archived * For a broader sweep, open the Memories page's header menu and choose **Dedupe memories**. It scans the library at a similarity threshold you set and walks you through each group * The agent guards this too, holding back an auto-save that looks close to something you already have and offering it as a card instead ### Keep a thinking-out-loud thread out of it [#keep-a-thinking-out-loud-thread-out-of-it] Some conversations are scratch space. Open the thread's menu, from the sidebar or the thread header, and choose **Exclude from knowledge**. The agent then won't search or read that thread from anywhere else. It's reversible, and it's offered on threads that aren't bound to an agent. ## FAQs [#faqs] No. It waits as a card in the thread and on the Learning page, and nothing becomes standing knowledge until you accept it. No, dismissal is final. If the idea was good, run Suggest learnings on a thread where it applies and the agent can propose it again. Before proposing anything, the agent reads your existing memories, skills, and pending proposals, then decides per candidate whether to create, refine, or skip. That's why a near-duplicate arrives as an update to an existing item rather than a second copy. Quick builds the skill on its own, researching the documentation for you. Use it for a straightforward service. Interactive opens a guided conversation in the thread so you shape the requirements. Use it when the skill needs your judgment. No. Archiving takes an item out of the agent's recall but keeps the record, and Restore undoes it. Deleting is permanent, and most types require archiving first so the destructive step is never the quick one. Proposals from threads with no agent attached. Accepting a prompt suggestion there updates that thread's own instructions, since there's no agent to carry it. To the Rubrics page and the thread's Rubrics tab. The Learning queue holds memories, skills, prompts, and configuration changes; see [Rubrics and evaluations](https://www.hyperagent.com/docs/learning/rubrics-and-evaluations). --- # Rubrics and evaluations Source: https://www.hyperagent.com/docs/learning/rubrics-and-evaluations > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Define what good looks like, score real work against it. In Hyperagent, a **rubric** writes your standards for good work down as criteria a model can score, so the next output gets a number instead of another conversation, and you can watch that number move. Write the standard down once, then score any output against it in a couple of clicks. Quality stops being something you re-argue each time and becomes a trend line you can point at. ## The judge that does the scoring [#the-judge-that-does-the-scoring] Nobody wants to grade their agent's work by hand every week, and the agent can't be trusted to grade itself. So a second model does it: the **judge**. The judge is handed two things and nothing else, the conversation and your rubric. It doesn't see the agent's reasoning about how it did, or its earlier scores, or which model produced the work. It reads the output the way a reviewer would and scores each criterion on its own. That separation is what makes the number worth having: * **It's consistent.** The same standard is applied the same way at 9am and at midnight, on run one and run fifty. * **It's independent.** An agent can't talk its way to a good score, because the thing scoring it never hears the argument. * **It explains itself.** Every criterion comes back with the reasoning behind its number, so you can tell whether you agree. You choose which model sits in that seat each time you run an evaluation. ## What's in a rubric [#whats-in-a-rubric] A rubric is a handful of **criteria**. Each is one thing you'd check if you were reviewing the work yourself, and carries a name, a **weight**, and a **scoring guide**. Good criteria are specific enough that two people would score the same output the same way. "Whether claims rest on primary sources" is checkable; "well researched" is not. Three to seven of them is the useful range, few enough that each weight means something. * **Weights say what matters most.** A research brief might put source quality above structure. They're relative, so you don't have to make them add up: anything that doesn't sum to one is normalized when you save. * **Scoring guides make the number repeatable.** "1 = no primary sources, 3 = mostly primary, 5 = primary throughout with dates" holds two runs to the same bar. Without a guide, the judge invents its own, and the score drifts. * **Write criteria you could defend to a colleague.** "Clear organization and logical flow" can be argued about honestly. "Good" cannot. ## How a rubric makes the agent better [#how-a-rubric-makes-the-agent-better] A score on its own changes nothing. The value is what a run of scores lets you see. * **One evaluation** tells you how this output did, criterion by criterion, with the judge's reasoning. * **A dozen evaluations** show which criterion is consistently weak, which is improving, and which one you keep disagreeing with. * **That pattern names the fix.** A criterion that scores low run after run points at a missing skill or a vague instruction. A criterion you keep overruling points at the rubric. From there the agent proposes the fix itself, as a skill, a memory, or a change to its instructions, and you accept or dismiss it like any other suggestion. The rubric is what turns "it feels off lately" into a specific thing to change. ## Write your first rubric [#write-your-first-rubric] There's no blank form to fill in. You open the evaluation dialog, ask for a new rubric, and the agent drafts the criteria with you. ### Open Run Evaluation [#open-run-evaluation] Open a thread with real work in it. Under the agent's response, click **Eval**. ### Choose "+ Create New Rubric..." [#choose--create-new-rubric] It's the first option in the **Evaluation Rubric** dropdown. Choosing it closes the dialog and starts rubric building in the conversation. ### Answer the agent's questions [#answer-the-agents-questions] It works through one criterion at a time: what to check, how much it matters against the others, and what a 1 and a 5 look like. Answer in your own words. It tells you how far along the draft is as you go. ### Save when it's ready [#save-when-its-ready] Once there's enough to score against, the agent checks the draft for gaps, then posts it as a card. Edit anything, then save. It lands in your rubric library ready to run. Three other ways in: * **From feedback on real output.** In the composer, open the **Execute** menu, choose **Give feedback**, and answer the interview. When it offers what to do with your answer, reply **3** for **Create eval rubric** and your complaints come back as criteria. * **From the thread's Rubrics tab.** With nothing pinned yet, it offers **Build rubric interactively**, which starts the same guided build. * **Wait for a proposal.** After substantial work the agent may draft one on its own, or suggest pinning one you already have. Those wait on the Rubrics page and in the thread's Rubrics tab. ## Score an output [#score-an-output] An **evaluation** applies a rubric to real work. The judge reads the whole conversation, not just the last message, so it can tell whether the output answered what was actually asked. Open the thread you want scored and click **Eval** in the actions beneath the agent's response. If the rubric is already pinned to the thread, its **Eval** button in the Rubrics side panel does the same thing. The mode decides what gets scored: * **Evaluate Existing Output** scores the response already in the thread. Nothing re-runs, so it's the fast one, and the right default. * **Replay & Evaluate** runs your prompt again in a hidden thread and scores that. Use it after changing the agent's setup, to see whether the change helped. **Judge Model** picks who does the scoring. **Opus 5** is the default and the one to keep when the answer matters; Sonnet and the Gemini Flash models are there when you're scoring in volume and want it cheaper. **Same as thread** uses whatever model ran the work. The choice applies to this run only. Every evaluation is a separate call that sees only the conversation and the rubric, never the agent's own reasoning about how it did. That's what keeps a score from being the agent grading itself. ## Read the result [#read-the-result] **Overall Score** is the weighted total. **Criteria Breakdown** is where the value is: each criterion shows its score out of five, its weight, and the judge's reasoning for the number it gave. A 78% made of one excellent criterion and one failing one is a different problem from a flat 78% across the board. **Judge Assessment** closes with the judge's read of the output as a whole. ### Tell it when a score is wrong [#tell-it-when-a-score-is-wrong] Each criterion carries a **Fair?** prompt with a thumbs up and thumbs down. Marking a score unfair asks you to pick a reason, and those answers are what later separate "the agent is weak here" from "this criterion is measuring the wrong thing." Rate the ones you disagree with as you go. A history of unrated scores can tell you a criterion is low, but not why. ## Turn scores into fixes [#turn-scores-into-fixes] One score is about one run. The point of collecting them is the pattern, which answers a question you can't answer from a single number: is the agent falling short, or is the ruler bent? Open the rubric from the Rubrics page and the whole picture is on one screen. **Suggest Improvements** reads the history, including which scores you marked unfair, and proposes something concrete. What it finds falls into a few shapes: You keep marking one criterion's scores unfair. It's measuring the wrong thing, and the fix is to edit the criterion or its scoring guide. A criterion scores low run after run and you agree the scores are fair. Now a new skill, a sharper memory, or a revised instruction is worth trying. Scores on a criterion are trending down. Recent changes to the agent are the first place to look. Each suggestion arrives as a card you accept or dismiss, the same way you handle everything else in [the Learning queue](https://www.hyperagent.com/docs/learning/manage-suggestions). **Calibrate before you chase a weakness.** A low score only means something once you trust the criterion, which is the whole reason the thumbs matter. Suggest Improvements needs three or four runs before patterns are worth reading; below that it works from the most recent evaluation alone. Two more ways to work the history: Opens a new thread with the per-criterion averages and your agreement rates already attached, and asks the agent to work out whether the gap is capability or calibration. Available once you have two runs. Opens a fresh thread with this rubric pinned and a starting prompt, so you can watch the criteria land on new work before trusting them. ## FAQs [#faqs] Three to seven. Fewer than three and the weights stop meaning anything; more than seven and each one carries so little weight that a real failure barely moves the total. Only one is enforced as a minimum, so restraint is yours to apply. No. They're relative, and anything that doesn't sum to one is normalized when the rubric saves. Set them by how much you care and let the math sort itself out. Mark the criterion with a thumbs down and pick a reason. If you keep disagreeing with the same criterion, the rubric is what needs changing, not the agent. Edit it, then score the output again with **Evaluate Existing Output** to see the corrected number. It doesn't have to be, and the default doesn't try to be: the judge only ever sees the conversation and the rubric, so it isn't grading its own reasoning either way. Choosing a different model buys you a second opinion rather than a fairer one. **Same as thread** is there when you want the comparison held completely steady. The run shows **Evaluation Failed** with the reason, and a **Retry** button beside it. Nothing partial is saved: a run either produces a full score or none at all. --- # Migrate from OpenClaw to Hyperagent Source: https://www.hyperagent.com/docs/migrate/openclaw > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Migrate your OpenClaw agent in minutes using the import wizard. The OpenClaw import wizard brings an agent you've already built in OpenClaw into Hyperagent, including its instructions, memories, scheduled tasks, tools, channels, and skills. Your first import is free. This guide explains what gets migrated, how the import wizard works, what needs to be reconnected, and what to expect if something doesn't translate cleanly. ## Quickstart [#quickstart] 1. In Hyperagent, go to **Settings → Import from OpenClaw** (or select **Import from OpenClaw** during onboarding). 2. Locate your OpenClaw workspace folder. In many installations, it's stored at `~/.openclaw/workspace`, though the exact location may vary. 3. You can bring the workspace into Hyperagent three ways: * the workspace folder, * a `.zip` or `.tar.gz` archive, or * the individual workspace files. 4. Review the import preview, choose what to bring over, connect any tools or channels you want to use, and select **Import Agent**. *** ## What the import wizard does [#what-the-import-wizard-does] What the import wizard does The import has four steps: 1. **Upload:** Drop your `~/.openclaw/workspace` folder or a zip of it. The wizard accepts the whole thing and uses what's relevant. 2. **Preview:** You see your workspace files mapped to where they live in Hyperagent, `SOUL.md` and `AGENTS.md` into your system prompt, `HEARTBEAT.md` into schedules, `MEMORY.md` into memories, and so on. You can rename the agent, edit its instructions, and select which tools to connect before anything is committed. 3. **Connect tools:** You choose which integrations to connect and in what order. The wizard shows each tool's status. Nothing runs until you reconnect. You'll also set up Live Mode here if you want your agent to run continuously. 4. **Done:** You land in the agent config to review schedules, confirm everything looks right, and choose when to open a thread. You can start the import from the onboarding card or from **Settings**. If you want the background on what lands where, skim [Skills](https://www.hyperagent.com/docs/concepts/skills), [Memories](https://www.hyperagent.com/docs/concepts/memories), and [Threads](https://www.hyperagent.com/docs/concepts/threads) while you work. *** ## Import your agent [#import-your-agent] ### Open the import wizard [#open-the-import-wizard] Select your profile icon in the lower-left corner, choose **Settings**, then open **Import from OpenClaw**. ### Export your OpenClaw workspace files [#export-your-openclaw-workspace-files] Collect the files OpenClaw needs. `AGENTS.md` is the only required file, but including the rest of your workspace helps Hyperagent import your instructions, memories, schedules, tools, and skills more accurately. If your workspace is in the common hidden folder, open it with the command for your operating system: ```bash open ~/.openclaw/workspace ``` ```powershell explorer "$env:USERPROFILE\.openclaw\workspace" ``` ```bash xdg-open ~/.openclaw/workspace ``` If your workspace lives somewhere else, use that real path instead. To create an archive manually, navigate to the workspace and package the files you want to import: ```bash cd /path/to/openclaw/workspace zip -r openclaw-export.zip AGENTS.md SOUL.md IDENTITY.md USER.md MEMORY.md HEARTBEAT.md TOOLS.md memory/ skills/ ``` ```powershell cd "$env:USERPROFILE\.openclaw\workspace" Compress-Archive -Path AGENTS.md,SOUL.md,IDENTITY.md,USER.md,MEMORY.md,HEARTBEAT.md,TOOLS.md,memory,skills -DestinationPath openclaw-export.zip ``` This creates `openclaw-export.zip` in the same folder. If you do not have daily logs or custom skills, omit `memory/` or `skills` from the command. Your workspace is processed in your browser, on your own computer. Only the agent content needed for the import is uploaded. Agent instructions, memories, schedules, skills, and the metadata needed to map tools and channels. Your OpenClaw database contents, session history, channel tokens, webhook URLs, scratch notes, logs, caches, and unrecognized files stay on your machine. To read scheduled tasks, the wizard may send database column names such as `prompt` to the server. It does not send the column contents. Drop in just your OpenClaw workspace, not your whole home folder. The wizard only uses recognized workspace files, so including virtual environments, Git repositories, caches, or other large folders only increases upload size and review time. Large uploads may exceed file count or size limits. ### Upload and preview [#upload-and-preview] Drop your folder, archive, or individual markdown files into the wizard. The wizard reads the upload locally, detects what is available, and builds a preview. If the upload contains more than one agent, you will pick one to import first. Drop in your workspace folder, archive, or files. Review the imported agent, memories, tools, and channels before you bring it home. OpenClaw-specific sections are removed during migration. Nothing is added to your account until you confirm. You can uncheck anything you do not want, edit the agent name and instructions, review memories one by one, and restore trimmed instruction text if needed. Preview is a curation step, not a blind copy. Hyperagent maps what it can, flags what needs your attention, and lets you decide what gets committed. ### Connect tools and channels [#connect-tools-and-channels] After you confirm the preview, Hyperagent invites you to connect any matched integrations. Nothing runs until you connect the tools you want to use. Telegram and Slack channels need to be reconnected. Email needs no setup because your agent gets its own email address automatically. Connect matched integrations now, or skip and finish setup later from settings. Reconnect channels so the imported agent stays reachable where it already worked. ### Meet your agent [#meet-your-agent] You land on the imported agent's page with a `Talk to {Your Agent's Name}` button. The first conversation introduces the agent in its imported voice, explains what it can now do, and suggests concrete first actions. The first import is free. Additional imports may use your normal account usage after the free allowance is used. ## What gets migrated [#what-gets-migrated] | OpenClaw File | Hyperagent Destination | Notes | | ------------- | ------------------------------------- | -------- | | `SOUL.md` | Agent system prompt (persona section) | Verbatim | | `IDENTITY.md` | Agent system prompt (operating rules) | Verbatim | | `AGENTS.md` | Merged into system prompt | Verbatim | In OpenClaw, these were separate files your agent read at the start of each session. In Hyperagent, they live in the Identity tab of your agent as a single editable system prompt. Same content, one place. The preview shows the actual text inline so you can verify your content before confirming, but this can always be adjusted later on. Anything that's OpenClaw-specific (references to HEARTBEAT.md, heartbeat syntax, OpenClaw tool names) is flagged for your review — you decide what to keep or update. | OpenClaw File | Hyperagent Destination | Notes | | ---------------------- | ---------------------- | ------------------------------------------------------------------------- | | `MEMORY.md` | Agent-scoped memories | Split into individual entries, de-duplicated | | `USER.md` | Agent-scoped memories | Same entry-merge logic | | `memory/YYYY-MM-DD.md` | Agent-scoped memories | AI distills durable takeaways; raw session logs aren't imported wholesale | In OpenClaw, memories were a flat file your agent re-read each session. In Hyperagent, memories are live and scored — on an importance scale of 1 to 5. Any memory with importance 4+ loads automatically in every conversation, lower-importance ones surface when relevant. Your agent will know more without being told more. The import is a curation moment, not just a file copy — which is better than a straight transfer, because OpenClaw memory accumulates cruft over time. Everything lands visible and editable, and your agent can never overwrite what it knows without your approval. In OpenClaw, `HEARTBEAT.md` was a checklist your agent read to know what to do and when. In Hyperagent, it can turn into two invocation types: schedules and Live Mode. * **Schedules** trigger on a fixed cadence to run a process. If the schedule is enabled, it always runs. * **Live Mode** checks whether anything needs to be done on an interval. If there is no work to act on, the agent stays quiet. Schedules run the selected process every time the cadence fires. Live Mode checks on an interval and stays quiet when there is nothing to do. After import, both schedules and Live Mode checks are paused. Review them before enabling, confirm cadence, time, timezone, and expected behavior, then toggle them live. Note: cron jobs configured outside your markdown files, including system cron job entries and shell scripts, won't be picked up. Recreate those manually under the Schedules tab. In OpenClaw, `TOOLS.md` told your agent which tools existed. In Hyperagent, integrations are live OAuth connections. Your agent can actually read your calendar, draft in Gmail, or update Linear, not just know about them. You select which tools to connect and choose the order. The connect step queues only what needs OAuth, not tools that are already live. | Channel | Setup | | -------- | ------------------------------------------------------------------ | | Telegram | Requires re-authentication with your bot token | | Slack | Requires re-authentication via OAuth | | Email | Hyperagent will provide a new email address for your agent to use. | | Discord | In Development | In OpenClaw, channels were where you talked to your agent. In Hyperagent, channels are delivery surfaces your agent can use after you reconnect them. Hyperagent does not transfer channel credentials for security reasons. The wizard queues your channel re-auth alongside your tool connections so it's one flow, not a separate manual step. If the wizard says **no message channels were configured** but you do have Telegram or Slack set up, your channel credentials likely weren't stored in the workspace markdown files. Reconnect manually after import. Custom skill packages carry over as-is and stay scoped to the imported agent. If a skill duplicates a native Hyperagent integration, the preview can start it unchecked and show the built-in replacement instead. ## What does not move [#what-does-not-move] `BOOTSTRAP.md`, one-time reminders, out-of-band cron jobs, OpenClaw plugins, channel tokens, webhook URLs, and raw session history do not move with the import. * Recreate one-time reminders manually * Reconnect channels during the import flow * Reconnect tools after the preview * Keep OpenClaw running until you are satisfied with the imported agent ## Important notes [#important-notes] Schedules and Live Mode come over paused. Nothing runs automatically until you review it and switch it on. Your agent remembers across conversations in Hyperagent. You do not need to maintain `MEMORY.md` by hand anymore. Tools and channels need one-time setup after import before the agent can act on your accounts or reach you there. If your OpenClaw folder contains several agents, run the import once for each agent. If you start an import and do not finish, your in-progress preview appears under **Pick up where you left off** the next time you open the wizard. For the most up-to-date schedules, export with the OpenClaw gateway stopped. Recent schedule changes may otherwise still be in a temporary file. ## Limits [#limits] | Import item | Limit per import | | ----------- | ---------------- | | Memories | 100 | | Schedules | 10 | | Tools | 24 | | Channels | 8 | | Skills | 20 | | Files | 300 | Anything beyond those caps is left out with a note explaining what was skipped so you can add it by hand. Individual files and the overall upload also have size limits. If you hit them, trim the largest files or zip only the workspace folder. ## After the import [#after-the-import] If you want to understand how the imported setup behaves day to day, skim [Threads](https://www.hyperagent.com/docs/concepts/threads) for the run environment and [Skills](https://www.hyperagent.com/docs/concepts/skills) for repeatable methods. Confirm cadence and timezone, then enable the schedules you want running in the cloud. Scan for stale notes or log artifacts and prune anything you do not want to keep. Open a thread when you are ready and let the imported agent introduce itself. The import is a copy, not a move. Keep your old setup until you are satisfied. If your OpenClaw setup relied on heartbeats or a persistent messaging channel, turn on Live Mode after import. ## Troubleshooting [#troubleshooting] Make sure you are dropping the OpenClaw workspace folder, not a parent folder without `AGENTS.md`. Your upload contains files from more than one agent. Import them separately. Drop just the OpenClaw workspace or a zip of it, not a larger parent folder. Zip the workspace files directly rather than zipping a folder that already contains another archive. Usually transient. Try again, ideally after stopping the OpenClaw gateway. A saved preview was already completed or expired. Start a fresh upload. Hyperagent does not have a matching integration for that OpenClaw tool yet. You can continue without it. ## How AI is used [#how-ai-is-used] The wizard uses a single LLM pass during the Preview step. Its job is **judgment and translation only**, not rewriting your content: * Inferring an agent name, icon, short description, and role label from your files * Scoring memories by category (fact about you, preference, project context, etc.), importance, and whether to pin them * Translating your `HEARTBEAT.md` checklist into proper recurring schedules with the correct cadence and timezone * Matching OpenClaw tools to Hyperagent integrations and mapping your messaging channels * Flagging anything that didn't translate cleanly **The AI never rewrites, paraphrases, or "improves" your instructions or memories.** Your `SOUL.md`, `AGENTS.md`, and `IDENTITY.md` are carried over word-for-word. Your memory text is exactly what you wrote. The LLM classifies and scores by reference — it doesn't touch the content itself. Everything else in the wizard is deterministic code: unzipping, safety checks, memory splitting, agent creation, schedule import (imported paused so nothing runs until you've reviewed it), and database writes. ## FAQs [#faqs] Simple agents should not take more than 20 minutes. If you have a long list of tools to reconnect and secrets to re-enter, budget a little more time. Hyperagent translates your markdown memory files into editable agent memories. The preview lets you review each memory and uncheck anything you do not want. Yes. The preview shows the assembled instructions before anything is created. You can edit them, restore trimmed OpenClaw-specific text, or leave the cleaned version. No. Schedules and Live Mode import paused, and tools do not run until you connect them. Hyperagent supports the following models. See [Models and compute](https://www.hyperagent.com/docs/concepts/agents/models) for selection and configuration guidance. **Anthropic:** Claude Fable 5, Opus 5, Opus 4.8, Opus 4.7, Opus 4.6, Sonnet 5, Sonnet 4.6, Haiku 4.5 **OpenAI:** GPT 5.6 Sol, GPT 5.6 Terra, GPT 5.6 Luna, GPT 5.5 **Google:** Gemini 3.6 Flash, Gemini 3.5 Flash **Moonshot AI (Kimi):** Kimi K3, Kimi K3 Fast, Kimi K2.6 **Z.ai:** GLM 5.2, GLM 5.2 Fast **Alibaba:** Qwen 3.8 Max, Qwen 3.7 Plus **DeepSeek:** DeepSeek V4 Flash, DeepSeek V4 Pro **MiniMax:** MiniMax M3 **Sakana AI:** Fugu Ultra **xAI:** Grok 4.6, Grok 4.5 **Meta:** Muse Spark 1.1 **Thinking Machines:** Inkling Yes. Each agent session runs in an isolated VM. Integrations connect via OAuth, and a human-in-the-loop write gate prevents the agent from acting on injected instructions without review. No. The import is a copy, so your old setup keeps running until you decide to turn it off on your schedule. ## Get help in Discord [#get-help-in-discord] If anything looks off during the preview, if a tool is not supported, or if something did not come through the way you expected, join our [Discord community for support.](https://discord.gg/zBtVmkvZ9) --- # Data deletion Source: https://www.hyperagent.com/docs/reference/data-deletion > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. How to delete your Hyperagent account and the data associated with it. You can delete your Hyperagent account at any time. Deleting your account will remove the data associated with it. ## How to delete your account [#how-to-delete-your-account] The fastest way to remove your data is to delete your account from within Hyperagent: 1. Log in to Hyperagent. 2. Go to Settings → Security ([hyperagent.com/settings/security](https://hyperagent.com/settings/security)). 3. Select "Delete Account". 4. Confirm by typing your account email, then confirm deletion. ## No account, or can't sign in? [#no-account-or-cant-sign-in] If you don't have an account you can access, email [privacy@hyperagent.com](mailto:privacy@hyperagent.com) to request deletion. We may need to verify your identity before processing the request. For more details, see our [Terms](https://hyperagent.com/terms?standalone=1) and [Privacy Policy](https://hyperagent.com/privacy?standalone=1). --- # Troubleshoot a stuck run Source: https://www.hyperagent.com/docs/reference/runtime-limits > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. What to check when a run pauses, stops early, loses tool access, or fails to deliver. A run can look stuck for several reasons. It may be waiting for approval, missing access to a tool, continuing in a delegated thread, or finished without sending a notification. Start with the [thread where the work ran](https://www.hyperagent.com/docs/concepts/threads#where-the-work-happens). Its messages and tool activity usually show where progress stopped. Work through the checks below before starting over. In many cases, you can fix the issue and continue in the same thread without losing completed work. ## Start with what you see [#start-with-what-you-see] | What you see | What to check | What to do next | | --------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------- | ------------------------------------------------------------------------------------------------------ | | The run is waiting | An approval card or unanswered question | Approve the action, adjust the request, or answer the question | | A [tool or integration](https://www.hyperagent.com/docs/concepts/tools-and-integrations) failed | The last tool message in the thread | Reconnect the integration, restore access, then ask the agent to retry that step | | A [delegated task](https://www.hyperagent.com/docs/concepts/agents/invocations/other-agents) stopped | The linked child thread | Open it and check for an approval request, missing context, or a tool error | | The run ended before finishing | The last completed step | Ask the agent to summarize what is done and continue only the remaining work | | A [schedule](https://www.hyperagent.com/docs/concepts/agents/invocations) or [Live Mode](https://www.hyperagent.com/docs/concepts/agents/invocations/live-mode) run produced no alert | The run thread and notification settings | Confirm the run started, then check whether it completed quietly or could not deliver the notification | ## Continue without repeating completed work [#continue-without-repeating-completed-work] When a run stops partway through, stay in the same thread and give it a short recovery prompt: ```text Summarize what you completed, what remains, and any errors you hit. Then continue from the last successful step. ``` If the agent no longer has a source file, decision, or instruction it needs, attach or restate that specific [context](https://www.hyperagent.com/docs/concepts/threads/loading-context). You usually do not need to repeat the entire original brief. Before asking the agent to post a message, update a record, or write to a connected app again, confirm whether the first attempt succeeded. The thread's tool activity is the best record of what completed. ## If a tool is unavailable [#if-a-tool-is-unavailable] Check the access path from the agent to the system it needs: 1. Confirm the tool appears in [Tools](https://www.hyperagent.com/docs/tools) and is enabled for the agent. 2. Confirm the integration is still connected in the [integration directory](https://www.hyperagent.com/docs/integrations#connection-reference). 3. Confirm you [allowed access on the agent](https://www.hyperagent.com/docs/concepts/tools-and-integrations#allow-access-on-the-agent). 4. For schedules and Live Mode, confirm [unattended writes](https://www.hyperagent.com/docs/concepts/agents/invocations#automatic-invocations-and-unattended-writes) are allowed if the run needs to change an external system. 5. If the tool uses a browser session, sign in again when prompted. After restoring access, return to the original thread and ask the agent to retry the failed step. ## If delegated work stops [#if-delegated-work-stops] Delegated work runs in a child thread. Open that thread to see its progress instead of waiting in the parent thread. Look for: * An approval the child agent is waiting on * A missing file, credential, or integration * A brief that did not include enough context to finish independently * A tool error that needs to be retried Resolve the issue in the child thread, or send a more complete follow-up there. See [Agent delegation](https://www.hyperagent.com/docs/concepts/agents/invocations/other-agents) for how parent and child threads work together. ## If an automated run does not deliver [#if-an-automated-run-does-not-deliver] For schedules, Live Mode, and event-triggered runs, first find the thread created by the invocation. Then check: * Did the run start at the expected time or event? * Did the agent complete the work? * Is the Slack channel, email address, or other notification destination still connected? * Is the agent allowed to write to that destination without approval? * Was silence an expected result? Live Mode can suppress notifications when nothing crosses the alert threshold. Write automated prompts so each run has the context it needs and can be retried safely. See [Invocations](https://www.hyperagent.com/docs/concepts/agents/invocations) and [Live Mode](https://www.hyperagent.com/docs/concepts/agents/invocations/live-mode) for setup details. ## If a long thread loses context [#if-a-long-thread-loses-context] In a long-running thread, the agent may need you to restate an older decision or attach a source again. Give it the specific missing detail and continue in the same thread. See [How long threads stay coherent](https://www.hyperagent.com/docs/concepts/threads#how-long-threads-stay-coherent) for how Hyperagent carries context forward. Keep instructions the agent should follow every time in its [configuration](https://www.hyperagent.com/docs/concepts/agents/configuration), a [skill](https://www.hyperagent.com/docs/concepts/skills), or a [memory](https://www.hyperagent.com/docs/concepts/memories#what-belongs-in-a-memory) instead of relying on one old message. For larger jobs, use clear milestones so you can see what finished and resume from a known point. ## Contact Support [#contact-support] If the run still cannot continue, send Support: * The thread link * The approximate time and timezone * How the run started: thread, Slack, Telegram, schedule, Live Mode, email, webhook, MCP, or delegation * A screenshot of the error or final message * The external action you expected, if any * What you already tried This gives Support enough context to inspect the failed step without asking you to reproduce the entire job. --- # Models and compute Source: https://www.hyperagent.com/docs/reference/supported-models > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Choose a model and configure reasoning, runtime, timeouts, and context compaction. This page lives under Agents. **[Open Models and compute →](https://www.hyperagent.com/docs/concepts/agents/models)** --- # Troubleshooting FAQ Source: https://www.hyperagent.com/docs/reference/troubleshooting-faq > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Short answers to the questions that show up most in community and support, with links to deeper docs. Use this page when you need a fast pointer. Each answer links to the full concept or reference page. ## Models and cost [#models-and-cost] **Which model should I pick?**\ Start with Latest Opus or Latest Sonnet for important work, a faster tier for Live heartbeats and bulk helpers. Details: [Models and compute](https://www.hyperagent.com/docs/concepts/agents/models). **Why is a model missing from my picker?**\ It is not enabled for your account, or it is still rolling out. The picker is the source of truth. ## Tools, integrations, MCP, skills [#tools-integrations-mcp-skills] **Skill vs integration vs MCP?**\ Method vs connected app vs external tool server. Start with [Tools](https://www.hyperagent.com/docs/tools) and [Integrations](https://www.hyperagent.com/docs/integrations). **Can MCP update skills?**\ No. Hosted MCP runs threads. Edit skills in the product. [Edit and import skills](https://www.hyperagent.com/docs/concepts/skills/skills-edit-and-import). **How do I connect an app that is not listed?**\ Custom MCP if the app speaks MCP; otherwise a skill with scripts and credentials. [Custom MCP](https://www.hyperagent.com/docs/integrations/custom-mcp). ## Automation [#automation] **Live Mode vs schedule?**\ Watch-and-alert vs timed job. [Live Mode](https://www.hyperagent.com/docs/concepts/agents/invocations/live-mode), [Invocations](https://www.hyperagent.com/docs/concepts/agents/invocations). **Why did my schedule not post to Slack?**\ Check integration allow list, channel permissions, and unattended write settings. [Invocations](https://www.hyperagent.com/docs/concepts/agents/invocations). **Minimum Live Mode interval?**\ 30 minutes. Default new cadence is about once per day until you change it. ## Agents working together [#agents-working-together] **Can agents call agents?**\ Yes, with a depth cap of one named-agent hop. [Agent delegation](https://www.hyperagent.com/docs/concepts/agents/invocations/other-agents). **Child agent cannot see the parent chat**\ Expected. Put context in the brief. ## Knowledge and sharing [#knowledge-and-sharing] **Personal vs Curated vs Team learning?**\ [Knowledge and learning](https://www.hyperagent.com/docs/concepts/agents/knowledge-access). Use Curated for most Slack-shared agents. **Import overwrote my skill**\ Normal import should not clobber in place; you may have a duplicate. [Edit and import skills](https://www.hyperagent.com/docs/concepts/skills/skills-edit-and-import). ## Runtime [#runtime] **Run died / tools vanished / long thread got weird**\ [Troubleshoot a stuck run](https://www.hyperagent.com/docs/reference/runtime-limits). ## Billing [#billing] **Credits, invoices, unexpected charges, promo balance**\ Use in-product billing settings and Support. Public docs do not publish plan price sheets here. Include your account email and approximate charge time when you contact Support. ## Still stuck [#still-stuck] 1. Open the thread and read the tool trail 2. Reproduce once in an interactive thread 3. Contact Support with thread link, timestamp, and screenshot ## Related hubs [#related-hubs] * [How Hyperagent fits together](https://www.hyperagent.com/docs/concepts/how-hyperagent-fits-together) * [Integrations](https://www.hyperagent.com/docs/integrations) * [MCP server](https://www.hyperagent.com/docs/concepts/agents/invocations/mcp-server) --- # Tools Source: https://www.hyperagent.com/docs/tools > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Built-in capabilities agents use to research, operate sites, compute, and create finished work. Agents can search, browse, run code, and create finished outputs with built-in capabilities. Configure the standing set on an agent, then adjust one thread when a particular job needs something different. ## Choose tools by the job [#choose-tools-by-the-job] Search the web, produce cited research, build web datasets, and retrieve context from earlier threads. Drive a live browser to navigate sites, fill forms, work behind logins, and hand control to you when a person needs to take over. Run code and command-line tools, manipulate files, and keep working state available across turns in the thread. Publish reports, dashboards, presentations, and experimental interactive apps as shareable outputs. Generate or edit images, video, audio, transcripts, avatar clips, and maps. Tools combine inside one run. A market brief might use Search for sources, Browser for a site that needs interaction, code to analyze the findings, and Webpages to publish the result. ## Set the standing tools and thread exceptions [#set-the-standing-tools-and-thread-exceptions] Use the agent's Tools tab to set the capabilities every run starts with, wherever the work begins. Presets select all, none, or a smart default before you tune individual tools. Open Settings → Capabilities from the composer to change tools for one conversation. Matching the agent's setting again removes the override. Nearly every built-in tool is available by default. **Script** starts off because it is a separate stateless execution environment, while normal code execution is already available in the thread. **HyperApps** starts off because it is early alpha. Configuration is mainly for narrowing a focused agent or enabling one of those exceptions. ## Tools and integrations are different [#tools-and-integrations-are-different] A **tool** is a built-in capability Hyperagent provides, such as Search, Browser, Images, or code execution. An **integration** is access to one of your connected accounts, such as Slack, GitHub, Gmail, or a CRM. Connecting an integration and allowing an agent to use it are separate steps. Browse and manage connected services under [Integrations](https://www.hyperagent.com/docs/integrations). In a thread's **Capabilities** settings, the integration scope can be **Off**, **Selected**, or **Open**. That scope controls which connected accounts the current conversation may use; it does not connect or disconnect the accounts themselves. ## Tool reference [#tool-reference] The reference below follows the groups shown in the product. Keep the commonly needed tools on, then remove capabilities a narrowly scoped agent should not use. | Tool | Default | What it does | | ----------------- | --------- | ------------------------------------------------------------------------- | | **Search** | On | Searches and reads the web through the selected Standard or Exa provider. | | **Thread Search** | On | Searches earlier conversations for context and decisions. | | **Find Similar** | On in Exa | Finds pages similar in meaning to a supplied URL. | | **Exa Answer** | On in Exa | Answers a question with source citations. | | **Exa Research** | On in Exa | Produces deep multi-source research with citations. | | **Exa Websets** | On in Exa | Builds a structured, verified dataset from the web. | See [Research](https://www.hyperagent.com/docs/tools/research). | Tool | Default | What it does | | ----------- | ------- | ---------------------------------------------------------------------- | | **Browser** | On | Navigates a live browser, interacts with pages, and captures evidence. | **Stay logged in** can preserve one thread's authenticated session. Named agents can instead use Persistent sessions. See [Browser](https://www.hyperagent.com/docs/tools/browser). | Tool | Default | What it does | | ------------- | ------- | -------------------------------------------------------------- | | **Tables** | On | Creates, updates, and queries records with typed columns. | | **Documents** | On | Creates and maintains structured writing with version history. | **Global tables across threads** is on by default and lets an agent read tables marked global. See [Documents and tables](https://www.hyperagent.com/docs/knowledge/documents-and-tables) for sharing, scope, and lifecycle. | Tool | Default | What it does | | ------------- | ------- | ----------------------------------------------------------- | | **Webpages** | On | Publishes styled, versioned webpages. | | **Slides** | On | Creates versioned presentations with navigation. | | **HyperApps** | Off | Builds experimental interactive apps with persistent state. | See [Webpages and slides](https://www.hyperagent.com/docs/tools/webpages-and-slides). | Tool | Default | What it does | | -------------- | ------- | ------------------------------------------------------------------------------ | | **Images** | On | Generates and edits images. | | **Video** | On | Generates short clips with native audio, image-to-video, and clip extension. | | **Audio** | On | Produces speech and multi-speaker dialogue. | | **Transcribe** | On | Transcribes supported audio with speaker diarization, timestamps, and emotion. | | **Avatar** | On | Generates a HeyGen presenter video from a script. | | **Maps** | On | Geocodes locations, finds places, calculates routes, and creates map outputs. | See [Media generation](https://www.hyperagent.com/docs/tools/media-generation). | Capability | Default | What it does | | ------------------ | --------- | ---------------------------------------------------------------------- | | **Code execution** | Always on | Runs code and command-line tools with files that persist across turns. | | **Script** | Off | Runs Python or JavaScript in a separate stateless environment. | See [Code and files](https://www.hyperagent.com/docs/tools/data-and-code). Image search for finding existing web images is also available when configured for the account. It is separate from the Images tool, which generates new images. ## FAQs [#faqs] Its supporting service is not available to the account. A locked tool is different from one you turned off, and you do not supply the provider key yourself. Code execution is part of every thread rather than an optional tool. Script is the separate stateless environment controlled by a chip. --- # Browser Source: https://www.hyperagent.com/docs/tools/browser > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Use a live browser to navigate sites, complete forms, work behind logins, hand control to a person, and capture evidence. Some work ends with an answer. Other work has to happen on a site: compare inventory behind filters, upload a file, complete a form, verify a published page, or work inside a signed-in account. The **Browser** tool gives the agent a live browser for that work. Watch the live session from the browser panel and take control at any point. When a login, two-factor prompt, CAPTCHA, or judgment call needs you, the agent hands over the same session and continues from the state you leave behind. ## What the agent can do in the browser [#what-the-agent-can-do-in-the-browser] Navigate, click, type, scroll, fill forms, and upload files from the thread. It can also run a page script when a widget resists ordinary clicks. Observe what's on screen, extract comparable structured data across pages, and pull text or HTML directly. Take screenshots and keep the good ones as thread assets. Hyperagent records every session, and the agent can save that recording as a video you can watch, download, and share. Take control of the live session for a login, challenge page, or judgment call, then hand it back without losing progress. ## Choose the right web surface [#choose-the-right-web-surface] | Surface | Use it for | What it can reach | | -------------------- | ----------------------------------------------------------------------------- | ---------------------------------------------------------- | | **Search** | Finding and reading public information. | Search results and public pages; no signed-in interaction. | | **Browser** | Forms, filters, uploads, logins, visual checks, and other live site work. | Public internet sites and the session's saved login state. | | **Workspace Chrome** | Testing local files, generated HTML, or a development server before shipping. | Files and servers inside the thread's private workspace. | Start with Search when the job is read-only. Use Browser when the agent needs to operate the site or when the page only works in a real browser. Use workspace Chrome for local development that's not yet reachable on the public internet. ## How a browser session works [#how-a-browser-session-works] When the agent needs the browser, it opens a session: one live browser it drives for the length of a job. You can watch that session from the browser panel while the thread is open, and take it over yourself at any point without waiting for an invitation. Sessions are time-bounded rather than permanent. Hyperagent releases a session that sits idle, and every session ends after about an hour. That keeps a long-running job from holding a browser open forever; when the agent needs the site again, it re-opens the page and carries on. A session ending loses nothing about the task, only the live browser itself. ## Hand off logins and challenge pages [#hand-off-logins-and-challenge-pages] For a first-time login, two-factor prompt, CAPTCHA, or any step that needs your judgment, the agent hands you the live session. Complete the step in the browser panel, then return control. The agent continues from the signed-in state you left behind. Handoff keeps the session alive past the agent's turn so it waits for you instead of timing out mid-step. Inside Hyperagent, use the browser panel directly. From an external channel, open the thread in Hyperagent first; only the account owner can enter the session. ## Two ways to stay signed in [#two-ways-to-stay-signed-in] Every session starts clean unless you choose to preserve its login state. Hyperagent has two independent options, and a run uses only one: | | **Stay logged in** | **Persistent sessions** | | ------------------------------------------- | ----------------------------------------------------------------- | ----------------------------------------------------------------------- | | **Scope** | One generalist thread. | Every authorized run of one named agent. | | **Best for** | Continuing one signed-in conversation. | An agent whose recurring work requires the same accounts. | | **Where to enable it** | In the live browser panel or the thread's settings, even mid-run. | On the agent before the run starts. | | **External Slack, email, or Telegram runs** | Not available. | Available because the agent owner explicitly enabled unattended access. | | **How to clear it** | Select **Delete saved logins** on the thread. | Turn persistent sessions off on the agent. | When the agent finishes a sign-in during a handoff, a consent card offers to keep that login. Accept mid-run and Hyperagent queues the save until the turn ends, so keeping a login never interrupts the work in progress. ## Saved logins stay scoped to you [#saved-logins-stay-scoped-to-you] A browser with saved logins acts inside a site as you, so Hyperagent keeps that state within strict boundaries: * **Teammates running a shared agent get a clean browser.** An agent's persistent sessions attach only to runs its owner authorizes, never to a teammate's run of that shared agent. * **You can always delete the state.** Delete saved logins on a thread, turn persistent sessions off on an agent, or delete the thread. Each action destroys the stored login state. * **A thread's logins expire on their own.** Hyperagent deletes a thread's saved logins after the conversation sits untouched for about thirty days. * **Binding a thread to an agent releases the thread's own logins**, since the agent's setting takes over from there. The thread's history records everything the browser does in it. ## Recordings and screenshots [#recordings-and-screenshots] Hyperagent records every session automatically. Ask the agent to save the recording and it becomes an MP4 thread asset you can watch, download, and share. Saving it finalizes the recording and closes the active session, so this should be the final browser step in a job. Screenshots work differently. The agent can inspect a screenshot privately, then save the useful frames as visible thread assets. That keeps failed or irrelevant captures out of the conversation. ## FAQs [#faqs] It hands you the live session. You sign in yourself in the browser panel, clearing any two-factor prompt, and the agent continues from the signed-in state. A consent card then offers to keep the login for next time; the agent saves nothing unless you accept. Only if you ask it to. Turn on persistent sessions on the agent to keep logins across all its runs, or Stay logged in on a generalist thread to keep them for that one conversation. Otherwise every session starts from a clean browser. No. An agent's persistent sessions attach only to runs its owner authorizes, so a teammate running the same shared agent gets a clean browser. A thread's Stay logged in state belongs to that one conversation of yours. Sessions are time-bounded: Hyperagent releases an idle one, and every session ends after about an hour. The task isn't lost, only the live browser. The agent re-opens the page it needs and carries on. This is also why a long job re-navigates rather than holding one browser open the whole time. Take over. When a site throws a challenge page or a step the agent can't clear, it hands you the live session and you handle it in the browser panel; the agent resumes from where you leave the page. Screenshots the agent decides to keep become assets in the thread. Hyperagent records every session, and a saved recording lands in the thread as an MP4 you can watch, download, and share. Saving a recording finalizes it and closes the session, so it comes at the end of a browser job. Browser can't open `localhost` servers or `file://` paths from the thread workspace. For local rendering and testing, use the sandbox's headless Chrome; [Data and code explains how the sandbox connects to the rest of Hyperagent](https://www.hyperagent.com/docs/tools/data-and-code#how-the-sandbox-meets-the-rest-of-the-platform). --- # Code and files Source: https://www.hyperagent.com/docs/tools/data-and-code > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Analyze data, update many files, work with websites and repositories, and produce finished outputs using a private computer. Give an agent a folder of exports and ask for one clean dataset. Hand it a website and ask for a new page. Ask it to rename hundreds of files, convert a video, inspect a repository, or package a finished report. Every thread has a private computer capable of doing that work from beginning to end. None of it requires you to be a coder. The same machinery a developer uses to test a codebase is what a marketer uses to merge twelve campaign exports into one clean sheet, standardize a folder of images, pull the tables out of a stack of PDFs, or turn a two-hour transcript into a formatted report. If you can describe the transformation, the agent writes and runs whatever gets it done, and what you see is the finished files. You don't need to write code or specify commands. The agent can choose the right programs, run them, check the result, and return finished files you can open or download. You also don't have to tell the agent to use the computer. Describe the whole task, however complex, and the agent decides when the work calls for it. For evaluating specific workflows, what follows covers what the machine comes with, what it can connect to, and where its boundaries sit. ## What the sandbox lets an agent do [#what-the-sandbox-lets-an-agent-do] Write and execute Python, Node.js, shell commands, and existing project scripts. Read the output, diagnose failures, change the approach, and run the work again. Clone public repositories, inspect history and diffs, edit files, run the project's checks, and prepare a verified change. Add libraries and command-line packages when the built-in environment isn't enough. Installed dependencies remain available across later turns in the thread. Search directories, combine exports, convert formats, extract archives, resize or convert media, and create a clean output directory. Package code, reports, datasets, images, audio, video, and archives as files you can open, download, or use in the next step of the work. The agent can combine these operations in one job. It might clone a public repository, install its dependencies, change a component, run the test suite, build the project, and return the changed files and verification results. ## The machine and its filesystem [#the-machine-and-its-filesystem] Each thread receives its own sandbox. Files created in one turn remain available in later turns, so the agent can build on earlier work instead of recreating its state every time. Package installations persist with those files. The sandbox may sleep after sitting idle. Waking it can make the first command on a later turn take a little longer, but its files and installed state remain intact. Another thread doesn't inherit its files or installed packages. Return files as outputs when you need to download them, preserve them in the Library, or use them outside the source thread. Files worth keeping appear as downloadable cards in the thread and in your [Library](https://www.hyperagent.com/docs/concepts/library). Temporary source files, caches, installed packages, and intermediate results can remain inside the sandbox while the agent works. Treat the sandbox as a workbench rather than an archive: anything you should be able to open, share, or recover on its own belongs in an artifact, document, or table, not only on the sandbox filesystem. ## What comes installed [#what-comes-installed] The base environment covers common software, data, repository, and media workflows. | Category | Included | | ---------------------- | ------------------------------------------------------------------------------------------------------ | | **Operating system** | Linux | | **Runtimes** | Node.js 24 and Python 3 | | **Repository and web** | `git` and `curl` | | **Package managers** | `npm` and `pip` | | **Search and data** | `ripgrep` (`rg`) and `jq` | | **Media** | `ffmpeg` and `ffprobe` | | **PDFs** | Poppler utilities (`pdftotext`, `pdfinfo`, `pdftoppm`) | | **Local rendering** | Headless Chrome Stable channel | | **Fonts** | Liberation and DejaVu families | | **Python libraries** | `requests`, `pandas`, `numpy`, `matplotlib`, `Pillow`, `beautifulsoup4`, `openpyxl` Normally available | | **Archives** | `tar`, `gzip`, `zip`, and `xz` | Headless Chrome is the sandbox's own renderer: it opens files and local servers inside the sandbox to screenshot and check them, which the separate [Browser](https://www.hyperagent.com/docs/tools/browser) tool cannot reach. A **Normally available** package is installed on a best-effort basis; when one is missing, the agent installs it and continues. Project-specific fonts still get downloaded or bundled per job. When the task needs another library or CLI, the agent can install it and continue. Ask for a particular tool when the version or implementation matters; otherwise, the agent can choose what fits the job. ## Common workflows [#common-workflows] **Inspect, change, and verify a codebase** The agent can clone a public repository, search it with `rg`, inspect Git history, create or edit files, review the diff, and run the repository's own validation commands. Git is installed, but the sandbox does not arrive with your Git credentials. Public clones work directly. Authenticated repository access and pushes need an approved integration or credentialed skill. The sandbox can't open an SSH connection or proxy one for another tool. Use HTTPS-based access through an approved integration or API instead. **Use the project's own toolchain** Install dependencies, run linters and tests, compile the project, inspect failures, and repeat until the requested work passes. The agent can preserve logs and build outputs when they are useful for review. This works for more than application code. The same loop can validate a static site, execute a data pipeline, generate documentation, or run a repository's release scripts. **Transform the source material in place** Parse JSON with `jq`, search large directories with `rg`, write Python or Node.js transformations, combine exports, normalize filenames, and produce CSV, JSON, text, or other requested files. Because the filesystem persists across turns, you can review an intermediate result and ask the agent to refine only the remaining problems. **Process outputs at the command line** Use `ffmpeg` to inspect, convert, trim, combine, or compress supported media. Extract incoming archives, reorganize their contents, and return the result as a new `zip`, `tar`, or `gzip` file. **Use a purpose-built command-line tool** A CLI can be more efficient than MCP when the work involves batching many operations, chaining commands, or processing results locally. The agent can install the tool it needs, run it directly in the sandbox, and combine it with files and other commands. Use pandoc for Markdown, HTML, Word, and other document formats, or headless LibreOffice for batch conversion of Word, PowerPoint, and Excel files. Use duckdb to query CSV, JSON, and Parquet files with SQL, or csvkit to inspect, filter, clean, and join CSVs. Use pdftotext and pdfinfo to inspect PDFs, or ocrmypdf to make scanned documents searchable. Use magick to resize or convert images, exiftool to inspect metadata, and ffmpeg for audio and video. Use gh to inspect repositories, manage issues and pull requests, and work with releases from the command line. Use rclone to move files between supported cloud storage services after configuring the required account access. A service CLI still needs its normal credentials. Use [Custom MCP](https://www.hyperagent.com/docs/integrations/custom-mcp) when the capability, credentials, or governed access is provided through an MCP server instead. ## Network access and service boundaries [#network-access-and-service-boundaries] Code can make outbound HTTP and HTTPS requests. When it reaches a domain that hasn't been approved for the thread, Hyperagent pauses the run and asks before sending the request. **Allow for this thread** applies only to that conversation. Another thread begins with its own approvals. Search and [Browser](https://www.hyperagent.com/docs/tools/browser) use their own access paths; this approval covers requests made by code inside the sandbox. ### What the sandbox can connect to [#what-the-sandbox-can-connect-to] | Connection pattern | Support | What to use | | ----------------------------- | ------------- | ----------------------------------------------------------------------------------------------------------------- | | Outbound HTTP or HTTPS API | Supported | Approve the domain for the thread, then call the API normally. | | Managed database over HTTPS | Supported | Use the provider's HTTPS API or a native integration. | | Local web server | Local only | Headless Chrome in the same sandbox can open it for tests; it cannot accept outside traffic. | | SSH or an SSH proxy | Not supported | Use an HTTPS API, integration, or credentialed skill instead. | | SMTP, FTP, or raw TCP | Not supported | Send email and move files through an integration or an HTTPS API. | | Direct database wire protocol | Not supported | Use the database's HTTPS API or native integration instead of a direct PostgreSQL connection. | | Public inbound traffic | Not supported | Publish with [Webpages and slides](https://www.hyperagent.com/docs/tools/webpages-and-slides), or return the built files as thread outputs. | ## How the sandbox meets the rest of the platform [#how-the-sandbox-meets-the-rest-of-the-platform] The sandbox is one of several environments a run touches, and the boundaries between them are deliberate. Each boundary links to its full story. The sandbox's headless Chrome reaches sandbox files and localhost; the watchable [Browser](https://www.hyperagent.com/docs/tools/browser) tool reaches neither. To test work in the live browser, publish it first. An enabled [integration](https://www.hyperagent.com/docs/integrations#what-a-connection-puts-in-a-run) gives the run callable actions and their results. The stored OAuth token never enters the sandbox; nothing running here can read or forward it. Fetching a [credentialed skill](https://www.hyperagent.com/docs/concepts/skills/apis-and-credentials) copies its scripts into the workspace. The credential stays separate: locked to one host it never enters the sandbox at all, and even script-readable values go only to the credentialed process while it runs. Files, packages, and repositories sit in the sandbox without occupying the model's [context window](https://www.hyperagent.com/docs/concepts/threads/loading-context); a file costs context only when the agent reads it. Big results can stay on disk and be read selectively. ## Give durable results the right home [#give-durable-results-the-right-home] The sandbox is ideal for doing the work and producing files. When a result should remain easy to query or edit across other threads, save it in the structure designed for that job: Keep typed records the agent should query and update over time. Tables can be promoted to an agent or made global and can be exported as CSV or JSON. Keep section-based writing with version history and thread, project, or global scope. See [Documents and tables](https://www.hyperagent.com/docs/knowledge/documents-and-tables) for their editing, scope, sharing, and version behavior. ## FAQs [#faqs] The sandbox has Git, but repository credentials aren't built in. Use an approved integration or a credentialed skill for authenticated repository access. Raw SSH access isn't supported. No. A process can listen inside the sandbox for local testing, but the sandbox accepts no inbound traffic. Publish the interface as a webpage or return its built files instead. Use the database's HTTPS API or a native integration. Direct database protocols and SSH tunnels aren't supported. It tried to reach a domain the thread had not approved. Allowing the domain lets later HTTP or HTTPS requests to it continue in this thread; other threads keep their own approval lists. Yes. They persist with the thread even when the sandbox sleeps. A different thread starts with its own clean filesystem and packages. --- # Media generation Source: https://www.hyperagent.com/docs/tools/media-generation > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Everything an agent can create as media: images, short video with native audio, speech, transcripts, avatar videos, and maps. Product shots for a launch, a narrated walkthrough, a transcript of yesterday's call, a map of the route. The media tools generate and edit that work directly in the thread, and everything made here becomes an artifact in the thread and your [Library](https://www.hyperagent.com/docs/concepts/library), ready to reuse or share. These tools create new media from your request. Finding existing images on the web is a separate always-available capability, and publishing pages and decks is [Webpages and slides](https://www.hyperagent.com/docs/tools/webpages-and-slides). ## What an agent can make [#what-an-agent-can-make] Generate images from a prompt or edit ones you provide, across three models, resolutions to 4K, and a range of aspect ratios. Clips of four to eight seconds with native audio, kept consistent shot to shot with a first frame and reference images. A single narrated voice or a multi-speaker exchange with a distinct voice per speaker. Speaker labels, per-segment timestamps, and detected emotion, so a meeting or interview becomes searchable and quotable. A talking-head presenter for a spokesperson clip, explainer, or personalized message, from HeyGen avatars and voices. Geocoding, places, directions, distances, an interactive map, and a Street View image of a real location. ## Media generation tools [#media-generation-tools] | Media | Powered by | Capabilities | Limits / specs | | ------------------ | ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Images** | **Nano Banana****Nano Banana Pro****GPT Image 2** | Generates one image or a set in parallel. Edits images you provide by restyling or combining them, or by creating variations for product shots, hero banners, and redraws. | Outputs 1K, 2K, or 4K images in square, 16:9, 9:16, and wider or taller aspect ratios. Nano Banana is the fast default; Nano Banana Pro prioritizes fidelity; GPT Image 2 handles crisp text, dense compositions, and complex multi-image edits. | | **Video** | **Google Veo 3.1** | Text-to-video, image-to-video, reference-guided generation, video extension, and native audio. A first frame and reference images keep a product, person, or style consistent across clips. | Four-to-eight-second clips at 720p or 1080p, in 16:9 or 9:16. Supports one first frame and up to three reference images. | | **Audio** | **Google Gemini Text-to-Speech** | Single-speaker narration or multi-speaker dialogue with a distinct voice for each speaker. | Around 40 dialogue turns or roughly eight minutes per call. Generate longer pieces in parts and stitch them together. | | **Transcription** | **Google Gemini multimodal transcription** | Structured transcripts with speaker identification, per-segment timestamps, language detection, and detected emotion. | MP3, WAV, AAC, OGG, FLAC, and AIFF files up to 20 MB. M4A is not supported. | | **Avatar video** | **HeyGen** | Talking-head spokesperson clips, explainers, and personalized messages using avatars and voices from the connected HeyGen account. | Runs asynchronously and takes a few minutes. | | **Maps** | **Google Maps Platform** | Geocoding, Places search, directions, distance calculations, interactive maps, Street View, weather, time zones, markers, routes, and street, satellite, or dark map styles. | Aerial View is available for US addresses. An uncached cinematic 3D view can take one to three hours to render. | ## Media is not versioned [#media-is-not-versioned] Unlike [webpages and slides](https://www.hyperagent.com/docs/tools/webpages-and-slides), generated images, audio, and video keep no version history. Regenerating doesn't replace earlier generations, it simply adds more artifacts to your thread. ## FAQs [#faqs] Nano Banana is the default and the right pick for most images: Pro-level quality at Flash speed. Reach for Nano Banana Pro when the image has to be exactly right and you will trade speed for fidelity. Reach for GPT Image 2 when the image carries crisp text, a dense composition, or a complex multi-image edit. Use the two consistency controls. A first frame image sets the exact opening frame each clip animates from, and up to three reference images guide style and character so the same subject holds together across clips. Feed in the images you already generated and a set of separate clips reads as one coherent piece. M4A is not a supported format. Transcription accepts MP3, WAV, AAC, OGG, FLAC, and AIFF, up to 20 MB per file. Convert the M4A to one of those first and it will transcribe with speaker labels and timestamps. Its supporting service isn't available to the account. Images, Video, Audio, Transcribe, and Avatar rely on a platform-configured service; when it's unavailable the tool reads as locked rather than off. You never supply keys for these yourself. Every artifact lands in the thread that made it and in the Library, searchable across all your threads, so an image, clip, or transcript is easy to find and reuse later. --- # Research Source: https://www.hyperagent.com/docs/tools/research > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. How an agent finds things out: web search with a Standard or Exa provider, cited answers and deep reports, lookalike discovery, verified datasets, and search across your own threads. Before an agent acts, it finds things out: what the market looks like, what a page says, what you decided three weeks ago. Research is the group of tools that answer those questions, from a quick lookup to a report a team could circulate, without you gathering anything yourself. You never choose a research tool by name. Ask for a fact and the agent searches; ask for a market picture and it reads many sources into one cited report; mention a past decision and it searches your own threads. Your part is deciding which methods it may reach for. ## What research gets you [#what-research-gets-you] Search finds pages and reads them, so "what changed in their pricing this quarter" comes back with sources, not guesses. Exa Answer returns a direct answer with citations, so every claim points back to where it came from. For a grounded fact, not a reading list. Exa Research reads many sources and synthesizes one structured, cited result. This is the tool behind a real competitive brief or market survey. Find Similar takes a URL you already trust and finds pages like it in meaning: competitive sets, lookalike sources, related reading. Exa Websets builds a structured dataset from the web, checking each entry against your criteria. Lead lists and research corpora that arrive in minutes, not instantly. Thread Search reaches your own past conversations, so an agent picks up work it started weeks ago instead of asking you to repeat it. ## Two providers, one decision [#two-providers-one-decision] Web search runs on one of two providers, and the choice shapes what the agent can do: * **Standard** is the built-in web search and page fetch. It handles straightforward lookups well and is the simplest default. * **Exa** searches by meaning rather than keywords, which pays off when the query is a concept ("companies doing usage-based pricing for agents") rather than an exact phrase, and it returns cleanly parsed page content instead of raw HTML. Choosing Exa is also what unlocks the four Exa tools above: Find Similar, Exa Answer, Exa Research, and Exa Websets run only through Exa. That's the whole decision: Standard for simple lookup work, Exa when research is the job. In the toolbar, the provider lives on the Search chip itself, and the four Exa tools appear beneath it while Exa is selected. ## Reading is part of searching [#reading-is-part-of-searching] Finding a page is half the job; the agent also reads what it finds, and on Exa it gets back parsed content that's easier to work with when a page is dense or cluttered. Some pages resist reading: content that only renders in a real browser, or sits behind a filter or a login. For those the agent escalates to the [Browser](https://www.hyperagent.com/docs/tools/browser) on its own. The dividing line is the one you'd use yourself: reading a public page is research; operating a site is browsing. ## Your threads are a research source [#your-threads-are-a-research-source] Thread Search treats your own history as something the agent can look up: the call you made in another conversation, the analysis a thread produced last month, the context that would otherwise need re-explaining. It sits in the Research group and works on either provider. One boundary is explicit: thread search works only on threads you own, a standalone web thread or a named agent's run over its own threads. It isn't available on shared-agent runs or externally triggered ones, like inbound email, webhooks, Slack, Telegram, channels, and @mentions, so a run started by an outside event can't read through your other conversations. ## Finding images is research too [#finding-images-is-research-too] Searching the web for existing images, as references or seeds for image work, is always available when it's configured for your account, with no chip to switch on. It's separate from [generating new images](https://www.hyperagent.com/docs/tools/media-generation), which draws from a prompt rather than finding what already exists. ## FAQs [#faqs] Standard for straightforward lookups; it's the simplest default. Switch to Exa when queries are concept-shaped rather than exact phrases, when you want cleanly parsed page content, or when the job needs one of the Exa tools: cited answers, deep reports, lookalike discovery, or a built dataset. They show only while Exa is the selected provider on the Search chip. On Standard, Find Similar, Exa Answer, Exa Research, and Exa Websets disappear from the toolbar, because all four run through Exa. No. Search finds and reads pages without driving a live browser. Interacting with a page, clicking, filtering, working past a login, is the separate [Browser](https://www.hyperagent.com/docs/tools/browser) tool, and the agent escalates to it on its own when reading isn't enough. Thread search works only on threads you own. A shared agent run by a teammate, or a run triggered from outside, inbound email, a webhook, Slack, Telegram, a channel, or an @mention, can't read through your other conversations by design. No. Searching the web for existing images is an always-available capability with no chip. The Images tool in [Media generation](https://www.hyperagent.com/docs/tools/media-generation) creates new images from a prompt. --- # Webpages and slides Source: https://www.hyperagent.com/docs/tools/webpages-and-slides > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Publish reports, dashboards, and presentations as versioned artifacts with public URLs, plus early-alpha interactive HyperApps. A chat reply gets scrolled past. These tools end a job with something you can put in front of people: a designed report at a URL you send to an exec, a dashboard your team bookmarks, a deck you present from any screen. You describe the outcome; the agent designs it, builds it, and hands you the link, no designer or developer in the loop. Whoever you send it to needs nothing but the URL: no Hyperagent account, no attachment, no export. When you want changes, ask, and the same link updates in place with every earlier version kept. Everything published also lands in the thread and your [Library](https://www.hyperagent.com/docs/concepts/library). ## What the agent can publish [#what-the-agent-can-publish] Reports, dashboards, and one-pagers as styled pages with a public URL anyone can open. Presentations with real navigation: arrow keys, on-screen buttons, a slide counter, touch swipe. Early-alpha interactive apps with custom UI and their own persistent state. ## Publish webpages, slides, and apps [#publish-webpages-slides-and-apps] Ask for a report, dashboard, one-pager, or presentation and the agent designs and builds the finished result. [You can then publish it at a public URL you can send to anyone.](#publish-to-share-your-work) Beyond static pages, an early-alpha tool called **HyperApps** builds interactive apps with custom UI, their own persistent state, and direct access to tools, all through conversation. It is off by default and experimental. For finished, shareable deliverables today, webpages and slides are the dependable path. The agent can revise and republish the same artifact. Each publish creates a new version, so work refined over several turns keeps its history. ## The agent checks its own work [#the-agent-checks-its-own-work] After publishing a webpage, the agent can check the finished result itself. A **health check** loads the public page in a real browser and reports console errors or failed requests, catching a broken chart or missing script before you send the link. The agent can also open the published URL with the live [Browser](https://www.hyperagent.com/docs/tools/browser) tool to verify the page's layout and behavior. Publishing makes that check possible because the browser runs apart from the thread's sandbox and needs a public URL it can reach. ## Your controls on the page [#your-controls-on-the-page] The page opens in a panel with its title and controls along the top: zoom, **Edit**, **Publish**, and a menu with Reload, Fullscreen, Dock to right, Open in new tab, and Download HTML. ### Edit lets you change the page yourself [#edit-lets-you-change-the-page-yourself] You can work directly with generated webpages and slides, which is helpful when you make small changes, or simple code changes like colors, fonts, or layout. To edit a page: * Select the artifact in the activity pane. * Select **Edit** to work on the page directly. * Use **Preview** to select and update text in place. * Select **Code** in the status bar to edit the underlying HTML. * Select **Save** to record the changes as a new version, or **Cancel** to discard them. ### Restore versions from earlier edits [#restore-versions-from-earlier-edits] Because webpages, slides, and HyperApps are versioned, revising one never costs you the last good copy, whether the agent republished or you selected **Save** in the editor. Once an artifact has more than one version, a version chip appears on it; opening it shows the **Version History** popover, a list of every version with its change note and time. Any earlier version has a **Restore this version** control, and restoring first saves your current version to history, so the restore itself is reversible. This is the same version machinery [documents](https://www.hyperagent.com/docs/knowledge/documents-and-tables) use. Generated [media](https://www.hyperagent.com/docs/tools/media-generation) is not versioned; to keep an earlier image or clip, save it before regenerating. ### Publish to share your work [#publish-to-share-your-work] Publish an artifact to share it with others. To publish an artifact, select the artifact's name and choose **Publish**. From here you can control your page's publish settings. Control the following options: * **Allow your page to be accessed by search engines** A published page is not indexed by default; **Allow search engines to index this page** is your explicit opt-in. * **Restrict to allowed domains** limits who can open the page, and a domain-restricted page is never indexed regardless of the toggle above. * **Show view count** displays the page's views to visitors as social proof; until you turn it on, only you see the number. ### Choose when to publish updates [#choose-when-to-publish-updates] The published copy doesn't update until you **explicitly publish a new version.** When the source has changed since you published, the dialog flags **Source updated** and one click on **Update published page** ships the current version. **Unpublish** takes the page down without deleting the artifact. ## FAQs [#faqs] The agent edits and republishes the same page. Each publish creates a new version, so the page keeps its history as you refine it, and the agent can run a health check afterward to catch console errors or failed requests before you share the link. No. A published page is static: it renders anywhere without the agent, and nothing inside it can call tools or APIs. For an interactive experience with state, that is what HyperApps are for, with the early-alpha caveat that page carries. By default, anyone with the link, and search engines stay out unless you opt in with **Allow search engines to index this page**. To narrow the audience, turn on **Restrict to allowed domains** in the publish dialog; a domain-restricted page is never indexed. **Unpublish** takes the page down entirely without deleting the artifact. Both. Select **Edit** on the page's panel to change it directly, switching between **Code** and **Preview** as you work; **Save** records your edit as a new version and **Cancel** discards it. The agent and you edit the same artifact, and version history keeps every state either of you saved.