A recurring task is a starting point. Before turning it into an agent loop, someone still has to decide what the agent can change, what proves it worked, and when it stops.
That was the job of Loop Lab, the companion exercise used in my Build Your First Agent Loop workshop with Vonage and TechWalk at Fabrik DUMBO. The exercise walked participants through eight decisions, with a completed contract and one small manual pilot as the intended finish line.
This is a workshop case study. The public event record and participant account establish the teaching context; the downloadable worksheet lets you inspect the exercise. They don't establish company-wide adoption or measured business savings.
Start with a task that can survive a check
The organizer's event listing describes the hands-on session and names me as the featured speaker. The preparation was concrete: bring a recurring task, a laptop with Claude Code ready, and an empty folder for the first run.
Loop Lab itself ran in a browser without an account. That gave people a way to design the work before they needed a coding tool. Someone could arrive with a rough task and still work on the central questions: which inputs are allowed, which result matters, and who decides whether it's good enough.
The first decision was whether a loop belonged there at all. A task should repeat, leave enough time for a check, and produce a result that can be verified independently. If a person is waiting for an immediate answer, a bounded workflow is often a better fit. If nobody can describe a reliable check, a person may need to own the decision.
Those alternatives were part of the exercise. Choosing a smaller fixed workflow was a useful result, even if the participant arrived wanting an autonomous agent.
Eight fields turn an idea into a contract
The original loop contract worksheet is available as Markdown. It's the companion material used for the workshop, including the starter prompt for a manual Claude Code pilot.
| Field | Decision it makes visible |
|---|---|
| Job | The outcome one run should produce |
| Trigger | The event or person that starts a run |
| Evidence | The permitted inputs and authoritative source |
| Action and authority | What the agent may change and what needs approval |
| Budget | Limits on attempts, time, tool calls, or spend |
| Verifier | The independent check against the result |
| Artifact and state | What gets saved for a person or the next run |
| Stop + human line | Success, exhaustion, uncertainty, and the approval owner |
These fields make different decisions. A budget can stop a run that's taking too long, but it can't tell you whether the answer is correct. A saved report can show what happened, but it doesn't grant permission to publish a change.
The contract puts those distinctions next to each other. A partner can read it and spot a missing approval point or an undefined check without having to understand the implementation first.
The worked example separates review from permission
The worksheet uses completed support calls as an illustrative example. This is teaching material, not a report of a deployed customer system.
The proposed job is to find missing intake fields that caused avoidable transfers. The inputs include redacted transcripts, completed-call events, the current intake schema, and an approved escalation policy. The agent may classify failures and draft a proposed schema change. Publishing that change stays with a support lead.
The example also sets a budget: at most 50 calls, one retry for a failed download, and a 15-minute runtime. Those numbers define the exercise's boundaries. They're starting assumptions to revise for a real workflow, not recommended limits for every support team.
Success is checked against a reviewed test set. The saved artifacts include a dated report, a proposed JSON change, the source version, and the before-and-after score. Conflicting evidence is a reason to stop and ask for review.
That makes the handoff inspectable. A reviewer can trace a proposed change back to the evidence, rerun the check, and decide whether the change belongs in the live system. The agent's confidence doesn't settle any of those questions.
The interface helps people pressure-test the plan
The browser exercise offered presets alongside the eight editable fields. Participants could start from an example, replace its assumptions with their own task, and export the contract as Markdown. A separate starter prompt carried the contract into a coding tool.
The interface's completeness feedback helped people notice missing fields. It wasn't a test of the proposed agent. A complete plan could still contain a weak verifier or permission to do too much. That is why the attendee guide paired the interface with three questions for a partner: what proves it worked, what makes it stop, and what can it change?
The next instruction was to make the first version smaller once. That might mean reviewing one kind of input, removing a write permission, or choosing a manual trigger. The useful edit depended on what the partner found.
Then came one manual run in a new folder. The starter prompt explicitly excluded scheduling, background services, credentials, and production writes. It asked for a small input, an expected output, a visible independent check, and a human-readable report.
A participant described a specific change
In a public post about attending the workshop, Audrey Schroder described using the eight-part exercise to review a Gumloop agent she had already built. She reported adding a verifier and a clearer stop condition afterward.
That's a useful, narrow outcome: a participant identified missing controls in an existing workflow and described changing them. Her account doesn't provide a before-and-after benchmark or an independently inspected production run, so this case study doesn't attach a productivity percentage to it.
The teaching aim was similarly concrete. A participant should be able to point to the source, show the check, and explain which decision still belongs to a person. The intended finish line in the attendee guide was a completed contract plus one manual run with a visible verifier result and a report. It's a finish line for the exercise, not a claim that every attendee completed it.
Keep the receipt before adding the schedule
The follow-through in the attendee guide was to run the pilot manually at least twice more and keep all three receipts. Compare the verifier result, the human decision, and the point where the budget or stop condition fired.
The next improvement might be a better test case or a narrower input set. Scheduling should come after the manual path is understood. Otherwise the schedule mainly helps an unclear workflow repeat more often.
This is also where a team needs a broader measurement plan. The workflow measurement card covers time to a usable result, quality, review effort, and safety. It includes a blank template and a separately labeled synthetic example. That card extends this write-up; it wasn't part of the original workshop material.
For the measurement method, read How to Measure AI Adoption Without Inventing ROI. For preparing team inputs and approvals, see How to Run Safe AI Labs on Real Team Work.
Try the exercise on one piece of work
Download the workshop contract, choose a recurring task, and fill in the eight fields. Ask someone who reviews that work to challenge the verifier and the authority boundary before you build.
If the task passes the suitability check, the worksheet's starter prompt can help you scope one manual pilot. Keep the input small enough that a person can inspect the whole result. Find the report and the independent check before expanding what the agent can do.
The same separation appears in my Vonage Developer Blog article on voice AI: keep the live conversation responsive, then give slower review work its own evidence and limits.
For a team version built around your work, the AI enablement workshops cover the preparation, lab formats, and follow-through. More build notes and teaching examples are on Writing.