Skip to content
[bmdpat]
All writing
5 min read

Gemini first for four jobs. One run finished two tasks.

I moved four recurring jobs to Gemini, then checked what actually finished. One recorded run proved progress. The broken queue sweep stayed broken.

Share LinkedIn

On 2026-09-16, I changed the provider order for four recurring jobs in my agent fleet. Digest, Brain Worker, Obsidian maintenance, and supervisor review would try Gemini before Codex and Grok.

A longer provider probe passed after the first timed out, using my existing Antigravity login. The September 16 ledger recorded one Gemini Brain Worker run with two named tasks finished. The queue sweep still had a separate Windows permission failure.

Gemini routing changes and unresolved work

What did the routing change prove?

The first probe timed out. A longer probe passed. That gave me a working provider path to test against scheduled work. It did not tell me whether every job could finish its own work with that provider.

I needed the next receipt: a real run with named results. Brain Worker's report supplied two. It removed a retired dashboard from the queue sweep's eligible queues. It also stopped claims from being made against temporary scratch files. Both changes were maintenance work that the recurring job was supposed to handle.

I could point to those changes when I asked what the switch accomplished. The provider name alone would have told me much less. A configuration can say Gemini first while the actual job fails before it changes anything.

That distinction is why I keep coming back to verifying what an agent actually produced. I want a result I can inspect after the process exits. A successful probe is useful evidence about the probe. A completed task needs its own evidence.

Why did I reject the bigger completion count?

An earlier summary in the day's record said Brain Worker completed fourteen agent-doable tasks. The later correction was explicit: fourteen tasks were available to agents. Fourteen tasks did not finish. The report named two finished tasks.

Those sentences describe different amounts of work. Using that number in the next summary would give me credit for work still sitting in the queue. The correction belongs in the public account too.

This is also a reason to give an agent a file it can read again. My record had room for the correction. The next reader still has to apply it. Preserving both sentences without resolving their disagreement would just preserve the error alongside the fix.

For this day, I can name the two results. I cannot turn the rest of the available work into completed work because the provider changed.

What remained broken after the switch?

The queue sweep had failed on a Windows desktop permission. Moving four provider routes did not prove that problem fixed. I still had a failed sweep to deal with after I had a recorded Brain Worker run.

The supervisor also withheld approval for showwork, my project for checking agents' completion claims. Its local evidence archive was missing, despite passing remote tests. I could not count that review as approved.

I want routine work to continue without my hand on every step. On this day, I had one recorded Brain Worker run after my routing decision. I did not have a repaired fleet or a completed product checkpoint. Both limits belong beside the work that finished.

Accompanying prompt

What the prompt does: Checks the reported work behind a provider change and separates it from probes, available tasks, and unresolved failures.

Copy/paste this prompt:

Copy-ready prompt

Paste the exact block into your coding agent.

No article chrome, no footnotes, no formatting drift.

Role: Review an agent run against its recorded results. Context: I changed the provider order for recurring jobs. Read the supplied configuration change, run ledger, and task reports as evidence. Task: 1. Name the jobs whose routing changed. 2. Separate a successful provider probe from a completed scheduled run. 3. List completed tasks only when the report names their results. 4. Apply later corrections to earlier counts. 5. Identify failures that the routing change did not prove fixed. Output: - Routing changed - Reported results - Work still unresolved Constraints: - Do not count available tasks as completed tasks. - Do not infer a repaired system from one successful run. - If receipts disagree, explain the disagreement.
22 lines736 chars
Ready

This prompt and every other one we publish live in the free prompt library.

Copy the block above.

See what BMD includes: https://bmdpat.com/bmd

Get the Local AI Field Kit

Four copy-ready tools now, then one evidence-backed Local AI Lab Note on Friday when there is something worth sharing.

Try the free agent run check first

Get the requested artifact now, then at most one evidence-backed Local AI Lab Note on Friday when there is something worth sharing. One-click unsubscribe. No sponsored placements. Privacy.

PH

Patrick Hughes

I build BMD and publish measured AI runs, failure reports, and reusable checks. Nashville, Tennessee.

More writing