Your first AI-native practice

Try the work.
Make it your own.

Start with an example. Make a decision, explain your thinking, and improve it. Then see what changes when the situation does.

Four roles. One fictional mission. No account required.

Forward-deployed engineer / 15-minute practice

Leave a workflow someone can operate.

Design a bounded rollout and a recovery handoff that fits the customer's actual constraints.

You will create Pilot runbook + ownership handoff

Step 1 of 6 · Example

The builder's access is not the operator's access.

In this fictional rehearsal, a builder can read every support source. The receiving operator cannot open a restricted knowledge folder.

Observe
Run the workflow with the operator's permissions. A successful builder demonstration does not establish operator readiness.
Bound
Use only approved sources available to the operator, define a human escalation path, and keep automatic account changes disabled.
Transfer
Have the operator rehearse a failed request and recover from the runbook without the builder supplying missing steps.

The handoff succeeds when the receiver can operate and recover the workflow within their own authority.

Use this as a written practice worksheet

The step-by-step editor needs JavaScript. You can still use this complete exercise: write an attempt and explanation, compare it with the rubric, revise, then answer the fresh challenge in your own document.

The assistant works. The customer cannot recover it.

The fictional support assistant can draft routine replies in a sandbox. The receiving team has not rehearsed a failed source lookup, and nobody has agreed who can pause the pilot.

Only a small group of internal operators is proposed for the pilot.
Operators approve replies; automatic account actions remain disabled.
Source access and a named recovery owner are prerequisites.

Specify who can use it, permitted actions, stop conditions, receiver, and recovery steps.

How would you demonstrate that the receiving operator can recover without you?

Rehearse failure and recovery with the owner: Name the pause authority and verify the runbook before exposing the pilot.
Scripted guidance for this choice
This tests the missing operating capability. Your handoff still needs the pilot boundary, signals to stop, a named receiving role, and a recovery sequence they can execute.
Send a recording of the happy path: Ask the team to contact the builder if something fails.
Scripted guidance for this choice
A recording does not establish independent recovery. Name who owns failures and have that person use the runbook on a seeded problem.
Give every operator the builder's access: Remove permission differences to make the demo work.
Scripted guidance for this choice
Broadening access to fit a demonstration ignores the customer's real boundary. Design and test within approved permissions instead.

Review criteria

A bounded pilot: Are participants, approved sources, permissions, and allowed actions explicit?
Internal support operators only; approved knowledge; human-approved replies; no automatic account changes.
A recovery someone can follow: Are the stop signal, pause authority, escalation receiver, and restart conditions specified?
On source failure, pause assistance, use the manual queue, notify the support owner, and resume only after the failure check passes.
A tested handoff: Does the receiver perform a failure rehearsal using their own permissions and the written runbook?
Seed a missing source, watch the operator recover, and revise any step that needed the builder's explanation.

Revise your attempt

Rewrite the handoff so an operator knows what to do when the source fails. Include authority and recovery, not just the happy path.

The receiving team changes its operating hours.

The support owner now covers only daytime requests, while the assistant is configured to accept requests overnight. Nobody owns the out-of-hours escalation queue.

No substitute owner or out-of-hours support commitment exists.
The system can be limited to supported hours and fall back to the existing manual process.

What changes in availability, escalation, user expectations, and the recovery rehearsal?

Explain how the new constraints change your rollout.

Align availability with real operating coverage: Limit the pilot and make the off-hours fallback explicit until ownership is agreed.
Scripted guidance for this choice
The system boundary must match the operating model. Update hours, user expectations, escalation routing, and the rehearsal rather than implying support that does not exist.
Keep it available and queue failures: Assume the owner will catch up in the morning.
Scripted guidance for this choice
Queuing silently creates an unsupported operating promise. Name acceptable response expectations and a real fallback before accepting those requests.
Make another agent the escalation owner: Let an AI agent resolve cases without an accountable person.
Scripted guidance for this choice
Another model does not supply missing human authority or coverage. Preserve the handoff boundary until an accountable operating arrangement exists.

Give the runbook to a teammate playing the operator. Observe their recovery attempt and fix the first step where they need you.

Looking for a technical release decision?

Open the engineering release exercise

The builder's access is not the operator's access.

Observe

Bound

Transfer