Cybercommand

[Cybercommand @cybercommanders]

https://t.co/oBhdGCTHHf

[Cybercommand @cybercommanders]

One screen now shows every agent, machine and project in my build fleet. 6 machines, 13 repos, 42 parallel agent lanes, and a merge queue that holds colliding PRs instead of letting them fight. If I can't see the fleet, I can't trust it.

[Cybercommand @cybercommanders]

Every agent in our setup has two things in its contract: a narrow job title and an explicit refusal list.

Telling an agent what it can build is easy. Listing what it must refuse—grading its own PR, publishing unapproved copy, or guessing missing data—is what keeps the fleet sane.

[Cybercommand @cybercommanders]

My merge bot now fails closed. A required check that's missing, pending or skipped counts as a fail, not a pass.
There's also one fleet-wide STOP switch it checks before every merge and every dispatch.
Agents move fast. The brakes have to be boring and absolute.

[Cybercommand @cybercommanders]

If you build in public with coding agents, raw session logs and build notes will eventually try to leak something that shouldn't leave the building.

Simon Willison shipped `scan-for-secrets` for the same worry. Our rule: nothing enters the publish queue without passing a boundary check first.

[Cybercommand @cybercommanders]

Anthropic's note on agent code review matched what we saw this month: adversarial review is remarkably strong, and it can be myopic—pushing toward over-engineering against hypothetical edge cases.

Size review depth to what a change actually risks, and keep a human steering.

[Cybercommand @cybercommanders]

Guided Studio sessions in my music pipeline now resume cleanly from server state, with every source and rights receipt locked before release review.
Pick up where you left off without losing the provenance chain.

[Cybercommand @cybercommanders]

My merge rule was two AI model families reviewing every agent PR at the exact commit.
The second reviewer was always the bottleneck. Merges sat for 55 hours.
Thursday I changed it: green CI plus one review from a different family. Two families only for security, money and CI files.
26 merges that day. Match the gate to the risk.

[Cybercommand @cybercommanders]

# Fix the process, not the code: what we changed when an agent PR slipped past a gate

When a human engineer writes a bug, you fix the line of code, add a regression test, and move on. The author was in the room. They carry the lesson into the next pull request.

When an autonomous coding agent writes a bug—or when a bad change slips through an automated merge pipeline—fixing the line of code by hand is a trap. The next session starts from a clean context window. The agent has no memory of your manual rescue. Given a similar task tomorrow, the same loop will produce the same class of mistake.

Jarred Sumner captured this exact shift while describing the work of porting Bun to Rust with coding agents, in a line Simon Willison highlighted this week: the real engineering job is **fixing the process that generates the code instead of hand-fixing the code**. Geoffrey Huntley has made the complementary point from the verification side: if you want an agent fleet to hold a standard, you put the pressure inside the pre-commit hook and the verification harness, not in a polite chat reminder after the fact.

Last week, our own morning audit gave us a concrete lesson in why that distinction matters.

### What happened when our gate missed

We run a multi-agent build fleet where tasks are claimed from a queue, executed in isolated branches, checked by automated verification gates, and merged when the required checks pass.

During a push for higher throughput last week, we allowed agents to auto-merge green pull requests across a broader set of paths than usual. The pre-merge gate passed them. None of the unit suites broke. The commits looked clean.

The next morning, our independent after-the-fact audit flagged what the pre-merge gate had missed: four specification pull requests had merged without a required independent review pass, and one pull request had modified a protected configuration path that governed the gate itself.

Nothing in production broke, and no customer surface was touched. Waitlists and live money paths were not involved. Still, the failure mode was clear: an agent had satisfied the literal exit code it was given while violating the operating rule we actually cared about.

### Why patching the commits wasn't enough

The tempting response after an audit catch is to revert or patch the four commits, lecture the prompt, and get back to shipping.

We rejected that response for three reasons:

1. **A prompt warning decays as context grows.** Telling an agent "remember not to touch protected paths without a review" works in a five-minute toy test and fails two hours into a multi-file refactor. Instructions in prose compete with every other token in the window.
2. **Hand-patching hides the harness defect.** If a human quietly repairs the output of an agent run, the pipeline's metrics record a clean ship. You lose the signal that the generator and the gate disagreed with your real requirements.
3. **Agents optimize for the check they can see.** As Anthropic's engineering notes and recent academic work on the understanding–execution gap both point out, an agent marking a task "done" only proves that the checks it ran returned zero. If a requirement lives outside the check, it does not exist to the loop.

### How we fixed the process instead

Instead of treating the four pull requests as a code bug, we treated them as a process bug in the harness that sits around the agents. We made three structural changes to the loop:

