Platform · Automation · May 2026 · 3 min read

When the repeating unit is the product

Thesis

For platforms of many near-identical units, the product is the scaffold: discovery → analysis → generation → validation, with CLI tools collapsing context and scripts judging while agents propose.

Some problems aren’t one hard task. They’re hundreds of near-identical units that differ in a few structured ways: another check, another governed limit, another sibling service with the same shape. In that world the product isn’t the nth implementation. It’s the scaffold that makes the nth implementation cheap, reviewable, and consistent.

The public example I can point at is quota monitoring from March 2025: custom checks for cloud limits that native tooling doesn’t cover, with a runtime that executes small counting functions through a shared handler, and a separate scaffolding layer for adding a new governed limit. The same instinct shows up later in MOS (November 2025) and in how Context Compression treats structure as the reusable asset. The lesson is portable even when the domain isn’t.

The repeating-unit problem

If every new unit starts as a blank file and a long prompt, you will eventually lose. Context explodes, style drifts, and review becomes archaeology. The repeating-unit problem is recognizing that the valuable artifact is the pipeline that turns “we need another one” into a candidate that already looks like the last good one.

Platforms amplify this. The cost of inconsistency isn’t one bug; it’s a family of near-misses that all need the same explanation in code review.

Four agent roles

The scaffold that kept working for me splits into four roles that should not share a brain:

Discovery finds the unit: the limit, the endpoint, the pattern instance that isn’t covered yet. Analysis classifies it: what kind of check, what inputs, what failure modes. Generation scaffolds the implementation against known-good shapes. Validation reviews the candidate against deterministic rules before a human merges it.

Mixing those roles is how you get confident nonsense. Keeping them separate is how you get a factory instead of a hero agent.

Pattern-triggered instructions

Recurring guidance shouldn’t live in the live prompt. It should fire when a pattern matches: this is an account-level check; this is a resource-level check; this output shape is required; this handler boundary is not optional. Pattern-triggered instructions are the cheap rule hierarchy applied to a domain of siblings.

That encoding is what makes generation safe to automate. The agent isn’t inventing the platform each time. It’s filling a slot in a shape you’ve already decided is good.

Tool call as compressed context

CLI tools and shared handlers are compression. A tool call that paginates, retries, and normalizes a response replaces a pile of prose about how to talk to the API. The agent proposes the small unit (the counting function, the threshold config) while the tool owns the boring reliability surface.

That’s the same attention-budget idea from agent-ready context, applied to runtime: don’t paste the platform into the prompt. Call it.

Deterministic validation

Generation can be agentic. Certification should not be. Schema checks, contract tests, policy scripts, and review gates that don’t depend on a model’s mood are what make the scaffold trustworthy. Scripts judge; agents propose is the general form. On a repeating-unit platform it’s also how you keep the hundredth unit from quietly inventing a new return shape.

Soft metrics only: when the scaffold is working, adding a new unit feels like filling a form and surviving review, not like reopening the design of the platform. I’m not claiming a universal speedup. I’m claiming the failure mode changes from “heroics” to “process.”

What I’d reuse elsewhere

Anywhere the work is a family of near-identical units, I’d reuse the same skeleton: discover → analyze → generate → validate; pattern-triggered instructions; tools as compressed platform context; deterministic gates in front of merge. MOS is how I’d want that skeleton to run locally and stay inspectable. Context discipline is how I’d keep each role’s window small.

The product is the repeating unit’s factory. Ship that, and the individual units stop being the interesting part, which is exactly when a platform starts to feel like one.

Related work

AWS Artificial Server Quotas Observability Platform →Modular Orchestration System →Context Compression →

Related reading

Let the scripts judge and the agents fix →Compress for agents, not for humans →Orchestration engineering: systems that spawn engines →Dual channels and rule layers beat a longer prompt →

Portfolio graph

Hover nodes · click empty canvas to zoom/pan

Maps how the work here connects. Open the Portfolio graph →

  • Professional
  • Personal
  • Skill
  • Writing