# Agents Source: https://www.hyperagent.com/docs/concepts/agents A configured teammate you staff once and reuse across threads, channels, and schedules. An **agent** is an AI teammate that you give a role and a job to, and equip it with the tools, context, and access it needs to complete it at your quality bar. You shape it once, then the same teammate shows up in a thread, email, or a Slack channel delivering a Monday report without you rebuilding the briefing from scratch. The agent carries its identity, methods, and standing context into each run. The [thread](/docs/concepts/threads) is still where the agent completes the work. The agent is who shows up. You do not need every layer on day one. Start with a job worth repeating, then add tools, knowledge, and triggers as the role earns them. ## A role worth staffing [#a-role-worth-staffing] Use an agent when Hyperagent should own a **recurring responsibility**, not only answer one prompt. If you keep asking for the same kind of result, with the same tools and standards, that pattern deserves a named role. The agent becomes employable when it can carry the job, context, tools, and ways to start work without a fresh briefing. Every agent should be equipped with a job description, the tools it needs to do the work, and the context it should carry into each run. The cards below show three example agents with their job, context, and tools. ## Every run has a thread [#every-run-has-a-thread] A **run** is one time the agent does the work. The messages, tool calls, files, decisions, and outputs always live in a [thread](/docs/concepts/threads). [Invocations](/docs/concepts/agents/invocations) decide how the run starts. Integrations decide which connected systems the agent can read from or write to. The role stays the same even when the route changes. Open a thread when you want the full workspace. Use Slack or Telegram when the request already lives in a team conversation. Use schedules for recurring deliverables. Use Live Mode for monitoring. Email and webhooks start a run when another system owns the event. ## What you configure [#what-you-configure] Agent settings answer practical staffing questions: who this role is, what it can use, what it knows, how it should think and spend, where a run can start, how much freedom it has, and how you review what happened. The cards below follow one RevOps agent so the settings feel like a real staffing decision, not an abstract checklist. Name, icon, description, and system prompt. Role, tone, decision style, standards, and boundaries. You are a RevOps agent for revenue leadership. Monitor pipeline movement, reconcile CRM and warehouse data, flag risk, and prepare concise updates for sales leaders. Systems where the data and delivery live, plus research and creation tools. Connecting an account is not enough; the agent must be allowed to use it. See [Tools and integrations](/docs/concepts/tools-and-integrations). Salesforce Databricks Google Sheets Slack Gmail Exa Search Repeatable methods for this job: how to review the pipeline, how to spot risk, how to write the update. Weekly Pipeline Summary Forecast Variance Review Deal Risk Triage Board Metrics Narrative Facts and standards the role should not need re-explained every run. Controlled by [knowledge access](/docs/concepts/agents/knowledge-access). FY26 pipeline targets Enterprise segment definitions At-risk deal thresholds Leadership update format Choose the model after you choose the job. Judgment-heavy forecast review can use a stronger model; recurring read-heavy checks can use a leaner one. Swap the model without rebuilding the role. Stronger model for forecast review Leaner model for Live Mode heartbeat Higher effort on variance analysis Run budget cap Threads, Slack, Telegram, schedules, [Live Mode](/docs/concepts/agents/invocations/live-mode), email, and webhooks. [Invocations](/docs/concepts/agents/invocations). Monday 7 AM forecast run @RevOps in #sales-leadership Stage-change webhook Approvals and autonomy: whether the agent runs end-to-end or pauses before sensitive external actions. Unattended schedules have their own write rules. Auto when you are in the thread Ask first before external writes Unattended write rules on schedules Recent threads, usage, and cross-channel runs so you can inspect, continue, and debug real work. Recent threads Last run Evaluations ## How the role improves [#how-the-role-improves] Agents get more useful when repeated work stops living only in chat history. * **[Skills](/docs/concepts/skills)** capture methods: research process, report format, voice, or how to use a system the same way every time. * **[Knowledge access](/docs/concepts/agents/knowledge-access)** controls what context the agent can see and whether conversations can change what it knows. Standing facts often live as [memories](/docs/concepts/memories). * **Rubrics** define what good looks like so you can evaluate against a standard instead of vibes. When other people should run the same role, share it through a [team](/docs/concepts/teams) and set knowledge access first. Most channel-facing agents should start with a narrow knowledge boundary rather than access to every personal memory. ## FAQs [#faqs] When the responsibility has a recurring audience, operating style, or outcome. If you keep asking for the same kind of result with the same tools and standards, that pattern deserves a role. Use an agent for the teammate and a [skill](/docs/concepts/skills) for the method. A Chief of Staff agent can use a Weekly Pipeline Summary skill. The agent owns the role; the skill teaches one kind of work. Yes. Each [thread](/docs/concepts/threads) keeps its own conversation and artifacts. The agent brings the same identity, tools, skills, and knowledge into each run. Yes. Connect tools, attach skills, or change settings and the next turn picks them up. If the agent tried to use Slack before it was connected, connect Slack and continue. Yes, for one-off work with the default agent. For outcomes you expect to repeat, improve, or deploy to a team, configure an agent so the role carries forward. An agent is the configured teammate: identity, instructions, tools, skills, knowledge, controls, and [invocations](/docs/concepts/agents/invocations). [Threads](/docs/concepts/threads) are where individual runs happen. [Skills](/docs/concepts/skills) are methods the role can call. As you teach the agent how your team operates, that context carries into the next thread, channel, and trigger.