Govern the Boundaries, Not the Reasoning

An agent can complete the immediate task and still produce the wrong result. The artifact may look useful. It may even satisfy a narrow goal. But the agent may have exceeded its authority, ignored required evidence, violated an operating constraint, or drifted away from the reason it was created.

We encountered this while building WTK. The lesson was not that agents need more instructions at every reasoning step. The lesson was that purpose and operating boundaries must be established before an agent is exposed to a harness and asked to work.

The observation

A capable agent needs room to reason, adapt, and discover approaches. If every decision is prescribed in advance, the agent becomes a brittle workflow with a language model attached.

But flexibility does not mean leaving the system undefined. The agent still needs a clear purpose, explicit goals, meaningful evaluations, known capabilities, authority limits, and conditions for stopping or escalating. Those elements define what acceptable success means.

The harness provides intelligence and execution. It may provide models, tools, memory, sessions, and coordination. It should not silently become the source of the agent's purpose or decide which boundaries may be ignored.

Why it matters for agent systems

Loose agent design often rewards completion without asking enough questions about how completion was achieved. A generated artifact can fulfill the visible request while relying on unsupported claims, using the wrong tools, skipping required review, or producing an output that cannot be evaluated reliably.

The opposite extreme is not much better. Overly deterministic orchestration can suppress the reasoning and adaptation that make an agent useful in the first place.

The better design target is determinism at the boundaries, not inside the reasoning.

Contracts and registries can expose the structure an agent needs without prescribing every thought. They can identify permitted capabilities, required inputs, evidence obligations, output fields, authority limits, evaluation criteria, and escalation paths. Deterministic controls can then govern consequential actions, tool authorization, receipt capture, required output structure, validation floors, and promotion decisions.

Inside those boundaries, the agent remains free to reason about how best to accomplish the goal.

What this means for WTK

WTK is exploring whether an agent's purpose and operating contract can remain canonical while the agent is projected into different harnesses. Registries describe the capabilities and controls available to the agent. Evaluations test whether the resulting behavior still serves the intended outcome. Guardrails and steering help return the work to its governed path when execution begins to drift.

This does not mean that WTK has solved alignment or made agent behavior deterministic. It means the architecture is attempting to make the important boundaries explicit, observable, and testable.

Each harness projection must still be evaluated under its own execution conditions. A contract that reads well is not proof that every runtime will enforce it faithfully.

Still unknown

The open question is where the boundary should be drawn for different kinds of work.

Which fields and controls materially improve reliability? Which decisions must be enforced deterministically, and which should remain available to agent judgment? How much structure can be added before useful reasoning becomes constrained? Do the same boundaries remain effective when the model, harness, tools, or team shape changes?

Those questions cannot be answered by architecture alone. They require controlled experiments, visible failures, and repeated qualification under declared conditions.

Our working principle is simple: let intelligence remain flexible, but govern the purpose, authority, evidence, and definition of success around it.