An ode to the Bitter Lesson and Amdahl's law maximalism.

I built an agent before I built Bitter.

At Blueshift, I built a long-horizon tool-calling agent from scratch. It had compaction, paged tool access, and programmatic tool calling. The published architecture covered roughly 90 tools and executions across millions of tokens.

Our first design was a fleet of specialists. Nothing failed loudly, but intent quietly evaporated at the handoffs. The system kept producing work while the strategy flattened into generic action. We eventually replaced the fleet with a continuous identity that moved through phases and left explicit traces for itself.

That work taught me the layer I did not want to compete in again.

I came away believing that the harness is a punishing layer on which to build a durable company. A provider can co-design its model and harness, train against its own interface, observe the combined system at scale, and control the inference economics underneath it. A clever independent harness may win locally. The next provider release can erase the reason it existed.

Bitter Lesson Maxing

Rich Sutton's Bitter Lesson gave me a name for the pattern. General methods that improve through computation, learning, and search repeatedly overtake handcrafted systems. My business version is simple: build where improving general agents compound your advantage, not where their next release erases it. I call that Bitter Lesson Maxing.

That is why Bitter does not own a house reasoning loop. Bring Codex, Claude Code, Pi, or the next harness that earns your trust. Bitter is betting that agent cognition will become replaceable. The operating environment, repository, authority, deployment, logs, customer feedback, and company history should survive the swap.

Amdahl Maxing

Amdahl's law explains the other half. Making one part of a workload infinitely fast cannot overcome the fraction that remains serial. In a company full of agents, human attention is that scarce serial resource. Faster code generation does not make a faster company when prioritization, review, deployment, support, and learning still queue behind the same person. More agent output can make the system slower when every artifact returns as an interruption.

Amdahl Maxing means designing the enterprise so scarce attention is spent where judgment has the highest marginal value: direction, taste, ambiguity, consequential risk, customer evidence, and accountability. Routine work should happen inside clear authority, be verified mechanically where possible, and return decision packets instead of transcripts.

Not every human gate is waste. A deliberate boundary for responsibility or an irreversible action may be the point. Re-entering the same state across five tools, approving low-risk actions one at a time, and reviewing unfiltered agent output are accidental serial work.

Why Frontier exists

Bitter deliberately depends on upstream models and harnesses. We need to understand what they can now do, where authority lives, which release contains the change, what state survives, and what new work reaches the human queue. Bitter Frontier is that intelligence function made public.

A release note describes one provider in isolation. It will not tell you that another project tried the same design earlier, that the shared feature name hides different defaults, or that one fix reached stable while the other still lives on a branch. Frontier reads projects together and provides cross-project memory no single project can supply.

The publication asks what agents just made cheaper, what handcrafted layer became less defensible, which part of the end-to-end company loop agents can now operate, and where scarce human attention moved next.

See the thesis meet the evidence

Foreground Attention Is No Longer the Control is the cleanest current Amdahl example. Claude Code let background agents commit, push, and open draft pull requests, moving human attention from a terminal prompt to repository policy and review. Codex moved a permission consequence into trace retention, while Gemini showed that a fix in nightly does not protect a stable operator.

The Agent Flywheel profile tests the Bitter Lesson from the other direction. Its tagged method keeps plans, task state, coordination, verification, and memory outside any one provider agent. That is bitter-pilled engineering. The same review still finds incomplete authority boundaries. Choosing the right layer does not excuse weak defaults.

The Bitter Lesson essay and Amdahl's Law essay collect more cases that support and complicate each part of the bet.

The line we will not cross

These ideas determine the questions. They do not predetermine the answers. A specialized method may remain valuable. More autonomy may reduce total throughput. A human approval gate may be the correct design. A provider change may contradict Bitter's assumptions. Frontier should publish those conclusions when the receipts support them.

Bitter is the disclosed publisher. It does not become the answer inside the reporting. The publication has to remain useful to someone who never becomes a Bitter customer. Trust first, product second.

A living letter

This is not a finished doctrine pinned in amber. Models will improve, provider harnesses will absorb new layers, Bitter will mature, and our understanding of both constraints will get sharper. I will revise this letter when the evidence changes the read. Frontier is where we test the bet in public. If the evidence breaks it, the record should show that too.

Michael Ruescher
Founder, Bitter
Editor, Bitter Frontier