HACW: helping people and AI continue the same work

An agent finishes the task, but someone still has to explain the context

Suppose a sales representative delegates customer research and a proposal draft to an AI. The next day, the team learns that the customer values implementation time more than cost, and another person takes over. If that person receives only the finished text, the original representative must explain why the team chose the proposal, which conditions remain unverified, and what needs changing. This is a hypothetical example for examining collaboration design.

An agent's ability to research with tools differs from the next person's ability to continue its work. People do more than issue a request and wait: they change goals during execution, create parts of an artifact, and compare conflicting evidence. Without a way to communicate those changes to the agent and the next owner, more automated execution can leave the explanation and repair burden intact.

This article uses product announcements and research available by August 12, 2026 to examine an environment for continuing the same work across people and agents. We call our design hypothesis a Human-Agent Collaboration Workspace (HACW): shared goals, ownership, artifact versions, evidence, changes, and human decisions. This is the author's proposal about which capabilities to connect and test, rather than an account of an established standard.

Execution across tools is already part of products

OpenAI's Workspace Agents announcement describes shared organizational agents using permitted tools and data, with approval for selected actions. A Rippling customer comment in the announcement connects account research, Gong call summaries, and deal briefs posted to Slack. The statement that this automates work previously taking representatives five to six hours a week is a customer report, not an independent time measurement.

The example shows a product expanding from answering questions to carrying a team's process across tools. The time report alone does not establish whether another owner can recover the research assumptions or how a person's correction carries into the next task. Once execution is connected, the sharing of work context still needs examination.

For the hypothetical proposal, the customer's changed priorities affect whether the team preserves only the cost table or researches the implementation sequence again. Before placing existing capabilities under one label, check whether a changed goal reaches the responsible people and artifacts. HACW starts with making that handoff work, rather than simply adding more executable actions.

People do more than provide the final approval

The first version of the CLEO paper examines delegation, direction, and concurrent work with an agent in a shared workspace. Its initial exploratory study involved ten professional designers; the two-day study of the revised CLEO also involved ten. These studies observe collaborative behavior, rather than comparing productivity across occupations.

In the first prototype, seeing the agent's process encouraged people to intervene, but the agent could confuse independent human work with corrective feedback and revert changes. The revised design emphasizes interpreting what human actions mean. Displaying an execution process and handling changes made concurrently by a person are separate capabilities.

In the proposal example, a person might revise the customer-facing introduction while asking the agent to research implementation timelines. Treating that edit as an instruction to rewrite the entire document could destroy the person's work. Participants need to share who owns which part and whether a change affects another task.

The Magentic-UI research report also presents a prototype for planning together, participating in tasks, and controlling selected actions. These are concrete examples of collaboration extending beyond a final permission gate. A research interface, however, has a different maturity level from an environment operated continuously across departments.

Read intervention results through what the study measured

The first Pista paper proposes splitting spreadsheet changes into steps, showing formulas, affected ranges, and downstream effects, and branching execution from a local edit. A person can question computational assumptions during the process instead of only inspecting a completed spreadsheet.

Its within-subject evaluation involved sixteen participants with Excel experience, twelve of whom were graduate students. Across two spreadsheet tasks, the baseline removed Pista's collaborative features and applied changes before returning a summary. The mean number of prompts was 2.19 with Pista and 4.00 with the baseline, a difference the paper reports as statistically significant. That count does not mean completion time or operational errors fell by the same proportion.

Our interpretation is that targeting a particular step may enable intervention without restating the whole job. Increased trust in a readable explanation still needs to be distinguished from a correct calculation. HACW should likewise measure the sense of participation, whether intent was reflected, and artifact accuracy separately.

HACW keeps shared records for continuing the same work

Our design shares the goal and unresolved conditions, current owner, permitted actions, adopted artifact version, evidence, checks, reasons for changes, and open issues. The aim is not to save every conversation. It is to let the next owner understand the current state and return to relevant original material. Even a solo user must hand work to their next-day self and agent.

The Copilot Pages announcement describes retaining generated content as an object people can edit, expand, and share. A shared document provides a basis for handing over an artifact. Collaborative text editing alone does not establish shared task ownership, execution authority, or the scope of a decision.

The first CHAP paper proposes a protocol containing workspaces, participants, tasks, artifacts, and an append-only evidence log, with a published specification and reference implementation. It attempts to structure handoffs and human changes rather than leaving them only in conversation. Such formats therefore cannot be described as entirely absent. The existence of a proposal, widespread adoption, and a working handoff between products are separate questions.

A record that detects tampering does not establish that the recorded decision was correct. Different access permissions may also prevent a receiving owner from opening the evidence. Design the record format together with the conditions that let someone use it to continue work.

Five roles do not imply five AI agents

We organize participants using shared records into five roles. This is our division of responsibilities, not a required product architecture. One person may set the goal and perform specialized work; existing programs may coordinate tasks and run checks.

