# How Hyperagent fits together

Source: https://www.hyperagent.com/docs/concepts/how-hyperagent-fits-together

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](/docs/concepts/agents)

Where one run happens. It holds messages, tool calls, files, decisions, and
the output from that conversation. [Threads](/docs/concepts/threads)

A reusable method. It teaches an agent how to perform a specific kind of
work. [Skills](/docs/concepts/skills)

Saved context. It carries facts and preferences forward without turning the
whole chat history into the brief. [Memories](/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](/docs/concepts/teams)

The gallery of outputs produced across threads, ready to find, reuse,
publish, or share. [Library](/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](/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](/docs/concepts/skills) so the checklist and output format stay consistent.

### Keep the facts [#keep-the-facts]

Link [memories](/docs/concepts/memories) for risk thresholds, reporting preferences, and the delivery audience. Set the [knowledge boundary](/docs/concepts/agents/knowledge-access) before the agent is shared.

### Start each run [#start-each-run]

Add a Monday [schedule](/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](/docs/concepts/library). Share the agent with the sales team when they should run the same role themselves.

Start with [Agents](/docs/concepts/agents) when you are staffing a recurring role. Start with [Skills](/docs/concepts/skills) when you already have a method worth teaching once.