Delegation Contract

v0.1 · Working draft

Working specification · v0.1

Delegation Contract

A compact contract for recording how a software task enters an AI coding agent, what authority the agent receives, what it must return, and where a human accepts the result.

Vincent Schmalbach · 2026

Abstract

Software teams already assign work in structured ways: issues, tickets, pull-request comments, audit logs. In current practice, AI coding agents receive the same kinds of work, but the surface, scope, authority, and output vary widely across products. Calling them all “coding agents” hides distinctions that matter for review and accountability.

A delegation contract records four facts about a delegated software task: how it entered the agent, what authority the agent had during the run, what it had to return, and where a human accepted the result. It is short enough to fit inside an issue, a runbook, or an audit log, and explicit enough to be reviewed by a teammate, an auditor, or a downstream tool.

§ 1   The four dimensions

Every delegated software task involves four decisions, whether the team writes them down or not: where the task came from, what the agent was allowed to do, what artifact it had to return, and who decided whether to accept the result. The contract makes those four explicit.

i   Task entry

The entry surface: a GitHub issue, an IDE command, a terminal prompt, a pull-request comment, or an external ticket. It marks where the task crossed from a human (or another system) into the agent.

ii   Authority

What the agent could do: read files, run commands, install packages, push branches, open or merge pull requests. Captured as a level (L1–L4) or as an explicit list of permitted actions.

iii   Work package

What had to come back: a diff, a branch, a pull request, a test report, a deployment preview, or a structured log. Specifying the artifact makes the output reviewable rather than performative.

iv   Acceptance context

Where the human decided: a code review, a staging deploy, a change-management workflow, or an internal sign-off. The contract marks the boundary the agent is not allowed to cross on its own.

§ 2   Authority levels

Authority can be written out as a permitted-action list, but most contracts can lean on a four-level shorthand. The levels follow standard supervisory-control vocabulary: the agent can acquire, analyse, decide, and act; the level says how much of that chain runs before a human steps in.

L1   Manual

Human acts

The agent inspects and explains. A human performs every implementation action.
L2   Advisory

Approve before act

The agent proposes a plan or patch; no command runs and no file changes until a human approves.
L3   Execute

Approve before merge

The agent edits, runs tests, and opens a pull request. A human reviews and merges. This is the most common level in current cloud coding agent deployments.
L4   Scoped autonomous

Bounded auto-merge

The agent can merge or ship inside a pre-agreed scope: specific repositories, file globs, or workflow types. Rare; usually limited to narrow, well-tested tasks such as dependency bumps or documentation updates.

§ 3   Templates

Each template is a contract for one common handoff. The format is illustrative; the same four fields work as a YAML block in an issue, a frontmatter section in a runbook, a short checklist in a PR template, or a row in an audit log.

3.1   Cloud agent on an assigned GitHub issue
task_entry: github_issue
authority_level: L3
allowed_actions:
  - read_repository
  - edit_files
  - run_tests
  - open_pull_request
work_package:
  - branch
  - pull_request
  - test_summary
acceptance_context: pr_review
3.2   Local terminal session
task_entry: terminal_prompt
authority_level: L2
allowed_actions:
  - inspect_files
  - propose_patch
  - run_tests
work_package:
  - diff
  - explanation
acceptance_context: developer_applies_patch
3.3   Mention on a pull request
task_entry: pr_comment
authority_level: L3
allowed_actions:
  - read_repository
  - edit_files
  - push_to_branch
work_package:
  - commit
  - updated_pr_description
acceptance_context: pr_review
3.4   Scoped autonomous workflow
task_entry: scheduled
authority_level: L4
scope:
  repositories:
    - org/dependencies
  paths:
    - package.json
    - lockfiles/**
allowed_actions:
  - read_repository
  - edit_files
  - open_pull_request
  - merge_pull_request
work_package:
  - pull_request
  - merge_record
acceptance_context: post_merge_review

§ 4   How to read a contract

To read a delegation contract, work through four questions in order.

1   Where the task came from

If the entry surface is ambiguous, you do not know who can amend the task while it is running.

2   What the agent may do

The authority level, or the explicit action list, is the boundary you would have to defend in an incident review.

3   What must come back

If the work package is unstated, “done” will be defined after the fact, usually by whoever runs out of patience first.

4   Who accepts the result

The acceptance context tells you which review, deploy gate, or sign-off the work has to pass to count as accepted.

§ 5   Companion paper

The framework above is introduced and defended in a working paper, Delegated Software Agents, that names the broader category, places it against adjacent terms (assistance, generation, automation), and proposes an evaluation agenda built around reviewable artifacts rather than benchmark scores. The arXiv preprint is forthcoming and will be linked from this page when posted.

Citation

Vincent Schmalbach. Delegated Software Agents. Working manuscript, 2026. arXiv preprint forthcoming.

BibTeX
@misc{schmalbach2026delegated,
  author = {Schmalbach, Vincent},
  title  = {Delegated Software Agents},
  year   = {2026},
  note   = {Working manuscript. arXiv preprint forthcoming.},
  url    = {https://www.delegationcontracts.org/}
}

Colophon

Delegation Contract is a public reference for a working specification. The contract fields and authority levels may revise in response to feedback before the arXiv version of the paper is posted. Issues, corrections, and dissents reach the maintainer through vincentschmalbach.com.

Last reviewed 2026-05-12