When can a human approval become a rule for future agent tasks?

Does approval today authorize the next task?

A person approves an invoice prepared by an AI agent. Another invoice arrives from the same supplier next month. That earlier decision does not establish permission to proceed: the amount or bank account may have changed, or the approval may have covered a one-time exception.

Agent products address part of this problem. OpenAI's Workspace Agents announcement describes organization-controlled access to tools and data, with approval for selected actions. It does not establish an end-to-end process for converting one approval into a business rule for separate future tasks. OpenAI announcement

This article proposes that missing process: record a human decision, test the conditions under which it can be reused, and activate only rules approved by an accountable owner. We call this design proposal a Human-Agent Collaboration Workspace (HACW). It is a working hypothesis, not an established standard or a product category with demonstrated benefits.

A decision record and an execution rule answer different questions

A decision record explains why an action was approved. An execution rule specifies which conditions a new request must meet, whose authority applies, and which action is permitted. Finding a previous decision does not answer all of those questions.

The OpenAI Agents SDK can interrupt a tool call and resume after approval or rejection. This controls an operation in a running task. Approval documentation AWS AgentCore Policy evaluates tool access through Gateway against rules outside the agent's code. Policy documentation

These mechanisms support a distinction between receiving permission and repeatedly testing execution conditions. We propose a separate step between them: derive a candidate rule from the decision, test it, and have it approved. Connecting the products does not automatically supply that step. The business must define the conditions and accountable owner.

An invoice example with explicit exceptions

The following is a hypothetical design example, not a deployment report. A company processes a monthly contractual charge. For the current invoice, a reviewer checks the contract number, billing period, amount, and registered payment destination before approving it.

To reuse the decision, the owner specifies more than “allow invoices from this supplier.” The contract must be active, the amount must match, the billing period must not already have been processed, and the payment destination must be unchanged. The record identifies the contract version, approving owner, and rule expiry. Similar wording in two invoices does not establish those conditions.

• A matching invoice for an unprocessed period is a candidate for the rule.
• An excessive amount, changed destination, or previously processed period must not receive automatic permission.
• An unavailable contract or unreadable billing period returns to review instead of being guessed.

A developer turns the normal and exceptional cases into tests. The business owner reviews the results and scope before activating a versioned rule. Execution rechecks the target data and records the rule version and result. A contract change triggers another review; a discovered error must allow the rule to be disabled.

Automation extends only to operations the organization delegates to that rule. If payment needs separate approval, a successful invoice match does not waive it. Passing the tests also does not guarantee correct handling of exceptions missing from the test set.

Keep the records the next owner needs

The next person needs the invoice and contract, matching results, applied rule, and reason for any escalation. Preserve references to those records without requiring everyone to read an entire conversation. If several agents divide the work, assign responsibility for routing and integration. A task completed by one process does not inherently need another management agent.

Research supports carrying experience into later attempts. Reflexion evaluates agents that retain textual feedback and retrieve it for subsequent trials. Reflexion paper Better benchmark performance, however, is not authority to approve a company's payment. In this design, memory retrieves relevant decisions; approved rules determine whether an operation is permitted.

Test whether reuse saves work without increasing errors

Begin with the agent proposing a rule while people continue making the decisions. Record agreement, incorrectly permitted candidates, missed exceptions, and review time. Use those results to choose the automation scope, retaining sample review and rule withdrawal after deployment.

Fewer approval requests offer little benefit if rule authoring and maintenance consume more time than they save. Rare negotiations and rapidly changing conditions may be better served by keeping past decisions as reference material. The test of HACW is whether decisions with checkable applicability can pass into subsequent work without increasing misapplication.