Skip to content
Apart Research
Apart Research
Contact us
Sprint projectOct 26, 2026Hong Kong

Fuse: Keeping an AI Team Within One Approved Task

Seab Jackson · Team Fuse

Submitted to AI Collusion Research Sprint. Sprint projects are early-stage work by participants, not Apart Research publications.

Read the report

Report: Fuse: Keeping an AI Team Within One Approved Task

Open in a new tab (opens in new tab)
Share

An AI team can respect a spending limit and still exceed what its user approved. Two assistants may buy the same 25-credit report from different providers, spending only 50 of a 100-credit budget. Fuse keeps a shared record of the permission behind that purchase. Before a protected purchase executes, the system reserves both the money and the right to buy that report. An unanswered request keeps its reservation until its outcome can be established. We built a small Python reference model and compared two versions: a correct shared budget with safe retries, and the same controls with Fuse's shared purchase record. Across all 20 tested orderings of two purchase attempts, the first version bought the report twice in every ordering; Fuse bought it once. Both respected the budget and completed all four requested purchases in a separate normal-workflow check. Eighteen test methods passed. One cancellation ordering completed nothing, making the cost of conservative recovery visible. These are scripted engineering results under explicit assumptions, not observations of AI collusion. The contribution is an executable design, a conditional safety argument and a proposed behavioral evaluation. Fuse shows how a customer's purchase permission can remain intact across multiple attempts; its effectiveness with autonomous agents and real providers remains to be tested.

Reviews

Judging this Sprint?

Review “Fuse: Keeping an AI Team Within One Approved Task”

Your public critique appears on the project page without your name. Reviews of strong projects are shared with funders, as you choose below.

Not shown on the project page.

Shown on the project page, without your name.

Only the Apart team reads this, and funders if you agree below.

Decline to score

Only when the quality of the writing makes the work impossible to follow. Say why in your private critique; the project page shows only that a judge declined, not why.

How much would this matter for the field if it worked? How innovative is it? For scores of 4-5: is this actually new to the field, or replicating recent work?

Scoring guide
  1. 1Negligible. No clear problem addressed, or no meaningful novelty.
  2. 2Limited. Addresses a real problem but with a generic or well-trodden approach. Incremental at best.
  3. 3Moderate. Clear problem with a reasonable approach; some novelty in framing or method beyond routine application of existing tools.
  4. 4Significant. Important problem with an original approach, or identifies a neglected problem area. A valuable contribution others could build on.
  5. 5Exceptional. Tackles a critical problem with a genuinely novel approach, or opens a new research direction. Clear theory of change. You'd be excited to share this with researchers in the area.

How sound are methodology, implementation, and findings?

Scoring guide
  1. 1Seriously flawed. Methodology broken, results uninterpretable, or implementation doesn't work.
  2. 2Weak. Approach has significant gaps: missing validation, flawed experimental design, or incomplete implementation.
  3. 3Competent. Technically solid given the short duration. Methodology makes sense, results are interpretable, limitations acknowledged, work builds toward clear conclusions.
  4. 4Strong. Thorough methodology with convincing validation. Results clearly support conclusions. Immediately useful for future work.
  5. 5Exceptional. Ambitious scope executed rigorously. Surprising findings, novel methods, or unusually robust validation.

How clearly are work, findings, and impact potential communicated?

Scoring guide
  1. 1Incomprehensible. Cannot determine what the project is actually claiming or doing.
  2. 2Hard to follow. Key information buried, missing, or diluted by excessive length. Significant effort to extract main points.
  3. 3Clear enough. Can understand the problem, approach, and results without undue effort. Core content clearly present: problem, method, findings, limitations.
  4. 4Well presented. Easy to follow, well-structured, appropriate level of detail. Target audience would get it quickly.
  5. 5Exceptionally clear. A pleasure to read. Complex ideas made accessible. Could serve as a model for how to present this type of work.
Sharing your name *

When we share a strong project with funders, your name, scores and public critique go with it, confidentially; this choice is only about whether your name is public. If you think this project deserves funding, please also endorse it: that carries the most weight.

Share my private critique with funders *

See our Privacy Policy.

  1. This paper gives a clear, concrete account of a real gap: an agent team can stay within budget and still exceed what the user approved. The lost-reply example, the money and purchase-record invariants, and the attention to recovery are well explained. It’s also commendably direct that these are scripted engineering results, not evidence about collusion, and it shows the cost of conservative recovery rather than hiding it.

    The main limitation is that the central result follows from the design. A baseline deliberately missing a uniqueness rule buys twice, while the version with that rule buys once. This shows that the model behaves as specified, but not that the boundary helps against colluding agents. To strengthen the work, I’d suggest:

    Run the proposed agent pilot: Even a small study would provide the first evidence on whether agents attempt duplicate purchases, how they respond to refusals, and whether private communication changes the outcome. One episode per cell will support only a feasibility check, so plan repeated runs for any comparison.

    Test adversarial use of recovery: Colluding agents may deliberately leave purchases unresolved, trigger cancellations, or race revocations to stall the task. Measure this as a denial-of-service risk, with a defined escalation path for operations that can’t be resolved.

    Address purchase equivalence: Fixed report IDs avoid the hardest real-world problem. Agents could buy a near-duplicate under a different valid item or split work across items, so tests should include open-ended purchases.

    Move beyond the sequential model: Implement the gate on a durable database, then test real concurrency, crashes, and at least one provider API with weaker deduplication and cancellation guarantees.

    Connect the design to collusion carriers: Define which coordinated behaviors the boundary limits and which remain open, then measure residual harm such as wasteful but permitted purchases.

    Publish the package: A public repository would let others verify the runner, tests, and traces.

    Read full reviewShow less

Cite this project

@misc{jackson2026fuse,
  title = {{Fuse: Keeping an AI Team Within One Approved Task}},
  author = {Seab Jackson},
  year = {2026},
  month = oct,
  note = {Submitted to AI Collusion Research Sprint, an Apart Research Sprint},
  howpublished = {\url{https://apartresearch.com/sprints/projects/fuse-keeping-an-ai-team-within-one-approved-task-pdfv}},
  url = {https://apartresearch.com/sprints/projects/fuse-keeping-an-ai-team-within-one-approved-task-pdfv}
}

More from AI Collusion Research Sprint

All 392 entriesBrowse all projects

A Sprint is running now

AI x Epistemics Research Sprint · Nov 13 - 15, 2026