Aweb Study 003 / Mission contracts

Mission contracts for agentic work.

Before an agent touches tools, it needs a frame: what to do, what not to do, what evidence to leave, and where the operator still decides.

03

Mission Contract

The operating brief before a system touches tools

AWeb
Operator requestIntent, context, taste, urgencyWhat should happen?What is not allowed?What proves it worked?MISSIONCONTRACTMissionThe specific work to complete.AuthorityWhat the system may read, call, change, or create.BoundaryWhat must be refused, paused, or escalated.EvidenceReceipts, tests, citations, diffs, screenshots.StopFailure states and human review points.Tool useAPIs / MCPfiles / providersReceiptartifacttracereview
A mission contract turns a request into bounded work: objective, authority, tools, evidence, and the point where the operator must decide.

Definition

A mission contract is the operating brief before the machine moves.

A prompt asks for an answer. A mission contract defines the work. It says what the system is trying to accomplish, what authority it has, which tools it may use, what evidence must be produced, and when the operator needs to intervene.

This matters because agentic work can move quickly through files, APIs, tools, providers, and generated artifacts. Speed without a contract is noise. Speed with a contract becomes inspectable work.

Fields

The contract carries mission, authority, boundary, evidence, and stop conditions.

The useful version is simple enough to use and strict enough to matter. A mission needs a goal. Authority needs a scope. Boundaries need to be explicit. Evidence needs to be requested before the answer is trusted.

In Aweb language, the contract is the human-readable frame around a machine-readable loop. It tells the system what kind of work is allowed and tells the operator how to inspect the result.

  • Mission: the work to complete, not the vibe to imitate.
  • Authority: what the system can read, call, change, create, or refuse.
  • Tools: APIs, MCP tools, files, providers, browsers, databases, or generators allowed for the task.
  • Evidence: receipts, artifacts, diffs, citations, tests, or screenshots needed before confidence is earned.
  • Stop conditions: what failure, uncertainty, risk, or missing permission should halt the loop.
  • Operator review: the exact decision a human still owns.

Aweb

Aweb is built around contracts because the work is bigger than chat.

Aweb is not interesting to me as another box that answers questions. It is interesting as an operating layer where a mission can route through tools, providers, API/MCP access, memory, evaluation, and generated artifacts while keeping the trace visible.

That means the contract has to be more than decoration. It becomes the thing that keeps the system from pretending it has authority it was never given.

Failure mode

The contract prevents impressive answers from becoming irresponsible work.

A model can produce fluent language even when the work is under-specified. That is dangerous because fluency can hide missing authority, missing evidence, or a shortcut that breaks trust.

The contract forces the system to ask a better question: not only what can be generated, but what should be attempted, what must be checked, and what cannot be claimed.

A mission contract is not bureaucracy. It is the minimum structure that lets a fast machine do serious work without stealing authority from the person responsible for it.