I wanted an agent that could figure out how to solve a task, not just follow a script I had already written. So I built a reusable harness that gives it freedom to inspect inputs, write code, and test an approach inside a controlled sandbox. The goal is reusable solutions, with evidence that the work is actually complete.

How the loop works

The agent first loads a skill: the task knowledge, tools, and rules its output must satisfy. It chooses an approach, writes a script, and runs it in the sandbox. The host checks the result. If it fails, the agent can use that feedback to revise its solution and try again. Once the output passes, the host saves it and checks what was actually stored before calling the task done.

I implemented this using Google ADK as the framework. The recorded run uses GPT-5.6 Terra. The harness is designed to be model-agnostic: task knowledge and model choice can change without redefining the host's execution and acceptance boundaries.

From a listing page to usable records

The task: extract all 20 jobs from the test page, capturing each job’s title, company, location and URL. Validate and save all 20 records, then independently read them back to verify the stored values. Here is one expected record.

What the agent sees

One listing · recreated from the source fixture

Switch Supply Pty Ltd

AI Developer/Engineer (Consultant) | Python, LLM, NLP

Remote Ho Chi Minh - Da Nang - Ha Noi

What it must produce

Expected record · four required fields

{
  "title": "AI Developer/Engineer (Consultant) | Python, LLM, NLP",
  "company_name": "Switch Supply Pty Ltd",
  "location_raw": "Remote Ho Chi Minh - Da Nang - Ha Noi",
  "job_url": "https://itviec.com/it-jobs/ai-developer-engineer-consultant-python-llm-nlp-switch-supply-pty-ltd-2549"
}

Expected-output example, not recovered agent output. The card is a readable reconstruction, not a screenshot. The agent must repeat this for every listing; the host then validates, saves, and independently verifies the results.

A walkthrough of the actual run

Watch the loop produce verified results

Follow the task, a rejected URL, the agent’s correction, and the actual saved records. This captioned walkthrough uses screenshots from the retained ADK session.

An edited screenshot walkthrough of an actual run, not live screen footage. Watch the agent correct a rejected URL, then deliver 20 validated, saved and independently verified records from a fixed test page.
What to watch for
  1. The generic agent discovers and loads the job-extraction skill.
  2. The skill introduces task-scoped tools and the acceptance contract.
  3. Generated extraction code runs inside the isolated workspace.
  4. The host validates, persists, and rereads the accepted records.

What makes the harness reusable

I separated the machinery for running and checking work from the knowledge needed to solve a particular task. Skills, task adapters, and allowed tools provide that knowledge. The harness keeps responsibility for the sandbox and for deciding whether the result meets the task's acceptance contract.

01 Load the task skill
02 Choose and build an approach
03 Run inside the sandbox
04 Validate; revise if needed
05 Save accepted results
06 Independently verify storage

This is the boundary I designed for reuse: change the task-specific knowledge, while keeping the same way of executing, checking, and completing the work.

Next: improvement across tasks Reconcile new approaches with what already works.
01 A new task variant appears
02 The agent can propose and test a new approach
03 The host can validate the evidence
04 The agent could reconcile new and existing approaches into a more generalizable skill or adapter

Beyond completing one run, I want the agent to improve its reusable task knowledge. When a new variant needs a different approach, it would reconcile that approach with existing solutions and test the combined skill against previous cases. Host review and versioning would decide what future runs inherit.

That continuous improvement loop is the next design layer, not something this recording demonstrates. The ambition is a reliable, reusable, and secure workflow across tasks—not a growing collection of one-off scripts.

What the recorded run demonstrates

After correcting the URLs, the successful run completed the chain I wanted the host to own: all 20 visible cards were extracted, 20 accepted records were written, and all 20 stored rows were reopened and compared field by field.

20 extracted records validated
20 accepted records persisted
20 stored rows reread and verified
Host-written run manifest Accepted
Target before run
preexisting_source_rows: 0
Fixture integrity
Served-page hash matched the pinned fixture hash
Accepted writes
written_count: 20
Stored verification
stored_verified_count: 20
Open the sanitized recorded-run manifest →
The boundary of the claim

This run demonstrates one frozen synthetic layout modeled on a job listing. This walkthrough includes a URL repair before the output passes validation. Broader task coverage and cross-run skill evolution still need their own demonstrations.

The problems I’ll unpack next

This preview shows the finished loop. The next articles will slow down and explain the failures, tradeoffs, and implementation decisions behind it.

Part 2 · Planned When hidden contracts break the repair loop

The required-versus-actual mismatch, why an earlier run stopped, and how I moved validator-owned rules into the loaded skill.

Part 3 · Planned Why the host owns “done”

Sandboxing generated code, deterministic acceptance, persistence gates, and a fresh stored-state reread.

Part 4 · Planned How the solution layer evolves across tasks

Turning accepted approaches into versioned task knowledge, then testing whether those updates generalize without weakening the host gates.

Recorded scope

Recorded run
September 14, 2026
Runtime
Google ADK
Recorded model
GPT-5.6 Terra
Implementation
be0e7f2e980e4f8420fe83a4d569bccb15c0d9de
Experiment
One frozen synthetic layout modeled on a job listing