Long-Running Agents Need Checkpoint Contracts

GitHub's 24 July changelog says Claude Opus 5 is now available in GitHub Copilot, positioned for complex, long-running coding tasks that require careful reasoning, tool use, and reliability. That landed one day after GitHub said its MCP Server supports the next MCP specification, with the protocol moving toward stateless core behaviour on 28 July. The same 23 July cluster also added a mobile entry point where GitHub Mobile can ask Copilot cloud agent to investigate and fix failing Actions checks.

The pattern is not simply that coding agents have a stronger model. Long-running agent work now starts from more surfaces, can traverse more tool calls, and may depend on session context that is increasingly externalised rather than assumed to live inside one stateful conversation. The operating question for small teams is no longer only "should we approve this agent task?" It is "where must the agent stop, show evidence, and ask for a new decision before it continues?"

The repeated angle to avoid

The last ten posts here covered work taxonomies, file-upload workflows, agent work intake, spend-capable agents, model routing, AI credit pools, code-quality gates, review-agent environments, Copilot metrics, and operational project views. Older overlapping posts covered runtime credentials, permission budgets, prompt-injection triage, pull-request dashboards, agent audit trails, and deploy dry runs.

The weak version of this article would repeat the old X needs Y formula: long-running agents need guardrails. That is true but not useful enough. The sharper thesis is that longer reasoning and broader tool access move risk into the middle of the run. The launch approval matters, but the checkpoint design decides whether the operator can notice scope drift, rising cost, missing evidence, or an unsafe next step before the agent turns a useful investigation into an uncontrolled change.

Why launch approval is too small

A short agent task has a simple shape: ask, act, return. A long-running coding task has a different shape. It investigates, reads context, edits files, runs tests, follows failures, changes its plan, maybe opens a pull request, and may ask for another tool or model route along the way.

That creates failure modes that a single approval cannot catch:

Mid-run risk	What it looks like	Why a checkpoint helps
Scope expansion	A lint fix becomes a refactor across checkout, analytics, and auth	The agent must restate the new blast radius before editing more surfaces.
Evidence gap	The agent says tests pass but skipped the failing integration because credentials were missing	The checkpoint records which proof exists and which proof is absent.
Context loss	Stateless tool sessions require context to be reconstructed between calls	The agent must carry a compact task record instead of relying on hidden conversation memory.
Cost drift	A hard investigation keeps retrying expensive model calls or CI runs	The checkpoint can compare spend to the original task class.
Unsafe continuation	A mobile-triggered failed-check fix discovers a production migration issue	The run stops for desktop or owner review instead of continuing from a compressed interface.

The mechanism is simple: long-running agents make decisions after the initial human decision. If those later decisions are invisible, the operator has approved a process they cannot inspect.

Design checkpoints around decisions, not time

A checkpoint is not a calendar reminder every 15 minutes. It is a required pause before the agent crosses a decision boundary.

Useful boundaries include:

1. After investigation, before modification. The agent can read logs, tests, issues, and code, then must summarise the suspected cause and proposed edit scope before changing files.
2. After first diff, before broadening scope. If the first patch touches files outside the approved path, the agent must explain why and ask for a wider scope.
3. After local evidence, before pull request. The agent records tests, screenshots, build output, or reproduction evidence before asking reviewers to inspect the change.
4. After failed verification, before retry strategy. A failing test can justify another attempt; three failing strategies may mean the task needs a human diagnosis.
5. Before any irreversible or business-affecting action. Deploy, publish, migrate, spend, close a customer issue, or change a CRM record should be a separate approval class.

This keeps the agent useful without forcing a human to approve every keystroke. The operator approves state transitions, not tiny implementation details.

A checkpoint contract for practical web teams

The contract can live in an issue template, Linear form, pull request body, or internal agent-run table. The important part is that both the agent and the reviewer know what must be true before the run advances.

