← News
  • Research

Can an agent maintain another agent’s app?

An agent built the feature. A different agent picked it up, extended it, and kept the existing tests intact. That is a useful kind of boring.

Flatpack illustration: under “Your Agent,” a person struggles with tangled chair parts; under “With Marionette,” a person assembles a chair using a numbered Marionette instruction sheet.
Some assembly required. Instructions included.

Same feed. One more request.

In Conduit, our RealWorld blogging frontend, the first agent built a title filter. The next job: match descriptions and tags too. Keep the rest of the app working.

Before

Search article titles

Filter cleanup

No matching articles.

After

Search titles, descriptions and tags

Filter cleanup

Keeping drafts across navigation

A note on cleanup and retained views.

marionette lifecycle
Illustrative example with sample article text, not an app screenshot. A description can now supply the match; tags are searchable too.

Same loaded articles. Same routes and pagination totals. Filtering kept the existing list and row instances. No extra fetch, and no quiet rewrite of article data.

New agent. Same contracts.

  1. First agentTitle filter + partly broken code
  2. Fresh agentRepair + descriptions + tags
  3. Independent checksOld behavior + new feature
The fresh agent received code and tests, without a handoff note.

Three inherited author tests were failing. The fresh agent repaired accessible names in application markup and added the extension while keeping those tests intact. The tests did not get a motivational rewrite.

Fresh-agent takeover
44 / 44 browser checks
33 baseline + 7 author + 4 withheld extension cases. Three unit tests, build, lint and architecture review also passed. Takeover assessment →
Lifecycle repair · second attempt
11 / 11 frozen independent checks
The first attempt was quota-interrupted and graded 7/11. This fresh attempt started from the original seed; no architecture review was performed. Lifecycle report →
A later unscored probe found a controller race →

The architecture review found clear ownership: the Application owned status and collection sources; Views borrowed them. Refresh, retry, navigation and cleanup behavior survived the extension.

How we checked it: method and limits

Gemini 3.8 Flash High at high effort, a fixed runner, published Marionette 5.0.0 packages and matching docs, in Chromium with local fixtures. The handoff used the installed official skill and read-only documentation MCP. Acceptance cases were withheld, without implementation hints, evaluator feedback or silent retries.

The full record includes the earlier attempts: the first feature passed baseline and withheld checks but failed three author tests; the next extension changed protected tests and was rejected before behavior grading; two original attempts stopped at provider quota. The additional lifecycle attempt is separate from those four.

The lifecycle checks covered stale loads and errors. Stop and destroy released resources synchronously; the borrowed state source survived destruction. A retained restart had the expected single subscription and heartbeat pair.

A later unscored probe found an agent-written controller race: a canceled restart cleared a newer restart’s flag, letting refresh abort its load. This was outside the eleven scored checks; their original result is unchanged. See the observation and open regression.

Supporting checks passed 30 native state tests; lint caught four deliberately invalid examples and cleared five valid ones. Review noted duplicated filtering work and an unverified refresh-focus case. This bounded study does not compare frameworks or measure speed, event counts, heap retention, live backends, other browsers or broader models.

Give the next agent real code, readable contracts and tests it must preserve. Then check its work. Instructions included; verification still required.