Studio: capture and read your own session
Learning objectives
Explain the loop behind one real coding-agent session (LO1), separating observed behavior from inference and changing your decision when verification supplies new evidence (LO9). This studio supplies material for A1, due this week.
Work individually. A peer or the instructor may challenge a citation; the task, capture and explanation remain your own. Bring your course-provided coding agent, a terminal and a keyboard-accessible editor. All records and checks are plain text. Use the safety practices in Tools and model access.
Minimal example
This task is course-constructed. The candidate below looks plausible and handles unpadded status strings. Generate: propose a whitespace repair from the written contract. Verify: run the untouched check first to expose the missing behavior, then rerun it after the candidate changes. Keep both observations.
Hands-on exercise
Prepare a fresh draft directory
Run these ordinary commands from the course root. They create only public synthetic files; no installation or third-party sign-in is required by the task.
mkdir week01-studio
cat > week01-studio/status_label.py <<'PY'
def status_label(raw):
return {"ok": "passed", "fail": "failed"}.get(raw.lower(), "unknown")
PY
cat > week01-studio/check_status.py <<'PY'
from status_label import status_label
cases = [("ok", "passed"), (" OK ", "passed"),
("\tfAiL\n", "failed"), ("cancelled", "unknown")]
for raw, expected in cases:
assert status_label(raw) == expected, (raw, expected, status_label(raw))
print("PASS: four status cases")
PY
python3 week01-studio/check_status.py
Expected baseline: a nonzero exit and an assertion identifying " OK " with
expected passed and actual unknown. This is the forced failure to preserve in
your agent session, rather than a requirement to cause unpredictable model failure.
Capture one real session
Before launching the agent in week01-studio, write your prediction: first tool,
what the failed check will return, what recovery you expect, and what ends the loop.
Choose a dedicated directory or container without employer or cloud credentials.
Never put a key in a prompt, repository, screenshot or recording.
Start the agent with its supplied seat or credit. Use its session export or visible transcript feature; check that you can save the record before beginning. Give it:
Work only in this draft directory. For string statuses, ignore surrounding whitespace and ASCII letter case; map ok to passed, fail to failed and everything else to unknown. First run python3 check_status.py and retain its failing output. Repair status_label.py without changing check_status.py. Run the same check again, then explain what you changed and what the result covers.
Read any proposed command before approving execution. Keep the baseline failure
inside the capture, including command, exit status and output. Export the session
in its supported format to your private evidence directory. If export is unavailable,
copy the visible messages in order into session.txt, retaining role labels and
call/result identifiers when shown. Record agent name, version, date and task.
Exclude credentials and private data from any excerpts you submit.
Read and revise
| Studio segment | Action | Evidence |
|---|---|---|
| Opening | Prepare files and save predictions before generation | Task and unchanged prediction |
| Capture | Agent runs the failing check, repairs, checks again | Original session and both results |
| Dissection | Read calls/results and inspect visible request fields | Table below with citations |
| Verification checkpoint | Run the check yourself and inspect the changed file | Current result and bounded diff |
| Revision | Peer or instructor challenges one citation; revise it | Corrected claim and decision line |
At the midpoint of the session, ask for help if recording or the first check is blocked. Continue the text participation exercise while access is restored; keep missing real-run evidence explicitly missing.
Make one row per visible request or event:
| Location | Instruction/context visible | Tools/call arguments | Returned result | Continue or stop | Observed claim | Inference and a possible check |
|---|---|---|---|---|---|---|
Identify system/developer messages and the tool list if your capture exposes them. If it exposes only chat and tool actions, say that the full request was unavailable. Do not treat a published prompt file as proof that your session sent it. Match each result to its call, inspect recovery after the forced failure, and find the check that supports the final message. Count requests separately from tool calls.
Practice with the read-only viewer and the supplied hand-authored record:
python3 lectures/week-02/session/show_session.py \
lectures/week-02/session/sample-session.jsonl --request 4
A native export can be read directly as text. Use the viewer on your own export only if it uses its supported course-session or course-trajectory format. Do not invent a header or fabricate hidden request fields to make another format fit.
Verification
From the course root, verify the candidate in the actual studio directory:
python3 week01-studio/check_status.py
Expected after repair: zero exit and PASS: four status cases. Confirm the check
file is unchanged and the candidate only normalizes input before lookup. A passing
result covers these cases; it is not proof for all strings or callers.
For the separate live-loop exercise, use the completed draft controller:
PYTHONPATH="$PWD/scripts" python3 week01-loop/verify_loop.py
The original lectures/week-02/fixture/loop.py is an unfinished starter. Checking it
would not test your repaired studio candidate or your copied controller.
Keep the work, verification and brief explanation in A1. Include one AI-use note, label each behavior observed or inferred, and end with accept, narrow, re-check or stop plus supporting evidence. No unrelated session history is required.
Common mistakes
| Mistake | How to notice it | Correction |
|---|---|---|
| Only saving the successful run | No forced failure in the session | Capture the baseline before repair |
| Checking the wrong directory | Command targets the original fixture | Check the candidate you actually changed |
| Claiming hidden instructions were seen | Export omits system messages | State the visibility limit |
| Citing a final claim as a tool result | No command, call ID or result at the citation | Find the corresponding observation |
| Letting the agent weaken the check | Check file changed | Restore it, inspect the candidate and rerun |
| Relabelling an inference as observed | Citation does not contain the claim | Change the label or obtain another observation |
Text participation
If capture is unavailable, dissect the sample with the same table. Its header says
course-made-sample: it is practice evidence, not your real agent session. Predict
recovery after the failed edit, reveal the next request, and revise your explanation.
Complete the real capture through supported access later; preserve any missing
observation rather than inventing it.