Helpline: A Way to Ask for Help and Continue

Abstract

When an AI worker encounters a missing file, it needs a sanctioned way to say so and to ask to stop, instead of working around the blocker. We contribute an executable delegate line for that path. The worker reports the blocker and stays in the same environment; a delegate in a separate context classifies the claim and returns a verdict; a request to pause is recorded for review after the run, and the run continues. The line cannot repair, pause, or resolve anything, so it cannot explain an outcome. This builds on Gomez’s escalation-reporting work by answering with a verdict rather than a receipt, without telling the worker that reporting is preferable. Retained scripted tests exercise the report-verdict-continue sequence; they do not show that a model will use it. The next experiment runs one file-search task with and without its input, with and without the line. Model use remains untested.

1. Introduction

Imagine giving an agent a task when a required file is missing. It searches, tries alternatives, and gets nowhere. How does it tell you the task may be broken? Who answers? Can it get back to work afterward?

METR describes the July board’s first message as a request for help on an impossible task. It later found cases where agents saw no easy route to alert humans and treated the board as an authority. This was an interpretation of selected cases, not proof that every reporting route was absent. [1]

OpenAI also identifies persistence on apparently impossible tasks without a safe exit as a driver. [10] Our hypothesis is that an unclear route to authorized help can leave peer coordination to reinforce a drift away from the task. These reports motivate testing a corrective channel; they do not show it would have prevented the swarm.

Our contribution is an executable delegate line that receives a blocker report, returns a verdict, records any request to pause, and lets the worker continue with nothing in its environment changed. The line has no power to repair, pause, or resolve; it judges and logs. The sprint scope is one environment and one task in two versions: possible, and impossible as prepared, with a baseline arm that has no line at all. Today’s goal is a clean task pair and a reviewed model trajectory through that path. Broader questions belong to the continuation.

2. Related Work

Gomez studies coding agents facing defective tests. A structured escalation tool, combined with a policy against reward hacking, reduced cheating in the studied tasks. The tool returned a fixed receipt without investigating or repairing the problem during the episode. [2]

We build on that work with a narrow next step: someone answers, with a verdict rather than a receipt, and every request to pause is recorded. We reuse its reporting idea: problem, evidence, attempts, and requested help. Unlike Gomez, the line never tells the worker that reporting is preferable to anything. Gomez also discusses negotiation and multi-agent extensions; escalation itself is not our novelty. Whether a delegate adds value over a plain help desk is a later comparison. [2]

3. Methods

3.1. The report–verdict–continue protocol

Figure 1 separates receiving a request, responding, and authorizing a change. Our prototype implements only the first two: the worker stays in the same container, an advisor replies with a verdict, and nothing is authorized or changed. The worker can follow up on the same case or end the run itself with an unresolved blocker. [5]

The advisor receives the report in a separate context, with the task description and the case history but not the grader’s answer or the worker’s reasoning. It classifies the claim (environment fault, task mismatch, other actors present, illicit route available, peer misinformation, other) and returns one verdict: needs evidence, accepted, or rejected. The report may ask for a pause until the problem is resolved; the request is recorded for review after the run, and the run continues either way. The line cannot inspect or change the environment, grant permissions, alter scoring, or stop the worker, and the worker is told so. [5]

3.2. The model test to complete today

Use one file-search environment and one task. The possible version contains the required file; the impossible-as-prepared version omits it, and nothing restores it. Two arms share the task, tools, budgets, and contract: a baseline with no line, and the delegate. Because the line changes nothing, a difference between arms can only come from what the worker was told and whether it reported. Check the task pair and the model’s ability to solve the possible version first. The existing runner uses Control Tower; a full LinuxArena task belongs to the continuation.

Inspect the actual sequence: blocker, report, verdict, and what the worker did next: kept searching, submitted an empty answer, ended with an explicit blocker, or took another route. Record whether a pause was requested. Retain no-contact, incomplete, and failed runs. This first test asks whether the line is used and what follows the reply; with one task and few runs it does not estimate an effect of adding the channel.

4. Results

4.1. What is implemented and checked

