Agentic Workshop
Module 10 · 65 min

Remote sessions, asynchronous routines and final project

Course by Nello Castellano

Working remotely or on a schedule shifts control over time. To remain reliable, the routine must know who owns it, where it holds state, when to stop, and what actions await a human decision.

Lessons

What you will tackle, step by step

10.1

The state of a session

When a session lasts longer than your presence in front of the screen, its state cannot live only in the conversation. If the connection drops or you come back the next day, you have to distinguish what was done, what was only proposed and what never started.

First distinguish the environment: Remote Control continues to run tools on your local machine; a cloud session instead runs on remote infrastructure. In both cases, a recoverable session records inputs, commits or starting snapshots, work done, artifacts, errors and next step.

Assign a human owner and time limit. “Work until you're done” is not a stop condition; “analyze five dependencies and produce a report within thirty minutes” is.

See it in practice · Resume an interrupted review without blindly starting over

A remote session scanned dependencies for twenty minutes and then lost connection. You don't know whether it edited files or just produced a partial report.

  1. Read the checkpoint with run-id, initial commit and phase reached; Don't rely on the last visible message.
  2. Compare the current Git state with the snapshot and identify any modified files or created artifacts.
  3. Check which checks have a recorded outcome and consider those without output or exit code not executed.
  4. Start again from the first incomplete phase with the same limits, or close the session if the repository no longer corresponds to the starting point.

Result: Recovery arises from persistent data. Do not duplicate work already attempted and do not attribute actions to the session that have not left evidence.

10.2

Idempotent schedules

A scheduler can run the same routine more than once, even when you have written "every night". Retries, timeouts, schedule changes, and repeated runs are normal. This is exactly where idempotence helps: the second execution must not create another effect as though it were the first.

A daily routine can start twice due to retry, time change or service error. Use an identifier that includes a logical period and time zone, for example `review-2026-08-08-Asia-Singapore`, and check whether the report for that period already exists before producing another one.

Retries must be limited and spaced. Immediately repeating an operation that fails due to remote unavailability can increase the problem and consume resources without new information.

See it in practice · Avoid creating two reports for the same night

Dependency check starts at 02:00, times out during notification and scheduler relaunches it. The report had already been saved.

  1. Calculate the run-id with date, repository and version of the routine before any writing.
  2. Save the report using that run-id as the key and record the notification status separately.
  3. On retry, detect the existing report and skip parsing and writing; resume only the incomplete notification.
  4. After the maximum number of attempts, keep the error and send a different warning, without regenerating the report.

Result: You get a single learning artifact and a clear trace of delivery attempts. The retry completes what is missing without repeating what has already succeeded.

10.3

Remote control and human checkpoints

Controlling a session from your phone or continuing from your browser changes the channel; it doesn't change the responsibility. A remote button may be convenient, but it does not automatically make the action it initiates safe. Before approving, you still need to understand the state, evidence, and effect.

Channels, remote control, and browser integrations are surfaces for sending instructions or continuing a session. The remote interface doesn't magically transfer filesystems and credentials - it's always the machine or cloud running the tools that matters. Reading a report can be automatic; publishing or modifying external systems requires appropriate permission.

A useful notification contains status, evidence, requested decision and deadline. It should not force the user to reconstruct the entire session to understand whether to approve.

See it in practice · Write a notification that allows a real decision

The routine has prepared a dependency update and asks the remote channel for permission to open a pull request.

  1. Include the run-id, repository, and starting commit, so the user knows exactly which job they are evaluating.
  2. Summarize diffs, tests run and residual risk with verifiable links or artifacts, not with a simple "all ok".
  3. Describe the required effect: create a pull request on a specific branch, without merging and without publishing.
  4. Add expiration and no-response behavior: no action, checkpoint retained, and session closed.

Result: The user can approve or reject from the remote channel without reconstructing the context and without granting broader permission than requested.

10.4

Capstone: full system, not full autonomy

The final project is not meant to show how many tools you can turn on. It shows that you can build an understandable flow even when something fails. A mature system isn't one that does everything by itself: it's one that makes authority, status, and evidence clear at every step.

The final workflow uses stable context, a review skill, a read-only link, local hooks, agents with ownership and a structured pipeline. Each component resolves a specific boundary; no component receives power simply because it exists.

In the end you need to be able to open the report and answer in two minutes: who authorized what? What test did it pass? Where do I start again if the remote service doesn't respond? If you don't know the answer, the workflow isn't ready yet. The delivery separates implemented, verified, and unverified and retains enough evidence to resume.

  1. Create a run-id and save the initial snapshot of the repository.
  2. Load stable context and schedule a routine with stop condition.
  3. Delegate independent analysis with minimal ownership and access.
  4. Apply hooks, JSON Schema validation, lint, and tests as recoverable gates.
  5. Save a checkpoint and ask for approval before any external effects.
  6. Deliver status, tests, limitations, and precise instructions for resuming.
See it in practice · Building the capstone without creating an omnipotent agent

Task Notes needs to add the priority field, update tests, produce a review and prepare a remote delivery without automatically publishing.

  1. Create a snapshot Git, write the target in the stable context and define visible criteria: priority saved, shown and covered by tests.
  2. Use a read-only MCP source for documentation, an Explorer for the map, and separate ownership for parsers and tests.
  3. Apply local hooks to secrets and formatting; then run the pipeline with JSON Schema validation, lint, tests, and a stop at the first failed gate.
  4. Save the report and checkpoint. Ask for approval only to create a pull request; leave merge and deployment outside the flow's authority.

Result: The project produces code and evidence, but above all a readable chain of decisions. Another person can understand what happened, repeat the checks and resume without relying on the memory of the session.

Guided example

Nightly review without auto-merge

Task Notes checks dependencies every night but keeps the last decision to the user.

Trigger: 02:00, run-id = date + repository
Read: dependencies and advisories, read-only
Analyze: no more than 5 updates
Checkpoint: save report and log
Notify: risk, evidence, decision required
Gate: no branch, push, or merge without approval