How to Assign a New Hire's First Project with an AI Company Brain

Judge a new hire's first project by the path, not by whether the proposal ships. We recommend a one-page contract that gives the hire one bounded, reversible deliverable for a real internal customer, approved sources, narrow temporary access, a named decision owner and explicit stop conditions, and that counts a correct stop as a result. The company brain retrieves and explains approved context. It never approves a change, grants access or declares the work done, because a fluent plan is not permission, ownership or correctness.

Write the contract first

A request such as "improve the customer handoff" leaves most questions open: which handoff, which procedure is authoritative, whether the hire can see customer records, who decides if the change is right, and what happens when a source conflicts with current practice. A one-page contract settles those before the work starts:

• Outcome: one observable deliverable and the person who needs it.
• Scope: systems, records, teams and time period included or excluded.
• Approved sources: current pages, policies, examples and owners.
• Access: what the employee may read, edit, test or publish.
• Decision owner: the person accountable for accepting the result.
• Checkpoints: moments when work pauses for review.
• Stop conditions: situations in which the employee must stop and escalate.
• Rollback: how drafts, settings, test records or published changes are reversed.
• Completion evidence: what proves the work is ready for handoff.

Every consequential decision needs one owner, even when several people contribute. Store the contract beside the governed sources so the company brain can retrieve both, and keep the source page authoritative: a generated summary must not become a second copy that drifts away from the procedure.

Choose work you can undo

A good first project matters to someone, yet a reasonable mistake stays recoverable. It passes four tests. The hire can finish a meaningful unit in several working days. An identifiable customer, such as a colleague, a manager or a small group, will use the output. The output can be reviewed before it changes production behavior, as a draft checklist, a proposed page revision or a sandbox configuration can. And the team can say how to reverse it. If nobody can describe the undo, shrink the scope or move the work to a test environment, and when the task grows, move the follow-up work into a separate backlog instead of the starter project.

A disposable exercise teaches little about real dependencies, and a live task with broad access makes the hire absorb operational risk before learning the team's review habits. CIPD's induction factsheet says an employee's first impressions of an organization can significantly affect their integration into the team and their job satisfaction. A first project is where those impressions turn into evidence.

Guidance is not authorization

The assistant may explain a procedure, compare approved examples, summarize a source or draft a plan. It must not approve spending, grant access, publish a change, accept risk or declare the project complete. Put that boundary in the workflow, not in a warning inside the prompt:

project_id: onboarding-first-project-042
outcome: revise-support-handoff-checklist
source_set: support-handoff-approved
employee_permissions:
  read: [approved-playbook, sample-redacted-ticket]
  edit: [draft-workspace]
  publish: []
decision_owner: support-operations-lead
checkpoints: [scope-review, draft-review, release-review]
stop_conditions: [restricted-data-request, conflicting-policy, live-system-write]
rollback: delete-draft-and-revoke-temporary-group
completion_evidence: [review-comments-resolved, owner-approval, source-page-updated]

The record makes automation inspectable and stops the assistant from treating a polite "looks good" as approval. Use an explicit approval action tied to the decision owner and the project version.

Kipwise's employee onboarding page shows how assigned reading, searchable company knowledge, and progress tracking can sit in one onboarding flow. Keep project authorization separate from that employee-visible progress. A completed reading task proves that the employee opened or completed the assigned item. It does not prove that a production change is approved.

Sources, access and a temporary group

Answer from the smallest approved source set that supports the project, and let each answer carry the direct link, the owner, the last-reviewed marker when there is one, and an escalation route for missing or contradictory evidence. NIST's Generative AI Profile for its voluntary AI Risk Management Framework is meant to help organizations identify the risks that are unique to generative AI. For a starter project the practical reading is a division of labor: the assistant retrieves and explains approved context, a named person owns the decision, and the organization verifies the result.

If the hire cannot open a source directly, the assistant must not reveal its contents in an answer. Microsoft's document-level access guidance for Azure AI Search advises group access over individual user access for ACL-secured content, for ease of management. That fits this contract: grant the project's access through a temporary group, so that closing the project is one membership removal and the rollback line in the record is true. Test with the hire's real identity, ask one negative question whose answer lives only in a restricted source, and expect a refusal that points to the permitted request path. Ask the denied question again after the group is gone. When the hire hits a missing permission, treat it as a scoping question first: confirm that the source belongs in the project before granting anything, and swap in a permitted example if it does not.

Start the schedule from working access

We recommend counting the project's schedule from the day access passes that allowed-and-denied test, not from the hire's first day. GitLab's onboarding handbook recommends at least two full weeks of onboarding before team-specific onboarding and training begin in week three, and tells new hires they may join their team's work earlier without feeling they must contribute heavily. A deadline that starts on day one with half the access in place measures your provisioning delays, not the hire's work. Tell the hire the date only after the test passes.

Example: a support handoff checklist

Suppose a new operations hire gets this outcome: propose one revision to the checklist used when Sales hands a new customer to Support. The approved source set holds the current handoff policy, a redacted example, the field definitions and the escalation route. The hire can read those pages and edit one draft, but cannot open live customer records or change the published checklist.

At the scope checkpoint the hire finds that the policy requires an owner for every open risk while the checklist has no owner field. The company brain cites the policy and the field definition, and the hire drafts a field, a validation rule and a migration note from the redacted example. At draft review the support operations lead checks the proposal against the source, tests the rule on sample data and decides whether another team must be consulted. If the policy and the actual workflow conflict, work stops and the owner resolves the source before the hire continues. After acceptance, the artifact goes through the normal release path, the temporary access is removed, and any source page the work proved unclear is updated.

We recommend grading the project on the path, and not on whether the proposal ships. Here the project succeeds even if the owner field is rejected, provided the hire found the governed source, named the decision owner, kept customer information out of the draft, tested the change and answered the review. Those are the habits the next ninety days depend on. The same project also shows the team whether its company brain exposed the right context without crossing the access boundary.

Count a correct stop as a result. A hire who halts on a conflicting policy and routes it to the owner did the job, and one who picks the more plausible answer did not. For the same reason, never score a hire by how few questions they ask, because questions expose missing sources, conflicting instructions and unclear ownership. Name a delegate for each checkpoint, since a reviewer's silence is not approval.

Before you assign it

Run the workflow once with a test identity, covering a success and a failure: every approved source found, a restricted one refused, conflicting evidence escalated, edits possible only in the draft target, each checkpoint blocking the next consequential action until the owner approves, and rollback removing the test artifact and the temporary access. Then pick one upcoming hire and one reversible project with a real internal customer, write the contract, and keep it, the sources, the decisions and the final artifact with durable owners outside the chat transcript.