The reason for distinguishing roles is not to add participants. The person who can change a customer's goal, the agent researching material, and the owner authorizing publication or delivery can decide different things. Even a system using one agent should preserve those distinctions in its records and permissions.

The scope of delegation can change during the work

Anthropic's agent design guide distinguishes workflows following predefined paths from agents whose models choose their own process, and recommends avoiding unnecessary complexity. With a stable sequence, sending input to an existing process may be easier to manage than asking an agent to decompose the task each time.

In its multi-agent research system, a lead divides research and integrates specialists' findings. The account also describes limitations for work requiring everyone to share the same context or involving many dependencies. Having independently researchable questions differs from integrating their answers into a coherent proposal.

For our hypothetical proposal, separate agents could research competing products, the representative could learn what the customer values, and both could revise the implementation sequence. New conditions may require stopping delegated research or rechecking a completed comparison. Delegation, joint creation, and handoff to a person should not be fixed permanently by the initial request.

Adding this coordination to every short routine task can create more record maintenance than useful work. In rare negotiations, a person may benefit more from reviewing past reasons than from replaying the earlier decision. Start testing HACW where work continues over time and intermediate changes or owner transitions actually occur.

Evidence alignment differs from permission to adopt the result

Anthropic's evaluation guide distinguishes an execution transcript from the resulting state of the environment and selects grading methods by task. Saying research was performed, supplying a citation, and actually verifying the required information are different achievements.

For a proposal, examine whether the material supports the statement, whether it is current, whether it applies to the customer's conditions, and whether the team may promise that result. A statement can match its source yet apply only to a particular configuration. Calculation and format checks may be programmatic, while missing conditions or competing priorities may require human judgement.

Permission to act is another check. AWS's December 2025 AgentCore Policy announcement describes checking tool calls through Gateway against policies. This illustrates control over execution conditions; it is not itself an evaluator deciding whether a proposal suits a customer.

When returning work to a person, send the artifact together with what was verified, which conditions are missing, and the requested decision. Also distinguish agent uncertainty from an action reserved to a person by the organization. The owner can then understand whether they are filling a research gap, selecting a goal, or authorizing an operation.

Turning today's approval into tomorrow's permission needs testing

Consider a hypothetical invoice example for reusing a shared decision record. A reviewer approves a monthly contractual charge after checking the contract number, period, amount, and registered payment destination. An invoice from the same supplier next month may still contain a change or follow a one-time exception. Finding the previous approval does not authorize a new operation.

For reuse, an accountable owner could propose a rule requiring an active contract, matching amount, unprocessed billing period, and unchanged payment destination. Record the contract version, expiry, and permitted action. Test the actual data against these conditions rather than treating similar wording as sufficient.

• Test excessive amounts, changed destinations, and duplicate invoices alongside ordinary cases; exclude them from automatic permission.
• Return to human review when the contract is unavailable or the period unreadable, rather than guessing.
• Activate only a version whose tests and scope the owner approved, with a way to revoke it after a contract change or discovered error.

If payment requires separate approval, successful matching does not waive that permission. Passing tests also does not establish correct handling of exceptions omitted from them. Decision reuse is one HACW capability; converting every human judgement into automatic execution is not its purpose.

Carry the adopted decision and its conditions into the next task

Reflexion evaluates retaining textual reflections derived from feedback for subsequent trials. It provides a research example of experience reuse, rather than a basis for granting business authority. Use prior records to find relevant candidates without replacing current instructions and permission checks.

For the opening proposal, retain why the customer prioritized implementation time, the adopted option, unfinished research, and the next owner's decisions. A search returning the old cost-first approach should not override the next day's correction. The proposal text, decision record, and future execution rule have different purposes and update owners.

A reader should be able to return to original material and inspect both a change and its affected conclusions. More retained information is not automatically better. Define what to keep, who corrects it, and when obsolete records are removed, so continuing work does not require reading the entire conversation.

Include the person's explanation and repair time in the test

Agent execution counts cannot measure HACW's benefit by themselves. Compare the same job using conventional conversation and file handoffs against a design with the necessary shared records. Include changed conditions and a new owner, then record restatements, use of outdated versions, lost conditions, and human repair time. This is our evaluation proposal, not a measured result for HACW as a whole.

Fewer review requests offer little benefit if record creation and rule maintenance consume more time. Displaying every action can increase reassurance without helping a person notice important changes. Test a view of changed conditions, conflicting evidence, and unchecked items, with access to original records when needed.

Our conclusion is that a collaborative environment should let people understand delegated work mid-process, revise it, and hand it to another owner. HACW organizes that requirement as shared goals, artifacts, ownership, evidence, and decisions. The next-day recipient of the proposal should be able to continue under the customer's changed conditions without asking someone to reconstruct yesterday's conversation. That is the state this hypothesis needs to demonstrate in real work.