Case studyGhostwriter
EventKane CLI Hack Day
TestMu AI and AWS
Result3rd of the field
$1,000 prize
Built inOne day, hard stop 5pm
PeriodMay 2026

An agent that checks its own work

A one-day hackathon run by TestMu AI on AWS Kiro, judged on how deeply the build used Kane CLI, a browser automation tool driven in plain English. Most ways of using it end at the demo: the agent does a thing on screen and a person decides whether it worked.

The build I entered closed that gap. On a timer it drafts a post in my voice, publishes it to my real X account in a real browser, then re-opens the published post and reads it back to confirm what actually went out. When the post is rejected, the reason is fed back and the draft is rewritten, up to three attempts, with no person in the loop.

It placed third and took a $1,000 prize. The organisers’ note said it stood out for shipping something real and wiring the tool in to prove it works.

ONE BEAT ยท NO HUMAN IN THE LOOPKiro draftsfrom persona.mdKane posts itin a real browserKane re-opens itand reads the live postRecorded as passedonly if the text matchesRejected for lengththe failure reason goes back in, Kiro re-drafts itself, up to three attemptsEvery stage writes a file, so the command centre watches the run rather than being told about it.

Figure 1. One beat. The accent path is the part that mattered to the judges: the agent catching its own failure and re-prompting itself, rather than a person noticing and asking again.

Why the verify step is the whole point

Posting is the easy half. An agent reports success when the tool call returns, which is a claim about the request rather than about the result. The second call re-opens the published URL and reads the visible text back, so the run passes on evidence from the page instead of on the absence of an error.

That is also what makes the failure recoverable. A draft that runs over the character limit is caught at the post step with the count attached, and the count is what gets injected into the re-draft. The agent is not told to try again; it is told what was wrong.

Determinism where it counts

The drafting is done by the model. The loop is not. A thin orchestrator owns the state machine, enforces the retry cap and writes one file per stage, because a live demo cannot depend on a model choosing to retry. Keeping those apart is what let it fail on stage and recover on stage.

There is no database. Every stage is a file in the workspace, so the command centre watches the run by reading the directory rather than being told what happened, and the whole thing stays inspectable afterwards.

Posting to a real account

The output was public and irreversible, which changes the safety model. The first post of a session pauses at an approve, edit or reject gate before anything is published, and the unattended mode has to be armed deliberately. The persona document carries hard limits enforced at draft time, and no client is ever named, which is a product constraint rather than a preference.

What I would not claim for it

This was one day against a hard stop, built to be demonstrated. The self-correction is real and it ran live, but it was exercised on one failure mode, the character limit, which I knew about in advance and designed the recovery around. A verify step that reads the page back is a genuine improvement on trusting the return value. It is not evidence that the agent would catch a failure nobody anticipated, and the honest version of the result stops there.

The question it left open is the one I am working on now: an instruction obeyed inside a single run is a much easier thing than an instruction that has to survive a handoff to a fresh context hours later.

ghostwriter on GitHub →

Built solo in a day using Kiro, with Kane CLI driving the browser. The judging, the placing and the prize are the organisers’ assessment, not mine. The public repository is a scrubbed copy: the persona document is a redacted example and the drafted-post library has been removed, because both carried positioning I do not publish.

← All work