# The Agent That Could Fix the Code but Couldn't Finish the Job

By ayobamih

Canonical: https://aiworkaccountability.com/writing/the-agent-that-could-fix-the-code-but-couldnt-finish-the-job/
Published: 2026-11-01
Updated: 2026-11-01

*Engineering case study · 31 October–1 November 2026 · An original failure followed by a verified recovery*

An AI-assisted engineer can fix code, pass tests, identify the next deployment step and still fail to deliver what the user authorised. That happened in my Tail Wagging Websites production release. The outcome the user needed was a live portfolio verified against the exact merged code—not another passing CI job or another explanation of why deployment was blocked.

The first account, written on 31 October, correctly described **unfinished delivery**. That statement changed on 1 November, when a working API execution route, an actual credential-verification repair and a guarded CircleCI release produced a separately checked production result. Both phases matter. Eventual success does not make the earlier failed attempts disappear, and the result was **not fully unattended**: the user repeatedly resumed the work and manually stored a one-time API token.

A [redacted evidence package](/evidence/tailwagging-autonomous-delivery/README.md) accompanies this article. It records the selected claims, exact revision, CI states, production readback and limits without releasing credentials or private machine logs. The [Tail Wagging repository](https://github.com/AyobamiH/wagging-web-wins) is private; some linked PR and CircleCI evidence requires authorised access.

## The result the user wanted

Two authorised development machines were available through Remote Desktop Commander. The engineering involved GitHub, CircleCI, Cloudflare Workers, the existing site's business API and a guarded 31-stage production workflow. GitHub Actions had returned a \`startup_failure\`, so CircleCI served as an alternate CI and deployment execution path. Its quality results alone were **not** production authorisation.

The completion contract was concrete: merge reviewed code, verify exactly which commit was admitted, provision restricted release credentials, migrate and verify the commercial D1 schema, promote the candidate without bypassing release protections, check live routes and leave behind an auditable outcome. A green unit-test run could establish part of this, never all of it.

## Phase one: code and CI passed; delivery stayed blocked

CircleCI's first quality job failed because of a brand-contract mismatch in new portfolio files. The defect was corrected, job #2 passed, and later jobs passed as the production-admission and release-parity checks were added. A CircleCI adapter was implemented to reuse the canonical Cloudflare production sequence rather than maintain a competing deployment recipe.

The operational work stalled elsewhere. Windows process launching from WSL on the web machine intermittently returned \`UtilAcceptVsock:281: accept4 failed 110\`. Browser-control and PowerShell invocations sometimes worked and then failed again. Separately, a tool-execution safety check rejected one attempted credential transfer. Those observations must be kept distinct: a WSL interop timeout is not an API authentication refusal, and a tool-policy rejection is not a CircleCI error.

The repeating pattern was **failure → diagnosis → proposed workaround → report back**, while the target outcome remained unchanged. Identifying the next task was not completing it. Rechecking a passing CI job did not install credentials. Successfully connecting to a browser did not prove deployment.

On **31 October 2026 at 23:28:54 UTC**, [PR #126](https://github.com/AyobamiH/wagging-web-wins/pull/126) was merged at commit \`d0ec06fa4a820f1324fb02fd2068e2195cf2b2b2\`. CircleCI quality job #12 passed. But the production workflow remained on hold and the new \`/portfolio\` route returned HTTP **404**. At that moment the defensible conclusion was **merged and tested, not deployed**.

A working Windows \`cmd.exe\` path eventually restored the authenticated CircleCI browser. The user saved the newly generated, one-time CircleCI API token to a protected local file because an automated transfer had been blocked. This was a necessary, explicit **human-assisted handoff**.

## Phase two: a better execution route revealed the real defect

On **1 November**, the web machine's Linux terminal operated reliably. The credential directory was secured with mode \`700\` and the token file with mode \`600\`. CircleCI's \`/api/v2/me\` accepted the saved token with HTTP **200**, establishing an authenticated API route without relying on repeated Windows browser interaction.

The API readback exposed the next concrete mismatch. Two CircleCI contexts existed, both project-restricted, but initially **neither contained any environment variables**. The read-only admission context was provisioned with three required key names and the release context with five. A follow-up API read verified the inventories without displaying secret values. Creating the contexts earlier had not been equivalent to installing credentials.

The release preflight contained a separate code defect. Tail Wagging's Worker and D1 credentials were account-owned Cloudflare API tokens, but the adapter checked only Cloudflare's **user-token verification endpoint**. That endpoint rejected the active account-owned token with HTTP 401. The correct account-scoped verification endpoint returned HTTP **200** and an active status.

The repair was deliberately narrow: verify the account-scoped endpoint when the account identity is known, allow a user-token fallback only after an appropriate authentication denial, and fail closed for inactive, malformed or unrecoverable results. Worker and D1 write tokens stayed separate; their different permissions were checked. The full local repository checks, targeted credential regressions and canonical release-contract tests passed.

[PR #127](https://github.com/AyobamiH/wagging-web-wins/pull/127) contains this fix. It merged as \`c19703717e3d6c3ed45b0d11a3c3c5bffa25ca8b\`. This became the **only** eligible new production release candidate. The previously held workflow was not reused to ship an older commit.

The decisive change was not another retry of the unreliable interop command. The workflow shifted to an authenticated Linux-side API, live context readbacks, a reproducible credential failure and a reviewable code correction.

## Phase three: the exact commit reached production

CircleCI pipeline **#16** ran the newly merged main commit. Its [production workflow](https://circleci.com/workflow-run/28a30ae0-423b-46ce-a98a-50dc557a838f) reached four successful terminal jobs:

| Gate | Job | Final result |
| --- | ---: | --- |
| Repository quality | #19 | Success |
| Explicit production-admission approval | #20 | Success |
| Read-only production admission | #21 | Success |
| Canonical guarded production release | #22 | Success |

The workflow finished at **05:42:15.553 UTC on 1 November 2026**. The superseded CircleCI workflow for the older candidate ended failed with production release marked **not run**; it was **not** the successful deployment.

The live [Tail Wagging site](https://tailwaggingwebdesign.com) then reported the exact merged SHA through its [release metadata endpoint](https://tailwaggingwebdesign.com/__release.json). The repository's canonical production verifier returned \`ok: true\` for that same SHA and the active Cloudflare Worker version \`7615022e-83e6-4ef9-9e3e-873831e99b00\`.

Fresh HTTP checks returned **200** for the homepage, [portfolio](https://tailwaggingwebdesign.com/portfolio), \`/__health\`, \`/__release.json\`, \`/api/v1/runtime\` and \`/api/v2/agent/capabilities\`. Headless Chrome rendered the portfolio listing, three individual case studies and the contact page. Cloudflare's API confirmed the retained \`* * * * *\` schedule and disabled public \`workers.dev\` and preview/version URLs.

These are distinct supporting observations: CircleCI reports a successful release; the live application identifies the deployed revision; the verifier checks production contracts; the browser exercises selected rendered routes. No single observation alone proves the whole outcome.

## Evidence ledger: which statements can be defended?

| Evidence | Supports | Does not establish |
| --- | --- | --- |
| PR #126 and quality job #12 | Reviewed portfolio implementation merged and passed CI | That the portfolio was deployed at that point |
| Remote execution traces | Intermittent Windows/WSL failures and later functional API route | One definitive root cause for all execution failures |
| CircleCI context API readbacks | Scoped contexts and installation of three plus five required keys | Exposure or proof of every secret's ability to perform a write |
| [PR #127](https://github.com/AyobamiH/wagging-web-wins/pull/127) | Narrow account-token verification repair and regression coverage | A production effect by itself |
| [CircleCI workflow](https://circleci.com/workflow-run/28a30ae0-423b-46ce-a98a-50dc557a838f) | Exact-main release jobs and terminal success | Every possible browser or customer transaction |
| [Release readback](https://tailwaggingwebdesign.com/__release.json) and production verifier | Live exact SHA and active Worker version | Real payment settlement |
| [Portfolio](https://tailwaggingwebdesign.com/portfolio) and headless Chrome | Selected newly published pages rendered | All devices, accessibility paths or customer purchases |
| [Public evidence package](/evidence/tailwagging-autonomous-delivery/README.md) | Redacted owner-collected claim map and recorded hashes | Third-party cryptographic attestation or a public copy of private logs |

The owner also retained a private close-out receipt, eight JSON evidence snapshots and browser-DOM fingerprints. The private receipt SHA-256 is \`65fbe0abd2b58f3b17385f24b429ceec4525640204fa82f2109f54eb9343c2b4\`. It is a byte-integrity reference, **not** a signature, and the private archive is not presented as a public download. The public evidence package contains a deliberately bounded extract.

## What the result does not prove

This is **one dated owner-observed case**, not a benchmark of AI agents or independent academic peer review. No real card charge, genuine customer purchase, exhaustive mobile journey or forced rollback was performed for this release. The rollback guard stayed in the canonical release path but was not triggered on the successful deployment. The original Windows/WSL problem was worked around; permanent repair across all workloads has not been established.

The user repeatedly instructed the assistant to continue and personally saved a one-time credential. This prevents describing the eventual success as an unattended autonomous release. The eventual success was **verified delivery with human intervention**, not proof that the system can always recover without it.

## The engineering principle: preserve separate states

A dependable operator must distinguish implementation, verification, authorisation, external effect and acceptance. A useful minimum state machine is:

\`READY → CI_VERIFIED → CREDENTIALS_VERIFIED → RELEASE_ADMITTED → CANDIDATE_VERIFIED → PROMOTED → LIVE_ACCEPTED\`

\`BLOCKED\` and \`FAILED\` require specific causes, bounded retries and a next action that changes the execution conditions. When an external effect might have succeeded despite a lost response, reconcile external state before replay. Promotion must refer to the reviewed SHA, and the live system must confirm the postcondition.

Here, progress came from **changing the execution route and then following the evidence**: authenticated API access, zero-variable context readback, account-token verification reproduction, a tested PR, exact-main admission and post-deployment runtime checks.

## A reproducible experiment remains open

To test the broader idea, use an isolated repository with synthetic credentials and a nonproduction Worker. Inject faults one at a time: failed WSL interop, expired API authentication, tool-execution refusal and a lost promotion response. Compare a conversational recovery process with a durable operator that persists checkpoints and reconciles side effects.

Measure completion rate, time to verified recovery, repeated ineffective attempts, false-success claims, necessary human interventions and duplicate effects. **No such controlled benchmark has yet been run.** A single successful recovery cannot substitute for that data.

## The final result

On **31 October**, the truthful outcome was **not delivered**. On **1 November**, it became **delivered and independently checked against the live system** at commit \`c19703717e3d6c3ed45b0d11a3c3c5bffa25ca8b\`.

Both statements belong in the permanent record. The success is evidence of recovery, not permission to erase the preceding failure. The engineering standard should be that **the exact intended effect occurred, the external system confirms it, and the evidence survives the conversation**.

*Original incident record: 31 October 2026. Recovery and release acceptance: 1 November 2026. Authored by Ayobami John Haastrup with AI-assisted drafting and evidence organisation. The public package is a redacted owner-generated record, not an independent third-party audit.*


Author-published engineering case study by Ayobami John Haastrup (ayobamih), prepared with AI assistance and verified against the owner's retained CircleCI, GitHub and Cloudflare release evidence. Not independently peer-reviewed or audited by a third party. The Tail Wagging repository is private; cited PR and CI links may require authorised access. Public evidence is a redacted owner-produced extract.