Writing specifications agents can implement

Ambiguous prose produces accidental architecture

“Retry the agent and keep the session” sounds understandable until implementation begins. Should the same process be restarted? Should chat history be replayed? Is this a new assignment? Does the retry inherit permissions? Which identifier appears in logs?

With AWM terms, the same requirement can be written directly: “When an AgentInstance fails, create a new RunAttempt under the existing AgentRun. Preserve agent_run_id. The replacement instance may differ. Do not widen the AgentRun’s grants.”

That sentence tells the database designer which keys survive, the orchestrator what to create, the telemetry pipeline how to correlate events, and the test author what must remain invariant.

Identity answers what survived

Every AWM entity has a qualified identity field such as work_session_id, agent_run_id, or run_attempt_id. Handles are names, not credentials.

Qualified identities remove a common source of integration bugs: a bare session_id arriving at an API boundary with no indication whether it names a conversation, a transport, or a work episode. When the identity is explicit, restart and resume behavior can be explicit too.

Authority answers who may change it

Each entity names one external authority role. A work-session coordinator owns the mutable WorkSession graph. An agent executor owns a RunAttempt. A host product owns HostConversation history. Other systems may observe or reference those records; they do not quietly become a second mutable truth.

This matters when several agents and services act at once. Clear ownership makes conflict resolution, idempotency, and recovery design possible before production traffic exposes the missing rule.

Lifecycle and cardinality answer what is legal

A WorkSession may contain many AgentRuns. Each AgentRun belongs to exactly one WorkSession and may contain many RunAttempts and Turns. Lifecycle transitions name the allowed movement between states, and terminal states say when a record is done.

Those constraints make acceptance criteria concrete:

• Given an AgentRun whose first process crashes, when execution is retried, then the new RunAttempt has a new identity and the AgentRun does not.
• Given a host conversation that is reset, when attached work is still open, then resetting the conversation does not close the WorkSession.
• Given project policy that denies a capability, when a WorkSession, ResourceBinding, or AgentRun is created, then no child grant can re-enable it.
• Given a project-bound WorkSession, when its definition is recorded, then it pins one immutable ProjectSnapshot revision.

Machine-readable meaning compounds

Because the model is structured data, the same definition can drive schemas, generated reference material, semantic lint, event contracts, client types, storage reviews, and conformance tests. A correction is made once in the canonical model instead of being rediscovered in every integration.

This is especially valuable in agentic development. Agents move quickly and confidently, including when a prompt is underspecified. A precise model narrows the solution space before code is generated. It gives an implementation agent fewer plausible but incompatible interpretations and gives a review agent objective invariants to check.

The result is not more ceremony. It is less rework: specifications that survive handoffs, retries, provider changes, and the arrival of the next framework.