This is an independent lesson on the supplied topic. It uses the T3 Code team's public documentation as a concrete reference, while all Patch Desk examples and recommendations are original. It does not claim access to Theo's course recordings.
Learning goals
- Trace an agent task from user instruction to tool result and reviewable artifact.
- Diagnose failures at the model, harness, interface, and environment layers.
- Design a team workflow that makes ownership and permissions visible.
Theo's harness explainer follows a tool request through execution and back into the next model input. The trace in this lesson makes that publicly described loop inspectable. Automatic captions, around 8:20–10:20.
Follow the work through the layers
An agent task begins with an intended outcome. The interface collects the request and may show files, messages, and proposed actions. The harness assembles inputs for the model, receives action requests, executes permitted tools, and supplies their results to later model calls. The environment supplies the actual files, commands, network access, and credentials. A final answer is only one output of that process; the changed artifact is another.
T3 Code's public README presents the application as a control surface for agent providers already installed on the user's machine. That gives us a useful example: the control surface and the underlying provider are separate concerns. A mobile interface can make a task easier to supervise without changing which shell commands exist on the machine doing the work.
For Patch Desk, draw a simple trace in your notes: request, files read, model proposal, tool action, tool result, changed files, verification result, final report. You do not need access to private reasoning to inspect these observable events. If a step has no evidence, mark it as unknown. This trace is the basis for debugging a tool-using system.
Permissions shape actual autonomy
Autonomy has several dimensions. An agent may choose which files to inspect but still need approval to write. It may edit locally but lack authority to publish. It may run a check but be unable to reach a network resource. Do not compress these differences into a single label such as “fully automatic.”
The T3 Code permission guide describes its modes and approval behavior. Those details belong to that product and version, not to every harness. Before a real task, inspect the actual settings and test the specific action you need. A remembered mode name does not prove what a current process can do.
In our original Patch Desk workflow, the agent can read and edit the documentation checkout, run the local documentation check, and prepare a diff. Publication uses a separate authorized step. This boundary fits the task: local edits are easy to inspect and reverse, while publishing changes what other people receive. The agent's instructions should describe the same boundary that the runtime enforces.
When an action is denied, interpret the denial as evidence. Do not repeatedly reformulate the same prohibited command in the hope of slipping through. Determine whether the task needs a different supported operation, a missing dependency, or an explicit authorization. A useful report states the attempted operation and its result without exposing credentials.
Interfaces are part of the workflow
An interface affects what people can notice and control. Can you see which repository and branch the task uses? Can you inspect the diff before publishing? Does a progress message distinguish an attempt from success? Can you stop the task without losing the evidence it already produced?
For a documentation repair, showing twenty terminal events may be less helpful than showing the one changed paragraph and the relevant check result. The terminal evidence still matters; it should remain available when needed. Design the summary around the decision the reviewer must make, with a clear route to the supporting detail.
This is also a product issue. Patch Desk succeeds when a maintainer can trust and review a correction quickly, not when the interface displays the largest number of agent actions. Adding more simultaneous tasks can make the experience worse if it becomes unclear which result belongs to which request. Tool capability and usable workflow are different evaluation targets.
Teamwork requires separate workspaces and one owner
If two people or agents edit the same working files concurrently, their changes can interfere. Git's worktree documentation explains how multiple working trees can share one repository. A separate working tree can isolate working files for a task, but it does not automatically merge incompatible design decisions or isolate external databases.
In our example, one task repairs validation instructions and another updates screenshots. Each gets a separate branch and working tree. The first task owns command text; the second owns image assets. A reviewer still needs to check whether both touch the same guide. Isolation reduces accidental overwrites; ownership resolves intentional overlap.
Worked example: diagnose a misleading failure
Patch Desk reports, “The documentation check failed because Node was not found.” Treat this as an environment failure, not proof the documentation edit is wrong. Inspect the command and output, then determine whether the correct runtime is available through the project's documented setup.
Use this original diagnostic record:
Task: correct validation instructions
Artifact: docs/contributing.md, one command changed
Attempted check: npm run check
Observed result: executable unavailable in this environment
What this proves: the check did not run
What remains: validate in a prepared runtime before publishingA weak response claims the patch passed anyway because the edit looks obvious. Another weak response rewrites the checker to avoid needing Node. The first invents evidence; the second expands the task and changes the product to fit a broken environment. The stronger response repairs setup through the supported path, reruns the original check, and records the new result.
Now suppose the check runs but finds a broken local link. That is a different layer: the environment worked and the checker found a content issue. The same “failed” label hides two different causes, so retain the concrete observation.
Practice
Run one small agent task and produce an observable trace with the repository, branch, allowed operations, files changed, command attempted, result, and next decision. Introduce a harmless failure in a disposable copy, such as an intentionally missing local link. Confirm that the report identifies it as a content failure.
Your work passes when another person can explain which layer failed and reproduce the relevant observation. The report must not equate an edited file with a published update, or a launched command with a passing check. A strong answer also identifies one interface improvement that would make this distinction easier for the next user.
Check your understanding
- Does a polished control surface guarantee a capable runtime? No. The underlying environment and provider still determine available actions.
- Does a separate worktree isolate a shared external database? No. It isolates working files, not every external resource.
- What evidence is needed for “check passed”? The relevant command must actually complete successfully against the intended artifact.