Separating Durable Agent Rules From Model Workarounds

A rule added to help an earlier model can remain in an agent's harness long after the reason for it has changed. Reviewing that rule requires knowing whether it expresses an enduring requirement or compensates for a particular limitation.

In How We Built Our Design Agent, LangChain's Amal Irgashev and Shreya Talegaonkar describe Content Studio, an agent for graphics, presentations and video. An early harness supplied 115 prebuilt interface components and detailed rules. After moving to Opus 5.5, the authors describe removing many detailed rules while retaining design principles, to give the model more design freedom.

The model and harness changed together, so the account does not isolate the effect of removing rules. It does show the team's reasoning about which guidance remained useful. The authors also distinguish measurable checks implemented in code from subjective design guidance supplied to the model, and describe enforcing required workflow stages through the pipeline.

Preserve the requirement behind the workaround

Consider a hypothetical agent producing staff training materials for a college. An earlier model repeatedly omitted an important safety warning when arranging a page freely. The builder responded with a fixed layout that always reserved space for the warning.

A stronger replacement model might handle varied layouts reliably. The fixed layout could then limit useful presentation choices. The requirement to include the warning still applies.

The review question is whether the new setup preserves the required content while allowing more flexibility. A visually impressive sample cannot establish that the warning survives across the situations in which it is needed.

Our note on retaining rare safeguards explains why infrequent use does not justify removal. This case asks a related question: has the model limitation that motivated a particular method changed, while the underlying obligation remains?

Record why each rule exists

For WTK's catalog packages compiled into target runtimes, a model-upgrade review should distinguish required outcomes from instructions added to help an earlier model achieve them. The reason recorded for each rule can help reviewers decide what to retain or revise.

In the college example, the page layout can change while a check still confirms that the required warning is present. If the workflow requires a content review before distribution, that step also remains required. Improving the model's layout choices does not justify removing either check.

Our model-change note asks whether a replacement model continues to use retained goals correctly. LangChain's account adds the complementary question: which retained instructions now deserve revision?

Documenting why a rule exists gives that review a starting point. It lets builders reconsider the method while keeping the responsibility clear.

Source: Amal Irgashev and Shreya Talegaonkar, How We Built Our Design Agent, LangChain, October 27, 2026. The college example and WTK interpretation are ours.