Delegation Contract v0.1

Delegation Contract v0.1 sets out the minimum context a team should record when software work is handed to an agent. It is meant for product documentation, issue templates, audit logs, and research papers comparing coding-agent systems.

Four core contract dimensions

Task entry shows how the work starts. Common entry points include an issue assignment, a chat prompt, a pull request comment, an IDE command, or an external ticket.

Authority sets the agent’s allowed actions without asking. L2 and L3 differ on whether the proposed action needs explicit human approval before execution. Some products have conservative defaults and stronger configurable modes, so profiles should name both when the distinction matters.

A work package specifies what the agent must return. A package can be a diff, a branch, a pull request, a test report, a reproduction note, a deployment plan, or a combination of those artifacts.

Acceptance context describes where the human decision happens, whether a team accepts a patch in an IDE, reviews a pull request, runs a staging deployment, or routes the result through an internal change-management system.

Automation and acceptance profile

The draft uses levels to distinguish suggestion, planning, execution, and acceptance. The labels may change, but the practical split remains: one system proposes a plan, while another executes shell commands, pushes commits, or opens a pull request.

Profiles should include an access date when they classify live products because coding-agent systems change quickly. A defensible profile should state which documentation version or product state it describes.

Out of scope

Delegation Contract does not rank tools, certify vendors, or define a legal standard of care. It does not claim that higher autonomy is better. For many production teams, a lower level with clear acceptance gates is the stronger operating model.

The draft does not replace security policy. It describes the delegation shape; teams still need separate controls for credentials, network access, test execution, code review, and deployment.

Versioning guidance

The current draft is v0.1, and later versions should keep the four-dimension structure unless implementation experience shows that one dimension does not discriminate real systems.