agent_checkpoint_contract:
  task_id: agent-2026-07-27-001
  source: github_mobile_failed_check | linear_issue | github_issue | scheduled_maintenance
  task_class: investigation_then_change_proposal
  approved_scope:
    repositories:
      - owner/storefront
    file_globs:
      - src/checkout/**
      - tests/checkout/**
    forbidden_without_new_approval:
      - production_deploy
      - payment_provider_config
      - customer_data_write
      - auth_or_secret_changes
  checkpoints:
    - name: investigation_summary
      before: first_code_edit
      required_evidence:
        - failing_check_url
        - suspected_root_cause
        - files_expected_to_change
      continue_if: scope_matches_approved_scope
    - name: first_diff_review
      before: expanding_file_scope
      required_evidence:
        - diff_summary
        - reason_scope_changed
        - affected_business_surfaces
      continue_if: owner_explicitly_approves_expansion
    - name: verification_receipt
      before: pull_request_ready
      required_evidence:
        - failing_test_before_or_reproduction_note
        - passing_test_after
        - risks_not_tested
      continue_if: reviewer_can_reproduce_or_accept_limits
  abort_if:
    - task_requires_production_credentials
    - blast_radius_includes_payment_or_auth_without_owner
    - verification_fails_after_three_distinct_attempts
    - estimated_cost_exceeds_task_budget

For a small business website, that schema is enough to prevent the most common agent surprise: the assistant silently discovers a bigger problem and keeps acting as if the original permission still applies.

Stateless tools make the run record more important

The MCP stateless-core shift matters because it pushes teams to be explicit about what context travels with each tool interaction. That is good engineering discipline. It also removes a comforting illusion: the agent cannot rely on a magical, perfectly remembered session to keep policy, evidence, and intent aligned.

A checkpoint contract gives stateless tool calls a stable operating record. Each tool call can be evaluated against the current task state:

request_context = task_id + approved_scope + current_checkpoint + evidence_so_far
allow_tool_call if requested_action is permitted at current_checkpoint
require_new_checkpoint if requested_action changes scope, cost, data access, or reversibility

This is especially useful when the entry point is lightweight. A mobile action to fix a failing check may be fine for a formatting failure. It is not enough context for a checkout regression that requires database access, production logs, or a migration plan.

Match model strength to checkpoint burden

A stronger model can handle more complex work, but that does not reduce the need for checkpoints. It often increases the need, because the model is capable of pursuing a longer chain of reasoning and tool use before returning control.

Use a simple rule:

Agent run type	Model posture	Checkpoint burden
Small reversible edit	Fast model is usually enough	One verification receipt before PR.
Messy investigation	Stronger reasoning model may pay off	Investigation summary before edits.
Cross-repository change	Strong model plus constrained tools	Scope checkpoint before each repository boundary.
Customer-path or revenue-path fix	Strong model is not sufficient by itself	Owner approval before changing checkout, booking, lead routing, analytics, or CRM writes.
Irreversible action	Model choice is secondary	Separate human approval and rollback record.

The point is not to slow every run. It is to spend human attention where the agent's next decision can change the business surface.

Operator questions before enabling long runs

Before allowing long-running agent work in a repository or queue, answer these questions:

1. What is the first checkpoint where the agent must stop before editing code?
2. Which file paths, data classes, services, and actions are outside the initial approval?
3. What evidence proves investigation, implementation, and verification?
4. How many failed attempts are allowed before the run aborts?
5. Which entry points are allowed from mobile, chat, issue assignment, and scheduled automation?
6. Does each tool call receive enough task context to enforce the current checkpoint?
7. Who can approve scope expansion when the agent discovers the task is larger than expected?

Claude Opus 5 in Copilot is useful fresh evidence that longer agent runs are becoming normal. GitHub's MCP and mobile updates show why that normalisation needs more than a better model. The durable operating asset is the checkpoint contract: a way to let agents keep working while preserving human control at the moments where the work changes meaning.