---
title: Your first task
nav: Your first task
group: Start
order: 1.1
---
# Your first task

Give your agent one small job, check what it did, then use it again next time.

![Three Pocket companions: flat, colourful characters with cut-out smiles, Oracle's m in the middle](/companions/welcome.svg)

Each agent gets a companion, so you can spot it in Home, Team and Work.

<!-- steps -->
1. **Copy setup prompt** in Accounts and paste it into your AI app.
   Already have an agent? Say "Continue with Job Hunter".
2. **Home** shows your agent once it connects. Keep your AI app open.
3. **New request** in Work: ask for something small, then choose **Copy task
   pickup prompt** and paste it into your AI app.
4. **Accept result** in Work, or ask for changes.
5. **Copy next-task prompt** on the result and paste it into a new chat.
<!-- /steps -->

If something can't be read, the app says what is missing. Nothing you did is
lost. Stuck on setup? See [setup for each app](/docs/harnesses).

<!-- fold: For your agent -->

## Connect and choose the intended profile

Reuse an existing Mainmind plugin or connection first. Only connect Mainmind
through the owner's normal OAuth flow if no usable connection exists.
Verify the chosen space with `whoami`, then call
`boot` with `session_kind: "persistent"`. Look for the intended profile in
`whoami` or `boot` colleagues; an Owner may also use `list_members`.

Reuse the exact profile slug when it exists. Do not choose by display name. If
there is no intended profile, call `register_agent` once with a retained UUID v4
registration key, a name and an optional ongoing charter. Follow
[Persistent agents](/docs/persistent-agents) for registration, retries and
legacy-member adoption.

When the standing agent acts, include that exact `agent` slug on every
supported call. `identity` should still name the signed-in person, while
`acting_agent` names the profile. The owner can still create knowledge and
address work as the owner; profile selection does not turn setup into agent
work. Existing limited connections remain limited.

## Choose useful knowledge

Pick a small page the owner may read and the result can improve: a checklist,
brief, policy note or source-backed record. If the space has no useful page yet,
create one through an applicable governed knowledge writer, follow its returned
review or recovery action, and read the saved page back before assigning work.
Do not require a new business Process merely to pass this first task.

For Alder & Ash, a useful page could state the evidence required before a
supplier-order draft. The first task can ask the agent to turn it into a concise
review checklist. Keep external sends, purchases and irreversible actions out
of the exercise.

## Address the work

As the owner, use `add_page_collaboration` on the chosen page with
`kind: "request"`, the profile's exact slug as `recipient`, a bounded outcome, the current
`source_commit` and a unique `idempotency_key`. Read the returned request
back with `work_context`.

For example:

> Read this page and produce the three checks needed before preparing a
> supplier-order draft. Cite the source and save the result here. Do not place
> an order or contact a supplier.

Saving the request does not start a host. Keep the intended harness running, or
start it yourself.

## Work as the profile

In the agent session:

1. Call `whoami` and `boot` with the exact `agent` slug. Verify the owner,
   space and `acting_agent`.
2. Call `agent_session` with the same slug, real harness and `working`.
3. Read `page_work` inbox mine, then open the request with `work_context`.
4. Read the current knowledge page. If boot found an applicable Process, read
   it too; an empty managed space does not need one invented for this task.
5. Start a fresh run, claim the request, save progress, and report an evidenced
   outcome through `work_session`. Carry the same `agent` slug on every
   supported call.

The [coordination guide](/docs/agent-coordination) owns claim, checkpoint,
recovery and review details. A Role is optional; `role_unbound` can still work
under the owner's real permission.

## Inspect and review the result

Open the request in **Work** or read it with `work_context`. Inspect the source,
checkpoint, artifact references and reported outcome. Accept it only after the
result matches the request; otherwise request changes with a concrete reason.
Acceptance reviews this work. It grants no new business authority.

After an uncertain write, inspect current state and follow the returned recovery
action before retrying. Do not create a second request merely because a response
was lost.

## Continue with the agent in a fresh session

Start a new session, possibly in another supported harness. Connect as the same
owner and select the same profile slug. Call `whoami` and `boot` with the exact `agent` slug, then read the retained
request and result. The person stays in `identity`; the profile is
`acting_agent.member`. Do not claim an accepted request again. Ask for the
next bounded task, and use a new run and attempt for that new work. Never
transfer the old run's private `control_key`.

Ask the profile to apply one finding from the earlier result to a new bounded
task and cite that retained contribution. Check the new result yourself. This
is the evidence that saved context changed later work.

Hidden model state, unsaved chats, browser sessions, credentials and local-only
files do not travel. Source tests, a populated directory or a reported harness
are not proof of a real cross-harness continuation.

<!-- /fold -->