AI Agent Contracts Cannot Define Repository Acceptance

Most agent contracts answer an important question:

How should an agent change this repository?

They can protect sensitive directories, ask for smaller diffs, require a handoff, and tell an agent when to stop and ask a human.

But a repository has a second question:

What must happen before this change counts as accepted?

That is not a writing-style question. It is an execution question: the setup path, the selected services, the canonical verification lane, the execution mode, and the evidence a green result actually carries.

An agent contract can guide edits. It cannot, by itself, define repository acceptance.

Consider an agent contract that says:

- Do not edit generated clients.
- Keep migrations small and explain them.
- Run tests before handoff.
- Ask before changing infrastructure.

Those are good contribution rules. They do not answer whether “run tests” means pnpm test, a service-backed workflow, a container lane, or CI's actual verification closure. They do not say whether dependencies are materialized, a database is ready, or a zero exit proves more than one narrow check.

The dangerous outcome is a plausible handoff: the agent followed the instructions, ran a command, and reported success. Nobody can tell whether it used the accepted path.

Ota gives that operational truth a machine-readable home in ota.yaml:

tasks:  setup:    prepare:      kind: dependency_hydration      medium: package_dependencies      source:        kind: node_package_manager        manager: pnpm        mode: install        frozen_lockfile: true   verify:    command:      exe: pnpm      args: [test]    depends_on: [setup]    safe_for_agent: true agent:  safe_tasks: [verify]  verify_after_changes: [verify]

That is not an instruction to “remember to install dependencies.” It declares one accepted setup and verification path that Ota can inspect, dry-run, execute, and record.

An agent can discover the declared surface, then execute it through the enforced lane:

ota doctorota tasks --safe --useota run verify --agent

The important distinction is that --agent asks Ota to resolve the selected task closure before anything starts. If the requested task, dependency, or workflow path is outside the effective safe surface, Ota refuses it and emits a structured result rather than relying on the agent to obey prose.

Ota does not claim to sandbox every process an agent could launch. An agent with unrestricted shell access can still bypass Ota by not using it.

The enforcement point is the Ota runner boundary: ota run <task> --agent and, for an agent-admitted workflow, ota up --workflow <name> --agent. That gives developers and CI fast, inspectable execution control now. A stronger organization-wide boundary comes when CI gates and agent harnesses consume the same contract truth.

That honesty matters. A declared safe task is useful; a runner that refuses an unsafe closure is stronger; an org-level harness or merge gate that requires the same result is stronger again.

Use an agent contract for contribution behavior:

• editing and review rules
• sensitive files and escalation
• coding conventions and handoff expectations

Use Ota for repository acceptance:

• dependency hydration and setup order
• services, readiness, tasks, and workflows
• native or container execution selection
• agent-admitted execution paths
• receipts, proof boundaries, and CI drift checks

Neither replaces the other. A repository with only agent guidance still asks the agent to infer how the software runs. A repository with only Ota can still need human collaboration rules.

The durable model is simple: let the agent contract govern edits, and let Ota govern whether the repository was prepared, verified, and evidenced through an accepted path.