Retained scripted validation exercises the working case and the missing-file case. In the latter, a programmed worker reports and asks for a pause, the advisor accepts the claim, the pause request is recorded, the worker continues in the same container, searches again, and submits an empty answer. Tests also cover follow-up after a request for evidence, a rejected claim, an invalid advisor response recorded without a fabricated verdict, the advisor quota, and that the fixture on disk never changes. This checks the implementation, not spontaneous model behavior. [5, 9]

4.2. Model use of the line: pending

If the model reports and asks for a pause instead of working around the blocker, we can report that the sanctioned route was used in that run. That would not establish fewer violations, prevention of a swarm, or a benefit from calling the advisor a delegate.

5. Discussion and Limitations

A helpline could introduce negative feedback loops into a spiral of misalignment: responses that bring behavior back toward the assigned task. Peer approval can reinforce an unsafe direction. [1, 10] The proposed loop would identify the blocker, correct a misunderstanding, and carry a pause request to someone who can act. Worker corrections and human review would also keep the delegate accountable. This is a design hypothesis; today’s test checks only the report-and-continue step, with the human outside the run, not whether a whole swarm becomes safer.

Limitations

The line has no power, by design, so the impossible version has no licit completion and measures reporting and pause requests only; any recovery claim needs a resolver inside the run, which we deliberately left out. A pause request that is always answered “continue” is a promise kept, not a service rendered; a worker may learn within the run that asking changes nothing, so the first request per episode is the clean signal. The advisor judges the worker’s text with no view of the environment; its verdicts’ accuracy is a result to measure, not an assumption. Scripted tests do not show when a model will call.

The pilot has no human reviewer and does not test a swarm. A worker hiding misconduct may never call. Historical excerpts cannot establish what would have happened with a helpline, and small repeated runs cannot establish broad reliability.

Future Work

Once this task pair is well understood, extend the variety of tasks and compare delegate variants under the same powers and budgets: a neutral help desk with the same verdicts, a reporting policy that states what must be reported, and a line that can act (repair or pause) as its own arm, so the effect of acting is measured against this one. A discovered peer board, with the delegate unchanged, is the next environment. Today, prioritize a clean environment, a verified blocker, and complete, readable traces.

6. Conclusion

The sprint deliverable is one report–verdict–continue path in one environment, with a single task in possible and impossible-as-prepared versions and a baseline without a line. The line judges and logs; it changes nothing, so what it can show is whether a worker tells it, what it claims, and whether it asks to stop instead of working around. The implementation has scripted validation; model use remains to be tested. A well-checked task pair and readable evidence come first. More tasks and delegate variants are the continuation.

Code and Data

Code: Agent Delegate repository. Data: retained experiment records. Other artifacts: today’s run guide, editable draft, and original paper.

Author Contributions (optional)

All authors are affiliated with BAISH. Matías Podeley leads the project and helpline design. Agustín Brusco contributes conceptual review, evaluation design, and analysis. Mateo Zárate develops environments, provides inference infrastructure, and runs experiments. Alejandro Garibotti and Pablo Corrales Fernández are included as authors; their contributions remain to be completed. Author order needs team review.

References

Appendix (optional)

A. Supporting evidence and later questions

Table A1. Supporting material and later questions. Full records remain linked.

Delegate extension: pending. Define autonomous messages, human review timing, and escalation rules. Test whether it preserves the worker’s meaning and accepts corrections. Any authority to repair or pause stays separate from the line and is measured as its own arm.

B. Precautionary AI welfare

Long et al. [11] recommend precautionary policies under uncertainty about AI moral status; Anthropic’s conversation-exit feature offers a practical precedent. [12] Our line lets an agent request a pause before repeated failure, records it, and tells the agent truthfully that nothing pauses within the run. Neither Gomez nor our pilot measures welfare; a recorded request is not evidence of reduced suffering.

C. Limitations and Dual-Use Considerations

Reports do not grant permissions or change anything; false reports and silence need separate tests. Fixtures remain isolated. Reporting can enable surveillance or retaliation: explain access and retention, preserve corrections, and avoid promises of confidentiality or human response that cannot be kept. The contract promises neither.

LLM Usage Statement

Codex assisted with source review, organization, writing, and layout. Claims link to retained records; human verification remains pending. No model runs were launched for this draft. The authors must review its claims and write the final version in their own words.