---
name: onboard-agent-for-first-scoped-task
description: A new AI worker needs the same clear brief as a new teammate.
category: Knowledge System Maintenance
stage: —
definitive_article: https://blitzmetrics.com/new-agents-start-here/
status: needs-work
---

# Onboard an agent for its first scoped task

A new AI worker needs the same clear brief as a new teammate. This guide helps it find the right rules and do one useful job. Start with the team’s current notes, client status, and task.

**The path:** Operating context → Client state → Scoped claim → Checked first task

**Start when:** A new or returning AI worker needs current context before its first assigned task.

## Inputs

- The private START HERE, current client roster and live work-state location.
- One assigned task, its goal, sources, intended audience and authority.
- Canonical skills and verified access to the files needed for this task.

## Steps

1. Read the public onboarding guide, private START HERE and current operating instructions. Verify which sources own methods, client status, live tasks and credentials.
2. Before client/site work, check the actual roster: Active Client, Special Project or Not Active. Stop Not Active work. Billing, an old project title or a missing invoice does not set the status; never delete a roster row to resolve uncertainty.
3. Choose the current canonical task and record its revision. Read only relevant client context. Explain [Goals, Content and Targeting](https://blitzmetrics.com/gct-business-strategy/) in plain terms: result, material and people this work serves.
4. Inspect task claims and claim the exact write targets using the shared mechanism. Coordinate overlaps. Read-only orientation needs no competing write claim.
5. Perform one bounded authorized task using the real source systems. If a capability is missing, retain the exact gap and continue independent safe work; do not infer permission from a connection.
6. Verify the output where it was saved or delivered. Record draft/public, pass/fail and unresolved checks separately, including the next owner.
7. Write the execution’s meta record plus any required private team note. Update the checkpoint and hand off remaining work without copying private client data into public instructions.

## Definition of done (QA checklist)

[Quality assurance (QA)](https://localservicespotlight.com/article-guidelines/) means checking the work against the agreed result.

- [ ] Current context, roster state and exact task source are checked.
- [ ] No competing writes or unauthorized scope are introduced.
- [ ] First result and handoff are independently inspectable, with blockers preserved.

## Example(s)

**Fictional teaching example. This is not a client result or proof of a completed run.**

A fictional new worker finds a website task under an old paying-client project, but the roster says Not Active. It stops the site work and records the mismatch for the relationship owner. That is a correctly blocked onboarding run, not a failed reason to invent another status.

## Handoff and Content Factory context

This work supports the [Content Factory, our four stages of using real content](https://blitzmetrics.com/content-factory/): Produce → Process → Post → Promote. Use the specific inputs and next task below to place the work; a maintenance task does not manufacture transcripts, clips or other stage outputs it does not call for.

The task owner receives the result in the actual project. Use [the shared-memory handoff](https://local-service-spotlight.github.io/task-library/?task=coordinate-agents-with-shared-memory#task-coordinate-agents-with-shared-memory) for the next worker and the original thread for authorized updates.

## Run with an agent

Give the AI worker this recipe, the real Inputs above, the intended result and the actions already authorized. Ask it to return the saved output, checks, evidence and remaining owner. Check its work against this guide; loading a skill does not prove access, installation of a job, or successful execution. Keep media muted with volume at zero if playback is needed.

For recurring work, keep the actual trigger, owner and runtime in the job record. Scheduling and observed firings are separate. Do not create a schedule merely because this guide mentions a review interval.

## Record the real execution

Open the run record when the work starts. Keep the exact starting recipe revision, one execution ID, source evidence and actual state. Write a [meta article, the record of one run](https://blitzmetrics.com/meta-article-prompt/) with decisions, results, checks, failures and next owner. Link it to this task and register it through the [Task Library](https://local-service-spotlight.github.io/task-library/) execution process. Writing is part of the work; public release follows existing authority.

Reuse the same execution ID for revisions, QA, meta writing and retries within that run. A blocked run stays open with its dependency and next owner; do not invent a finish time. Use supported findings to propose and verify a better recipe. A historical public-example count without distinct run IDs remains dated article volume, not verified execution frequency.


<!-- factory-layer:start -->

## Factory chain (do not treat this as isolated)

- **Phase:** —
- **Importance:** 2/5 `●●○○○` — frequency 2, revenue 1, gating 2 (supporting)
- **Suggested previous station:** —
- **Suggested next station:** —
These stations are generated neighbors, not verified prerequisites or handoffs. Follow the task’s actual Inputs and Handoff sections.
- **Handoff:** Save this task’s actual output, source, date and checks where the receiving owner can read them. Follow the Inputs and Handoff sections for its next step.

## Model routing (same factory, any engine)

- **This task's lane:** `any` — Any capable chat model (Claude, ChatGPT, Grok, Gemini). SOP following, drafts, checklists.
- **Single-engine path:** Use the capable AI app you already have. Check its required tools and access before starting. Pass the actual result and proof to the next task.
- **Optional multi-engine:** A tested local model may draft; a stronger model may review facts and voice. Use supported tools for approved actions. Pick models from observed quality and cost; a model name does not prove it can run this task.
- **Never** store the working state in one vendor's memory. Files in the Content Library are the bridge.

<!-- factory-layer:end -->
## Definitive article & links

- [Maintained source guide](https://blitzmetrics.com/new-agents-start-here/)
- [This task in the Task Library](https://local-service-spotlight.github.io/task-library/?task=onboard-agent-for-first-scoped-task#task-onboard-agent-for-first-scoped-task)
- [Article Guidelines](https://localservicespotlight.com/article-guidelines/)
- [current article guide](https://blitzmetrics.com/definitive-article-guide/)
- [How recipes and run records work together](https://localservicespotlight.com/meta-articles/)

## Review and evidence still needed

The inherited contributor status is `needs-work`. It is preserved, not promoted by this rewrite. That label alone does not verify document readiness, a client outcome, access or an executed task.

A real execution still needs its own source, reviewer, saved result and handoff evidence. The fictional example teaches the method; a real example with relevant proof is still needed where required. The task-specific flow above is source guidance; its visible presentation and the full document need a named reviewer and desktop/mobile checks.