By Tuesday morning, I’d been running clear/concise/precise evaluation for a couple days.

Refining coordinators. Optimizing model assignments. Cutting verbosity. Adding precision.

And discovering the same problem in file after file: duplication.

The Duplication Problem

I reviewed the evaluation results.

The same context appearing in multiple workers. Standards explanations duplicated across files. Examples repeated in different places.

This wasn’t supposed to happen.

I’d created standards files weeks earlier. Specifically to hold all context about coding standards, formatting rules, and examples. Workers were supposed to reference standards, not duplicate them.

That was the architecture. Workers handle execution. Standards provide context. Clean delegation.

But the evaluation results showed something different. Context had crept into workers. Despite having standards files, workers were explaining standards themselves.

How It Happened

I traced back through the history.

Weeks earlier: Created standards files. Moved context out of workers. Clean separation achieved.

Then came weeks of iteration. Testing workflows. Finding edge cases. Refining instructions.

And during that iteration, context crept back in.

A worker needed to check formatting. The instruction said “format according to standards.” But that felt incomplete. So I added a sentence explaining what proper formatting meant. Just for clarity.

Another worker needed to verify compliance. The instruction said “verify per standards file.” But examples help. So I added one example. Just for illustration.

Another worker made decisions about priorities. The instruction said “prioritize per standards.” But what if the criteria weren’t clear? So I added the criteria inline. Just for reference.

One sentence here. One example there. One set of criteria somewhere else.

Multiply that by weeks of iteration and dozens of small additions. Context crept back into workers. Not intentionally. Just gradually.

The architecture was still there. Standards files existed. But workers had gotten bloated anyway.

Why It Matters

Duplication isn’t just about file size. It’s about maintenance and consistency.

When context lives in one place, you change it once. When context is duplicated across multiple workers, you need to change it everywhere. And if you miss one, you get inconsistency.

When workers reference standards, standards can evolve independently. When workers duplicate standards, every standards change requires worker updates.

When separation is clean, each file has one job. When separation erodes, every file does a bit of everything.

The clear/concise/precise evaluation had revealed the symptoms. But the underlying problem was architectural drift.

Good architecture doesn’t maintain itself. It requires enforcement.

The Cleanup

I created a systematic cleanup plan.

First, identify all duplicated context in workers. What explanations, examples, and criteria appeared in multiple places?

Second, ensure standards files contained comprehensive context. Did standards explain everything workers needed to reference?

Third, remove duplicated context from workers. Replace with references to standards.

Fourth, verify workers stayed thin. Only execution steps, no context.

Fifth, reduce duplication within standards files themselves. Even standards had some repeated content.

The work was straightforward. For each instance of duplicated context: verify standards contained it, remove from worker, replace with reference, verify worker still worked correctly.

Workers became thin again. Just steps. Just execution. All context in standards.

The Result

I compared before and after.

Workers cut significantly. Standards slightly larger. But total content reduced because duplication was eliminated.

More importantly: clean separation restored. Each file had one job. Workers execute. Standards provide context. No mixing.

Why This Keeps Happening

This is a pattern I’d see repeatedly: architecture erodes naturally.

You build good separation. Clean delegation. Clear boundaries.

Then you iterate. Add features. Fix edge cases. Refine instructions.

And during iteration, context creeps back. Not intentionally. Just gradually. One small addition at a time.

Good architecture requires active enforcement. It’s not a one-time design. It’s ongoing vigilance.

Clear/concise/precise methodology surfaced the erosion. But preventing it requires conscious effort to maintain separation.

The DRY Principle

Don’t Repeat Yourself.

This is fundamental wisdom. But it’s not just about code. It’s about documentation. Instructions. Context. Anything that can be duplicated.

Duplication happens naturally. It’s easier to add context inline than to reference external files. It’s faster to copy an example than to link to one. It’s simpler to explain again than to check if explanation already exists.

But duplication creates maintenance burden. And inconsistency. And bloat.

DRY requires enforcement. Deliberate effort to identify duplication and eliminate it. Not once. Continuously.

The Next Question

That evening, I committed the cleanup.

Workers thin again. Standards comprehensive. Duplication eliminated. Clean delegation restored.

Two days of systematic work. Not because the original architecture was wrong. Because architecture had eroded and needed restoration.

I had a way to improve documentation. I could assign agents the right models. Workers and standards were properly separated.

All the files were “good.”

But what did “good” mean? Were all files at the same level of quality? Were some workflows in better shape than others?

I’d been evaluating files individually. Refining each one. But I hadn’t established what quality actually meant across the system. Without defined levels, “good” was just intuition.

Quality levels needed definition. Clear criteria for each file type. A way to measure whether files met minimum standards or exceeded them. A framework to ensure consistency across all workflows.

Next: Defining Quality Levels