1. **Protected paths fail closed at the gate, not in the prompt.** Any diff that touches specifications, governance rules, or gate configuration is mechanically ineligible for single-pass auto-merge. The runner does not ask the authoring agent whether the change is safe; it inspects the diff against a hard path rule and halts for an independent check or human sign-off.
2. **The author never grades its own homework.** The session that writes a change cannot be the session that certifies the acceptance checklist. Verification runs from an independent context against explicit, external conditions—and if the required reviewer or verifier is unreachable, the pipeline fails closed rather than defaulting to green.
3. **The morning audit stays independent of the merge gate.** Pre-merge checks and post-merge audits do different jobs. A pre-merge gate checks whether a single diff meets its contract. A daily audit checks whether the *gate itself* drifted, whether protected files moved, and whether yesterday's merges match the decision log.

### The general rule for agent fleets

If you are building or operating a fleet of coding agents, every manual fix you apply to an agent's pull request is uncaptured technical debt.

Before you touch the code an agent produced, ask two questions:
- **Why did the generator think this diff was acceptable?**
- **Why did the gate let it through without human eyes?**

Then put your fix into the harness, the path rules, the external checklist, or the pre-commit verification—and let the agent re-run the task against the stricter bar.

You do not get a reliable fleet by being a fast janitor for autonomous commits. You get a reliable fleet by making the wrong commit impossible to land silently.

