A Requirement Needs a Job

I keep returning to the same design question: when does an agent package have enough requirements, and when have we added so much structure that the requirements begin to interfere with the work?

Recent WTK development gave me a more useful test. A requirement earns its place when it has a specific job, a known consumer, and a visible consequence when it is not satisfied.

The observation

Agent requirements are often collected into one large body of instructions. Purpose, operating guidance, acceptance criteria, tool permissions, evidence rules, and catalog descriptions all look like text, so it is tempting to hand all of them to the model and call the result governed.

They are not interchangeable.

Purpose explains why the agent exists. Runtime guidance helps it perform the work. Authority limits what it may do. Acceptance criteria help an evaluator judge the result. Evidence obligations state what the run must demonstrate. Catalog fields help another person or agent decide whether the package is relevant and usable.

Each requirement belongs to a stage and an audience.

This became concrete when WTK separated evaluation targets from runtime instructions. An acceptance target such as an accuracy percentage may be useful when constructing an evaluation, but placing that statement in the agent's operating prompt does not make the agent more accurate. It can instead encourage the runtime to repeat the desired claim without producing the evidence needed to support it.

The same principle appeared elsewhere. An evaluation fixture can be structurally valid while demanding an impossible success case. A registry can describe a capability that has no executable binding. More fields did not solve either problem. Giving each requirement a precise job exposed the mismatch.

Why it matters for agent systems

Too little structure leaves the agent free to satisfy the visible goal outside the intended bounds. It may use an undeclared capability, return the right answer without the required evidence, or produce an artifact that cannot be evaluated consistently.

Too much misplaced structure creates a different failure. The runtime receives evaluation language it cannot operationalize. Fixtures become overfitted to one expected answer. Catalog metadata begins to imply guarantees. The agent spends context on requirements that belong to a reviewer, compiler, or publisher.

The goal is not maximum specification. It is separation of responsibility.

For any required field or rule, I now want to be able to answer five questions:

1. Who consumes it?
2. At what stage is it used?
3. What decision does it change?
4. How can we observe whether it was satisfied?
5. What happens when it is missing or false?

If those answers are unclear, the requirement may be useful context, but it has not yet earned the authority of a contract.

What this means for WTK

WTK should preserve these distinctions as an agent moves from goal to package, projection, execution, evaluation, and catalog publication.

The governed package can remain canonical without sending every field to every consumer. A runtime receives the mission and operating boundaries it needs. An evaluator receives the criteria and evidence needed to judge the outcome. A target adapter receives the capability and binding requirements it must preserve. The catalog receives the public facts and limitations needed for discovery.

This is not an argument for making reasoning deterministic. It is a way to keep the surrounding system precise while leaving the agent room to choose how to accomplish the work inside its authority.

Still unknown

This is an engineering rule, not an empirical result. We still need to learn which requirements materially improve outcomes, which are redundant, and which constrain useful behavior without raising a measurable floor.

We also need to test whether the same requirement boundaries survive different goals, agents, teams, models, and harnesses. A field that is essential for a security-sensitive tool user may be unnecessary for a summarization agent.

The useful target may not be a universal minimum schema. It may be the smallest contract that can explain who may act, what success means, what evidence is required, and where uncertainty must stop the work.