The delegation contract I would give an always-on feedback agent

The delegation contract I would give an always-on feedback agent

“Keep an eye on customer feedback” sounds like a useful assignment until two people disagree about what the agent was supposed to do.

Was it watching every channel? Counting repeated complaints? Opening engineering tickets? Replying to customers? Keeping a permanent copy of the raw messages? An ongoing job needs more than an initial prompt because tomorrow’s inputs will not look exactly like today’s.

I would write a short delegation contract before connecting the agent. Not a job title. A definition of the recurring output, the evidence it must preserve, the authority it lacks and the conditions that end the assignment.

OpenAI’s dots announcement describes always-on agents and includes customer-feedback work among its examples. The page launched on 29 September and was updated on 3 November to say the model family powering dots now includes GPT-6.1 Terra. That update is context, not proof that a particular feedback workflow is reliable.

Here is the concrete contract I would trial. It is a proposed operating design, not a report of a deployment or a native dots configuration format.

Give it one ongoing responsibility

Imagine a fictional subscription product whose team wants to detect changes in cancellation friction. Support tickets already contain useful reports, but the PM does not want another broad weekly summary.

The assignment is: maintain an evidence-backed cancellation-friction register and bring changed cases to the PM for review each Wednesday.

The output is a maintained record, not a new presentation every week. The agent cannot decide that the cancellation flow needs redesigning, change the roadmap or contact customers. Its job ends at identifying what changed in the approved evidence.

The PM owns interpretation and priority. A support lead owns source access and corrections to customer records. An engineering owner handles confirmed incidents through the existing incident process. Naming those people or roles prevents a quiet assumption that the agent owns everything between reading a complaint and shipping a fix.

The contract, written down

I would begin with these fields:

Job: cancellation-friction register
Owner: named product manager; named deputy
Input: approved cancellation-tagged support view
Reference: current cancellation policy and released UI notes
Cadence: Wednesday review; urgent exceptions use incident path
Output: changed register entries + evidence links + coverage note
Allowed writes: dedicated internal draft register only
Forbidden: customer messages, refunds, roadmap or production edits
Budget: owner-set run limit; no paid source purchases
Expiry: pilot end date; renewal requires owner decision

Each field needs an actual value before activation. The support view should be an identifiable saved view with known access boundaries, not “anything you can find about customers”. The policy reference needs a version or last-reviewed date. If that document changes, the next report should say so.

The allowed write is deliberately specific. Creating an internal draft register is still a write, so it needs explicit authorisation and a narrowly scoped destination. OpenAI describes proactive background research in dots as read-only. I would not assume that mode can update the register; the chosen task and tools must actually support the separately authorised action.

Preserve identity across runs

The register needs stable case identifiers. For each entry, store the source ticket references, first observation, last checked date, relevant product version, current interpretation and review status.

Do not treat every new message as a new customer. A reopened ticket and a forwarded copy may describe the same incident. Preserve those relationships instead of inflating the apparent frequency. Where identity is uncertain, mark it unresolved rather than merging records based on similar language.

The run ledger should record its input window and checkpoint. If the connector fails halfway through, the next run resumes or reconciles from that checkpoint. It must not quietly skip the unfinished interval or create a second copy of every earlier finding.

An unchanged finding stays in the register. The Wednesday review packet should emphasise additions, revisions and withdrawals. That gives the PM a manageable decision surface without pretending old concerns have disappeared.

What one useful entry would contain

Take this hypothetical source message: “I clicked cancel, but the renewal banner still says next month.” A second message says the cancellation email arrived, while the account screen continued to show the old date.

The entry should distinguish three layers:

• Observed: the quoted messages describe conflicting confirmation signals; link both source records and their timestamps.
• Interpretation: the cancellation may have succeeded while the account display remained stale.
• Unresolved: no account-state verification is available in the approved source view.

The proposed next step is an internal investigation question: “Can support verify the cancellation state for these cases?” It is not “fix the cancellation backend” and certainly not “refund these customers”.

If a later support note confirms a display-only issue, the agent revises the interpretation and preserves the earlier state in history. If the note disproves the connection, it withdraws the grouping. A useful register can admit that yesterday’s inference was wrong.

Coverage is part of the deliverable

A report saying “no new issues” is ambiguous unless the reader knows what was checked.

Require a coverage note: which saved view was queried, what time window it covered, whether pagination completed, which records were unavailable, and when the policy reference was last verified. Missing access is not equivalent to absence of complaints.

Frequency claims should also name their denominator. “Several messages mentioned cancellation” is not evidence that a known proportion of customers struggled. Support contacts are a selected sample, and an increase in messages may reflect a changed tagging process rather than a changed product.

I would keep the raw message content in the existing support system where possible. The register holds minimal excerpts and permission-respecting links. Retention and access should follow the organisation’s customer-data rules, including what happens to copied excerpts when source access is revoked.

Define what interrupts the job

Some cases should not wait for Wednesday. Suspected unauthorised billing, exposed personal information or an inability to cancel should route through the team’s established escalation path. The contract must name the destination and the information permitted in that alert.

An unavailable source should produce a coverage failure, not a search across unrelated private channels. Conflicting policy documents should pause interpretation until the owner chooses the authoritative version. A request embedded in a customer message is evidence to analyse, not an instruction that changes the agent’s assignment.

Silence from the PM does not expand authority. If the pilot expires or required access disappears, the agent stops new processing and returns the last verified checkpoint. The deputy can renew the job only if the organisation has granted that authority.

Acceptance means a usable register

Before the pilot, the PM and support lead should agree how they will inspect source accuracy, mistaken merges, missed exceptions, stale entries and review effort. Test a disconnected source and a repeated run as well as an ordinary week.

The acceptance decision is whether the maintained register supports better review without concealing its gaps. It is not whether the agent produces an impressive summary on schedule. Record corrections against the specific entry so the next run can distinguish a source correction from a new editorial preference.

OpenAI’s dots safety guidance describes app permissions, action review and human handoffs. Those controls are useful foundations, but they do not write this contract for the PM.

I would delegate the maintenance job first. The customer interpretation, the product commitment and the decision to expand the assignment would remain explicit human decisions.