mainmind Docs
Open app

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
Three Pocket companions: flat, colourful characters with cut-out smiles, Oracle's m in the middle

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

  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.

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.

For your agent

The steps your AI app follows. You don't need to read them.

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 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 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.

For agents: this page as Markdown and every page.