Long-running agents change the failure mode. A short coding assistant can be treated like a sharp autocomplete with a tool belt. An agent that works across files, apps, browsers, calendars, and scheduled tasks for hours is closer to an unattended workflow runner with judgment in the loop. That is useful, but only if the handoff points are designed before the first impressive demo becomes a recurring process.
OpenAI's July 2026 ChatGPT Work launch is the clearest product signal so far. It describes an agent that can use connected apps, work across web, mobile, and desktop, run scheduled tasks, and ask for approval on important actions. That is a good direction, but the engineering work starts where the product copy stops: what exactly counts as important, who reviews it, and what evidence does the reviewer get?
The handoff map
I would split agent work into four gates. They are small enough to explain in a ticket and concrete enough to automate around.
| Gate | Human decision | Agent output required |
|---|---|---|
| Scope | Should this task run at all? | Goal, sources, allowed tools, stop conditions |
| Authority | May it touch this system? | Requested permissions, target records, expected side effects |
| Evidence | Is the result grounded? | Source list, changed files or records, assumptions, failed checks |
| Commit | May this become durable? | Diff, preview, recipient list, rollback path |
The lazy version is not a new platform. It is a checklist in the task template, a few permission rules, and a required evidence block before the agent can send, merge, publish, bill, delete, or schedule anything.
Gate 1: scope before runtime
The first gate happens before the agent starts. A long-running task should have a bounded goal and a stop condition. "Monitor competitors and update the roadmap" is not bounded. "Every Monday, collect pricing-page changes from these five URLs and draft a product note with source links" is bounded.
This matters because scheduled and persistent agents create a quiet kind of drift. They can keep doing almost the right thing long after the original context has gone stale. I want the initial prompt or task record to say what tools are allowed, what systems are read-only, what actions require approval, and when the task should stop instead of improvising.
This is the same discipline I argued for in agent-ready issues, just applied to work that survives longer than one pull request.
Gate 2: authority before action
The second gate is permission, but permission by itself is too blunt. "Can use Gmail" is not the same as "can email a customer." "Can use the browser" is not the same as "can submit a form." "Can edit a spreadsheet" is not the same as "can overwrite the source of truth."
The OpenAI ChatGPT agent system card is useful here because it frames the product as a combination of research, browser action, terminal work, and connectors. Those are separate authority surfaces. I would model them separately:
- Read public web pages.
- Read connected private sources.
- Draft changes in private sources.
- Perform external actions.
- Make irreversible or costly changes.
Most teams can allow the first two quickly. The last two need explicit review. That one split prevents a lot of policy theater. You do not need a giant governance program to say that an agent may collect source material but may not send, publish, merge, purchase, invite, delete, or change billing without a named approver.
Gate 3: evidence before trust
A human handoff without evidence is just a vibes checkpoint. The reviewer needs to see what changed, why it changed, and what the agent could not verify.
For production engineering workflows, I want every long-running agent result to include four things:
- The final artifact or diff.
- The sources or records it relied on.
- The assumptions it made.
- The checks it ran, including failures.
This is where observability and handoff meet. In my telemetry contract for production agents, I focused on traces. For handoff, the trace is not enough. The agent should convert the trace into a short review packet a human can read without replaying the whole session.
Claude Code hooks are a practical example of the shape I want. The hook system exposes lifecycle events such as pre-tool use, permission requests, post-tool use, failures, and stop events. I would not copy that exact interface everywhere, but I would copy the idea: lifecycle boundaries are where deterministic checks belong.
Gate 4: commit before durability
The last gate is the one teams skip because the demo already worked. An agent drafts a deck, edits a spreadsheet, prepares a pull request, updates a CRM field, or writes a launch note. The output looks plausible. Someone says yes. The durable action happens.
That gate should be boring and explicit. Before durability, ask three questions:
- What will become visible to other people or systems?
- What cannot be automatically rolled back?
- What account, budget, reputation, or customer relationship is affected?
GitHub's Copilot code review docs show a useful boundary: Copilot can comment, suggest changes, and pass suggestions to a cloud agent, but its review does not count as a required approval. That is the right default. Agents can compress review work, but they should not silently become the authority that replaces review.
The small implementation I would ship
For a team adopting long-running agents this month, I would start with one shared handoff block:
- Goal: the task in one sentence.
- Allowed systems: read and write surfaces.
- Approval required for: named action types.
- Evidence: links, diffs, screenshots, rows, logs, or trace IDs.
- Known gaps: anything not checked.
- Commit action: the exact button, API call, merge, send, publish, or schedule step requested.
That is enough to make agent work reviewable without building a custom control plane. Put the block in issue templates, scheduled task descriptions, PR summaries, and automation outputs. Then add deterministic hooks only where the same mistake repeats.
The forward-looking bet is simple: the winning agent systems will not be the ones that hide humans best. They will be the ones that make the right human decision cheap, early, and based on evidence.