> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cogniagent.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Workers

> What a worker is made of — instructions, skills, assets, and connections — and how to create, template, and manage one.

A worker is a reusable AI colleague that lives in your workspace. You build it once from instructions, skills, assets, and connections, and everyone in the workspace can then hand it real work. This page covers what a worker is made of, how to create and configure one, and how to manage it over its lifetime.

## What a worker is made of

A worker packages four things together:

<CardGroup cols={2}>
  <Card title="Instructions" icon="file-lines">
    The worker's persona and rules — who it is, how it should behave, and what "done" looks like for its job.
  </Card>

  <Card title="Skills" icon="puzzle-piece" href="/cowork/workers/skills">
    Packaged `SKILL.md` capabilities the worker loads on demand — how it knows to do a specific job well.
  </Card>

  <Card title="Assets" icon="folder">
    Files, scripts, and reference material the worker can read and use — shared, workspace-visible, and instantly up to date for everyone.
  </Card>

  <Card title="Connections" icon="plug" href="/cowork/workers/capabilities">
    Integrations attached through the Connection Manager, exposed to the worker as callable tools.
  </Card>
</CardGroup>

This combination is the worker's **definition** — a fixed, shared template. Every time someone starts a [task](/cowork/tasks/overview) with the worker, the harness pins a snapshot of that definition (instructions, skills, model, connections) for the life of the task. That means editing a worker later never retroactively changes a task that's already running — it only affects tasks started after the change.

The one deliberate exception is hooks: they're re-read live at the start of every turn instead of being frozen into the snapshot, so fixing a broken hook takes effect on the very next turn of a task already in progress. See [Hooks](/cowork/loop/hooks) for why they work this way.

<Info>
  Instructions, skills, assets, and connections are all **workspace-scoped**: the moment one is added or changed, every workspace member sees the update. Only tasks — the private conversations that use a worker — stay owner-only. See [Tasks](/cowork/tasks/overview) for that split.
</Info>

## Creating a worker

Workers are template-first: you start from a role that already has starter skills and suggested connections, then customize, or build from a blank worker if nothing fits.

<Steps>
  <Step title="Pick a template or start blank">
    Click **Hire** from the Roster. Choose a prebuilt role, or pick "Blank" to build the worker from scratch.
  </Step>

  <Step title="Name it and give it a role">
    Set a name, an avatar, and a one-line description of what it does.
  </Step>

  <Step title="Choose a model">
    Pick the model the worker uses for its tasks. You can change this later from its Overview tab.
  </Step>

  <Step title="Review the starter instructions and skills">
    Templates ship with draft instructions and a starter set of skills. Edit them to match how you actually work.
  </Step>

  <Step title="Connect capabilities">
    Attach any suggested connections through the Connection Manager. This step is optional and skippable — you can connect capabilities later.
  </Step>

  <Step title="Create">
    The worker is created and you land on its page, ready to review its skills, capabilities, and start its first task.
  </Step>
</Steps>

## Prebuilt worker templates

Each template bundles a role, starter skills, and suggested connections so you're not starting from a blank page:

| Template             | Does                                                                | Suggested connections                      |
| -------------------- | ------------------------------------------------------------------- | ------------------------------------------ |
| SDR / Outbound       | Prospect research, personalized outreach, follow-ups, book meetings | Gmail, LinkedIn, calendar, CRM, web search |
| Inbound Qualifier    | Score and route inbound leads, enrich, reply                        | CRM, email, enrichment, Slack              |
| Recruiter            | Source and rank candidates, screen, schedule                        | Email, calendar, ATS, web search           |
| Researcher / Analyst | Multi-source research, competitor and market briefs, reports        | Web search/extract, Drive, code (charts)   |
| Ops / RevOps         | CRM hygiene, report building, cross-app sync                        | CRM, Sheets, Slack, code                   |
| Customer Success     | Triage support, onboarding steps, churn signals                     | Helpdesk, email, Slack, knowledge base     |
| Finance Ops          | Invoice/AR reconciliation, quotes                                   | Sheets, accounting, email, code            |
| Content / Marketing  | Repurpose content, drafts, brand-voice checks                       | Drive/CMS, social, web search              |
| Data / Code worker   | Scripts, scraping, file and data transforms, dashboards             | Code sandbox, Drive, web extract           |
| EA / Chief of staff  | Inbox triage, scheduling, summaries, reminders                      | Email, calendar, Slack                     |