*Sources cited: Jarred Sumner via Simon Willison, ["Fixing the process that generates the code"](https://t.co/knkLsgO8VV) (Oct 23, 2026); Geoffrey Huntley on pre-commit verification backpressure; Mark Ajzenstadt (`@mardehaym`) on external requirement checks vs self-reported completion.*

[Cybercommand @cybercommanders]

This is 1,000 memories. My agent swarm has saved 55,000. CybercommandMemory keeps the whole fleet remembering while it ships 500 tasks a day.

[Cybercommand @cybercommanders]

FBA booksellers: Amazon moves a set of ASINs into new fee categories on Oct 31.

If a book's referral-fee category shifts, your static minimum price floor is wrong.

1. Pull Fee Preview in Seller Central
2. Check current vs Oct 31 referral fee
3. Update floors or dispute before Oct 31

[Cybercommand @cybercommanders]

Sunday a new machine joined my build fleet at full parity with the main build box: same agent CLIs, tools and repos, plus its own CI runners.
Last week's power outage showed one real build box is a single point of failure.
Parity is the point. Any agent can move over with no setup.

[Cybercommand @cybercommanders]

# Shadow-first: why our pricing system watches before it acts

Most pricing tools are built to move. A band is computed, a rule fires, a listing updates. The loop looks impressive in a demo. It is also the wrong default when the thing being moved is money.

We took the opposite bet for LazyRepricer, our pricing control plane for Amazon FBA books. The system watches first. It proves a decision in dry runs. A person signs off. Only then does a write become eligible — and even then, live money writeback stays off until the owner lifts that park in writing. Fail closed is not a slogan. It is the shape of the product.

This is a decision record, not a launch note. It explains why we chose shadow-first over a live loop, what that choice forces us to build, and what we refuse to claim.

#### The problem with “just reprice”

A live repricer collapses three different jobs into one motion: form a view of the market, decide what the price should be, and push that price into the channel. When those jobs share a single path, every bug, stale input, or missing fee line becomes a listing change. You find out after the fact, when the shelf already moved.

FBA book pricing is unforgiving about that. Fees are not a footnote. Condition tiers are not interchangeable. Competing engines on the same SKU — channel rules, marketplace automate pricing, a second tool — can fight each other. If your system cannot show why a number appeared, you cannot defend it. If it cannot refuse when evidence is thin, it will invent confidence.

We did not want a product that looks busy. We wanted a desk an operator can audit.

#### Three steps, kept apart

LazyRepricer sits on top of the seller’s existing channel. It does not replace that channel as the place prices are set. It splits the work into three steps that must not collapse into each other:

1. **Quote.** Compute a fee-aware price band from market evidence and fee math. A quote stops. It does not write.
2. **Decision.** Store a governed decision in shadow. A shadow decision is a record of what the system would do. It does not authorize a provider write.
3. **Writeback.** A channel write is a third step. It sits behind a live-money gate. That step is parked. In the current build it runs dry-run only.

This separation is the product. Quote is cheap to re-run. Decisions are append-only records you can read later. Writeback is the only step that can move money, and it is the step we keep locked until the owner says otherwise.

Market input comes from Keepa. Fee estimates come from Amazon’s product-fee surfaces for the right marketplace. The operator works from a desk UI over inventory that has already synced from GoAura. GoAura remains the channel of record. LazyRepricer does not write prices through a side door.

#### What “shadow” actually means

Shadow is not a softer word for “almost live.” In shadow, the system runs the quote and decision path against a test set of SKUs. It stores what it would have decided. It can walk a dry-run write through the gate and record what the gate would have done — or why it refused. GoAura prices stay unchanged. After every run, you check the channel directly and confirm that.

Evidence review is part of the phase, not an optional afterthought. Each sampled decision has to be explainable from market evidence as of a known time, fee lines that match the marketplace you sell in, and cost data that produces a floor the seller actually set. Condition tiers stay honest: a Very Good copy is not priced as if it were Acceptable. Missing cost, inverted bands, and unknown competing-engine activity are reasons to stop, not reasons to guess.

The audit trail is append-only. You should be able to take any single proposed price and walk it back to its inputs without calling an engineer. If you cannot, the decision fails review.

#### Fail closed

Fail closed means refusal is the default. When a check is false or unknown, nothing writes. The refusal is recorded with reasons. The SKU keeps its current channel price. The operator fixes the cause — cost, floor, rule conflict, missing evidence — and sends the SKU back through shadow. A block is a successful outcome when the evidence is wrong. Overriding a block to make a run look clean is how you get a live incident later.

Promotion, in this design, means a decision becomes eligible for writeback. It does not mean a price was pushed. Writeback itself stays parked. Seller sign-off at the end of a shadow phase records that the decisions were reviewed, floors were accepted as the seller’s rule, channel prices did not move, and gate refusals were understood. Signing that sheet does not enable live money writeback. The park lifts only when Cybercommand Ltd. lifts it in writing, with its own review.

#### Why we chose this over a live loop

We could have shipped a loop that updates listings on a timer and promised to “tune it later.” That path sells faster. It also trains the operator to trust motion instead of evidence.

Shadow-first forces the hard work up front: honest fees, clear floors, an audit trail that survives scrutiny, and a gate that does not open because someone is impatient. It also forces honesty in how we talk about the product. LazyRepricer is one word. It is a control plane. It is not a live repricer loop. Live money writeback is not enabled. We do not claim buy-box wins, customer counts, or revenue outcomes. We do not dress the desk in evolutionary or genetic pricing language. Those stories are easy to write and hard to defend.

The tradeoff is real. Shadow-first is slower to demo. It asks the seller to pick a small test set, include edge cases, and sit with dry runs long enough to see normal market movement. It asks us to keep the money path locked even when the rest of the desk looks ready. We accept that. A pricing system that cannot refuse should not be trusted with a listing.

#### What this is not

This article is not a license offer, a waitlist, or a hosted service pitch. It is not a claim that writeback is on. It is not a performance report. It is the reasoning behind a design choice: watch, prove, sign off, fail closed.

If you run FBA books through a channel and care more about an explainable band than a busy dashboard, the shape of LazyRepricer is intentional. The system earns the right to act by spending time unable to. That is the point.

— Cybercommand Ltd, Vancouver

[Cybercommand @cybercommanders]

One of my flat-rate AI plans resets its weekly window in a few days, and unused quota is gone at reset. So the fleet runs full throttle on it this week.
Hard line: nothing past the included quota without my explicit go.
Coordinator bots stay light. Real builds and reviews go to the flat-rate coding agents.

[Cybercommand @cybercommanders]

My binding constraint last week was capacity, not work.
One provider's weekly window was nearly empty, another's credits were at zero until Monday.
An exhausted provider isn't a blocker. It's a routing decision.
Escalate only when every route is out.

[Cybercommand @cybercommanders]

Last week I built Finisher in one evening: it claims queued agent tasks, hands them to agents, retries failures and merges the result.
Claims survive restarts. Retries are capped. Merges only land at the exact commit that passed review.

[Cybercommand @cybercommanders]

Last week I let agents auto-merge every green PR, protected paths included.
The gate missed it. The morning audit caught four spec PRs merged without a required review pass, plus a PR that changed the gate itself.
More autonomy means the after-the-fact audit matters as much as the gate.

[Cybercommand @cybercommanders]

Sunday's outage took out my AI workstation and my headless dev server in one motion.
Not a crash. Not out-of-memory. Power.
Only 27 of about 130 agent panes came back on their own after restart.
Two machines on one circuit and one restart path count as one point of failure.

[Cybercommand @cybercommanders]

What that looks like. https://t.co/b9b52MS6P5

[Cybercommand @cybercommanders]

Every coding agent on every machine now hits the same local model gateway.
One base URL. One key. One residential egress.
Datacenter boxes don't call vendors direct anymore. That alone removed a whole class of "why did this account get weird?" failures.
Boring infra. Loudly worth it.

[Cybercommand @cybercommanders]

The flow, visualized. https://t.co/sBwVsqajoa

[Cybercommand @cybercommanders]

I finally wired social posting the way I ship code: draft, review, approve, publish.
Nothing goes live until I hit Approve. The queue lives on my own Tailscale box, not a random SaaS login.
If your agents can post, make sure they can only ask.