Agent Usage Patterns

English

日本語

English

日本語

Appearance

Making the Verification Target Explicit ​

Saying "check it" alone lets the model decide afterward what to check. Hand over the verification criteria as a contract before the answer exists.

Problem ​

The model says "it's fixed," but it isn't. The cause isn't uniform, though. Separating Mechanical Gates from Semantic Gates deals with a failure where something that could be judged deterministically rides on instructions — a non-deterministic means. This pattern deals with a failure one step earlier than that — the criteria for saying "it's fixed" were never handed over to begin with.

Say "check that it actually works" and the model checks something. What it checked was never decided by the human. The act of verification happens, but there's no target.

Context ​

Applies when:

  • A concrete criterion exists that the human wants checked
  • The definition of "works" isn't self-evident
  • The same verification repeats

Does not apply when:

  • The criterion can be expressed mechanically. If it can be written as a test, write it as a test (→ Separating Mechanical Gates from Semantic Gates). This pattern covers the case where a criterion can't be reduced to a machine and has to be handed over instead as a verbal contract
  • In an exploratory phase, before it's clear what's even right. Fixing a criterion before it can be fixed narrows the exploration

Boundary with neighboring patterns:

  • Separating Mechanical Gates from Semantic Gates — that pattern decides which kind of gate to place work on; this pattern decides what criterion to check against. When work can ride a mechanical gate, that takes priority
  • Instruction Layering and Scoping — the same mechanism (applyTo) serves a different purpose. That pattern decides which instructions apply; this pattern hands over, with a scope attached, what a piece of work must satisfy
  • Preemptive Plan Review — that pattern verifies the plan before the work happens; this pattern decides what to verify after it happens
  • Failure as Institutional Memory — a past failure works best written as a verification item. That pattern's triple's "condition" becomes the verification target directly

Solution ​

The structure of making the verification target explicitOn the left, no target is handed over. Only an instruction like "check that it works" exists, so the model builds its own criteria and checks against them, making it a matter of chance whether the result matches what the human actually cares about. On the right, a target is handed over first. Concrete criteria to satisfy are fixed before the answer, checked one by one, and unmet items come back named.No target — criteria not handed over"Check that it works"Instruction: check that it worksThe model builds its own criteriaChecks against that criteria"It works"Whether it matches is chanceThe criteria are built alongside the answerA target — criteria handed over first"Check that these three criteria are met"Contract: three criteria to meetFixed before the answerChecked one by oneUnmet items come back namedWhat to fix is determinedWhat to check against is fixed beforehandThe question isn't "was it checked" but "do I know what was checked"

Why this works. Verification is matching against something. Matching needs something to match against. Without a target handed over, the model builds one itself — and against a criterion it built itself, it will almost always pass. "Check that it works" always coming back "it works" isn't a lie. The criteria are built alongside the answer.

So this pattern's claim isn't "verify more strictly." It's fix the criteria before the answer exists. Order decides everything — a criterion built afterward bends to fit the answer. Only a criterion fixed beforehand ends up constraining the answer.

That said, handing over more isn't automatically better. Handing over verification criteria and writing out the procedure for checking those criteria are different things. The latter consumes context, and whatever it consumes crowds out other information at that cost (see Trade-offs below).

Trade-offs ​

Advantages

  • Verification results correspond to what the human actually cares about. Because a target to match against is handed over, what gets checked doesn't drift from the human's intent.
  • Unmet items come back named. Instead of "it doesn't work," what comes back is "this item isn't met," so what to fix is determined.

Costs

  • Writing the criteria is the human's job. If it can't be written, it can't be handed over. And often the human can't put "what's correct" into words either — in that case, this pattern doesn't apply.

  • Instructing the procedure occupies context. There's research worth handling carefully here. Under conditions running a 30B open-weight model on consumer hardware, giving only TDD procedural instructions was reported to increase regressions by 9.94% (Research, arXiv:2603.17973). The paper explains this as the procedural instructions pushing repo context out. This figure is limited to that specific condition and shouldn't be read as a general law for AI agents.

    This research isn't a refutation of this pattern. What the paper shows is what happened when only the "how to proceed" procedure was handed over, without the "what must be satisfied" verification target. If anything, it backs up the distinction this pattern draws — handing over verification criteria is different from filling the space with a procedure to check those criteria. More explicit isn't automatically better. A long procedural write-up can push out the actual point by however much it consumes. Being explicit also charges rent (→ Resident Context Inventory).

GitHub Copilot in Practice ​

Copilot isn't a single product. Here, two surfaces are covered: VS Code and Copilot CLI. Both use the same property name with the same semantics.

VS Code — using applyTo as a verification contract ​

Source: VS Code — Custom instructions (retrieved 2026-07-16). The applyTo property of an instruction file is defined as follows Official:

Glob pattern that defines which files the instructions apply to automatically, relative to the workspace root. Use ** to apply to all files. If not specified, the instructions are not applied automatically, but you can still add them manually to a chat request.

What applyTo declares is the scope of "which files it affects," and that by itself is the subject of Instruction Layering and Scoping. But when the content within that scope is a verification criterion for "what this piece of work must satisfy," the same mechanism becomes a tool for distributing a verification contract. One mechanism, working as a different pattern depending on what's put inside it.

Scope isn't decided by glob alone Official:

The agent determines which instructions files to apply based on the file patterns specified in the applyTo property in the instructions file header or semantic matching of the instruction description to the current task.

The entry point for scope isn't only string matching (applyTo) — there's also semantic matching between the description and the task at hand. When writing a verification contract, both routes are available: matching by glob, or matching by description.

Copilot CLI — the same semantics, on a different surface ​

Source: Copilot CLI — Adding custom instructions (retrieved 2026-07-16) Official:

Path-specific instructions are included only when their applyTo value matches a file that Copilot CLI is working with. An instruction file that you disable using /instructions is not included.

The contract is included only when applyTo matches the file currently being worked on. The same semantics as VS Code hold on a different surface, confirming that this pattern isn't confined to one product's feature.

Also Known As ​

NameSource
Making the Verification Target ExplicitDescriptive — a descriptive name coined by this catalogue; no primary source uses it
Context contractDescriptive — ⚠ no source. A name that appears in research documents, but no primary source can be traced

Don't write "context contract" as if it were an established, existing name. Other documents use this term too, but as far as this catalogue could confirm, no primary source exists in either vendor documentation or academic literature. It's included here because it circulates, not because it's sourced. Both names are treated as this catalogue's descriptive names.

  • Separating Mechanical Gates from Semantic Gates — that pattern decides which kind of gate to place work on; this pattern decides what criterion to check against
  • Instruction Layering and Scoping — the same mechanism (applyTo) serves a different purpose. That pattern decides which instructions apply; this pattern decides what a piece of work must satisfy
  • Preemptive Plan Review — that pattern verifies the plan before the work happens; this pattern decides what to verify after it happens
  • Failure as Institutional Memory — a past failure works best written as a verification item. That pattern's triple's "condition" becomes the verification target directly
  • Resident Context Inventory — verification items are resident content too. The more that's written, the more rent is charged every turn
  • If reading just one more next: Preemptive Plan Review — worth moving next to the idea of placing verification before the deliverable exists