<Note>
  This is the starting menu, not a hard limit — the exact template roster can grow. Every template is fully editable after creation, and "Blank" is always available if none of them fit.
</Note>

## The worker's page

Once created, a worker has its own page with tabs for its definition and its history:

<AccordionGroup>
  <Accordion title="Overview" icon="id-card">
    The worker's identity — name, avatar, role, current status, and model at a glance.
  </Accordion>

  <Accordion title="Instructions" icon="file-lines">
    The persona and rules that shape how the worker behaves, edited with a live preview.
  </Accordion>

  <Accordion title="Skills" icon="puzzle-piece">
    The `SKILL.md` packages the worker can load, with enable/disable toggles per skill. See [Skills](/cowork/workers/skills) for how skills are packaged and loaded.
  </Accordion>

  <Accordion title="Capabilities" icon="plug">
    The connections attached through the Connection Manager, each exposed to the worker as a tool it can call. See [Capabilities & connections](/cowork/workers/capabilities) for the full model.
  </Accordion>

  <Accordion title="Channels" icon="comments">
    Where the worker is reachable beyond Cowork itself — Slack, email, and other surfaces it can be messaged from. See [Channels](/cowork/collaborate/channels) for setup.
  </Accordion>

  <Accordion title="Memory" icon="brain">
    What the worker has learned — notes it or you have written, viewable and editable here. Notes can be written live during a task, and the improvement reviewer proposes new ones after a task for you to approve.

    <Note>
      Memory notes ship today; only the on-demand **Learn** action (turning a finished task into a skill on command) is on the [roadmap](/cowork/autonomy/self-improvement).
    </Note>
  </Accordion>

  <Accordion title="Improvements" icon="wand-magic-sparkles">
    Skill and memory suggestions proposed by the improvement reviewer and curator, waiting for you to approve, tweak, or dismiss. See [Self-improvement](/cowork/autonomy/self-improvement) for how proposals are generated.
  </Accordion>

  <Accordion title="Activity" icon="clock-rotate-left">
    The worker's run history — every task it has been part of. See [Tasks](/cowork/tasks/overview) for how a task runs.
  </Accordion>
</AccordionGroup>

## Worker status: active or disabled

A worker has one of two statuses:

* **Active** — the normal state. Anyone in the workspace can start a new task with it.
* **Disabled** — a soft-retire. No new tasks can be created under it, but any tasks already running keep going.

A worker is never hard-deleted while it still has tasks — that would kill work other people in the workspace are relying on. If you try to delete a worker that has no tasks at all, it's removed outright. If it has tasks, deleting it instead disables it: the worker stops accepting new work but stays visible, and its existing tasks keep running to completion. For everyone except the task's own owner, a disabled worker and its tasks show up greyed out as a signal that the worker has been retired.

<Tip>
  Disabling is reversible. A disabled worker can be switched back to active at any time by any workspace member — there's no separate approval step.
</Tip>

## Who can create and edit workers

Every workspace member has full access to every worker: anyone can see, create, and edit any worker's instructions, skills, assets, and connections. There's no admin-only tier for worker management in the current release — access to workers isn't gated by role.

The one thing that stays private is a **task**: the conversation and work a person runs with a worker belongs to them alone, regardless of who built or can edit the worker itself. See [Tasks](/cowork/tasks/overview) for how that privacy boundary works.

## Next steps

<CardGroup cols={2}>
  <Card title="Skills" icon="puzzle-piece" href="/cowork/workers/skills">
    See how a worker packages and loads `SKILL.md` capabilities on demand.
  </Card>

  <Card title="Capabilities & connections" icon="plug" href="/cowork/workers/capabilities">
    Attach integrations to a worker through the Connection Manager.
  </Card>

  <Card title="Tasks" icon="list-check" href="/cowork/tasks/overview">
    Learn how a worker's tasks run, and the difference between worker-bound and worker-less tasks.
  </Card>

  <Card title="Quickstart" icon="rocket" href="/cowork/quickstart">
    Create your first worker and run a task end to end.
  </Card>
</CardGroup>
