What Is This?

Software teams usually assign work through a bug report, a GitHub issue, a Linear ticket, a pull-request comment, or a short request in chat. The work has a scope, an expected output, and a point where someone reviews and accepts it.

Coding agents are starting to receive the same kind of work. Some suggest code only. Some edit files in a local checkout. Some run terminal commands. Some work in the background, then open pull requests. Some receive tasks from issue trackers and return a branch, tests, logs, or a patch for review.

Calling all of those systems “coding agents” hides important differences. The key question is not whether a tool uses AI. The key question is what was delegated to it, what it was allowed to do, what it had to return, and where the human review step remained.

Delegation Contract is a public vocabulary for describing software work handed to an agent. It lets teams describe those differences without rewriting the same paragraph each time. It records the work package and the authority boundary around it.

Basic delegation contract

A delegation contract answers four questions:

It asks how the task entered the agent, what authority the agent received, what work package it had to return, and when human acceptance happens.

Those four fields distinguish products and workflows that behave very differently. A terminal assistant that edits local files under constant supervision fits a different workflow from a cloud agent that creates a pull request from a GitHub issue. A tool that suggests code has a different role from one that runs tests and pushes a branch. The vocabulary makes those distinctions explicit.

Why the vocabulary matters

Delegated software work is only useful when the boundary is clear: engineers need to know what the agent may touch, reviewers what output they are accepting, managers how tools with similar marketing language behave in practice, and researchers need stable terms for classifying agentic software workflows.

The specification gives those groups a shared language for product documentation, issue templates, agent logs, pull-request metadata, procurement reviews, safety evaluations, and research datasets.

What Delegation Contract does not cover

Delegation Contract is a vocabulary for delegation that is not a product certification. It says nothing about whether an agent is safe, capable, or production-ready, and it does not prescribe one ideal workflow. Some teams want tightly supervised local agents; others want background agents that prepare pull requests. The same vocabulary describes both.

It does not replace software review. The contract defines where the acceptance gate sits. The contract still leaves code review, testing, deployment controls, incident response, and security policy in place.

Automation levels and who has authority

The specification uses automation levels to describe authority. Lower levels keep the human close to each action; higher levels let the agent select and execute more work before review. What matters is what it can actually do before a human approves the result.

That sharpens comparisons. An agent that can inspect files and propose a plan but needs approval before edits has a different authority profile from one that can edit files, run tests, and open a pull request. When a product’s default workflow and configurable maximum differ, record both.

More on the site

Use the specification for the formal field definitions. The templates apply the vocabulary to common workflows. The schema is the right choice for a machine-readable record. The companion paper explains the research motivation and shows how the vocabulary classifies current coding-agent systems.