Tactical Pause: One Agent, Two Roles, One Window

How the same agent can run a live workflow, stop when either of us sees a problem, help me change the system, then go back to work without leaving the conversation.

What this article covers

The evening a logistics system finally exposed a database mismatch that had survived about a week of revisions.
Why either the human or the agent should be able to call a tactical pause.
How one agent can switch from executor to technical partner and return to execution in the same window.
What research on mixed-initiative systems, live programming and interactive code generation says about this way of working.
A practical prompt for defining stop conditions, authority and the before-and-after check.

Full article

For about a week we couldn't understand why a dispatch system for collecting and analyzing freight orders kept producing the wrong result.

The data and the fields were there, and each part looked reasonable when we inspected it alone. But the database and the analysis didn't agree, and the error survived a string of builds, roughly from version 0.5 through 0.8.

Then one evening I opened the project in Codex and stopped looking at it as a pile of files.

I could see the product running. I could see the database fields, the code, the logs, the result coming back from the analysis. The agent was doing the actual job: pulling freight orders, connecting records, calculating values, separating one type of load from another. And above that running process, in the same window, I had the same agent available to discuss what it was doing.

This is where it got interesting.

Sometimes I saw the mistake first. I would tell it, stop, the database and the analysis don't match here, look at these fields.

But the more surprising path worked the other way around. I had written stop conditions into the prompt. If a required field disappeared, if the schema didn't match, if a calculation moved outside the expected range, the agent wasn't supposed to push through and produce another confident answer. It had to stop.

And it did.

In effect, it said: look, I found an error. This field exists in the database, but the analysis isn't using it correctly. Let's fix it.

I looked at the proposed change and said no, the connection itself is wrong. Let's rebuild this part differently.

We changed the logic, ran the same case again and watched the result change. Version 0.9 worked.

That was the moment I sat there thinking: wow.

I know what I'm looking at. There isn't a little engineer hiding inside the model who suddenly became worried about my database. There is no consciousness there. It is generation, probabilities, context, tools and instructions. Fine.

But sitting in front of that screen, it felt like partner work. Either of us could notice the problem. Either of us could call the pause. Then we could inspect the same live state, change the system together and put the same agent back to work.

That is a very different experience from asking a chatbot to write code.

Either of us can call the pause

The comparison that makes sense in my head comes from strategy games.

The situation is moving. Units are moving, resources are being spent, something is already going wrong on the other side of the map. You hit tactical pause. Nothing disappears. Every position stays in front of you, but now you have time to inspect it, change the decision and continue from the same state.

The agent workflow felt almost the same.

The system runs. A mismatch appears. If I see it first, I say stop. If the agent detects one of the conditions I placed in the prompt, it stops itself and returns the initiative to me. We inspect the evidence, change the code, prompt, data contract or architecture, then run the same case again.

The loop is simple:

execution → either side detects a mismatch → tactical pause → joint change → execution again

The stop conditions give the agent a clear way to hand the problem back to me. We can work out what needs changing before the mistake spreads into the next operation.

The same agent changes roles

In execution mode, the agent is part of the product. It processes orders, reads the database, applies rules and produces an operational result.

During the pause, the same agent becomes my technical assistant. It reads the logs, compares fields, traces the connection, proposes a patch, changes the instruction or helps me rethink the architecture. I can accept the proposal, reject it or say the problem sits one layer deeper.

Then it goes back to execution.

This detail matters. I am not copying an error from a product into a separate ticket, reconstructing it for another developer, opening a new chat and trying to explain what happened five minutes ago. The working history is already there. The agent that just ran the workflow has the code, the terminal output, my decisions and the failed result in context.

Technically, the model isn't rewriting its own weights. It is changing the working system around it: code, prompts, configuration, tests, schemas, queries and connections between components. From my side, the collaboration remains continuous: the same agent, the same project, the case we are already looking at.

One window changes the conversation

What made that evening useful was how little I had to reconstruct. The product, code, fields, and logs were in front of us. When I questioned the connection, we could inspect it in the same working context.

The OpenAI documentation describes the pieces of that environment: an integrated terminal for running commands and inspecting output, and a built-in browser for looking at the website or local application together. Its macOS telemetry workflow goes through a related sequence: add diagnostic events, run the application, observe someone using it, read the logs, then propose a patch. That is close to the part I found useful. The next change starts from something we can see happening.

There is an older research connection here. In Supporting exploratory data analysis with live programming, 15 data professionals worked with edits that updated results automatically. Participants largely preferred the responsiveness, and the recorded live sessions contained fewer errors than the comparison histories. They also missed a visible history. In my workflow, both matter: I can see the current result and return to the conversation that explains why we changed it.

The pause gives each of us a turn

Researchers call the broader idea mixed-initiative interaction. Eric Horvitz's 1999 CHI paper describes combining direct human control with automated reasoning: the person can guide and correct the system, while the system can take on work and surface a useful next step.

The useful detail for me is that initiative can move. I can stop the run because the visible result looks wrong. The agent can stop because it has found one of the conditions I defined. Neither of us has to wait for the whole process to produce another bad result.

The 2019 Guidelines for Human-AI Interaction include efficient correction, clear global controls, and visible consequences of user actions. The work included evaluation of 20 AI-infused products and a study with 49 design practitioners. In our case, those ideas have a very concrete form: stop, decide what to change, rerun, see the consequence.

Grounded Copilot, a 2023 OOPSLA Distinguished Paper observing 20 participants across four programming languages, describes acceleration and exploration. Sometimes the programmer knows the next step and wants help doing it; sometimes the programmer needs help examining the options. Our pause moves between those situations. The agent executes, we investigate together, then it resumes the changed process.

The 2025 CHI paper Need Help? Designing Proactive AI Assistants for Programming also treats programming context as a shared workspace for more relevant suggestions. That helps explain why the same conversation mattered to me. We could point at the field and its use in the analysis, without rebuilding the problem from a description.

What another run can show

The agent's first proposal was useful even though I rejected it. It showed where to look. I thought the connection itself needed to change, and the next run let us test that decision.

There is evidence for the value of that kind of correction. In LLM-Based Test-Driven Interactive Code Generation, 15 programmers used tests to clarify intent. They were significantly more likely to evaluate generated code correctly and reported lower task-induced cognitive load. A separate large-scale evaluation used idealized feedback: average pass@1 accuracy improved by 45.97 percentage points within five interactions across four models and two Python datasets. That number belongs to the idealized evaluation, so I would not use it to predict the gain in my project.

Let's Fix this Together: Conversational Debugging with GitHub Copilot studied 16 industry professionals. It gathered context before responding and supported turn-taking. Against the prior AI-assisted debugging experience in Visual Studio, it reported a 2.5 times improvement in bug localization and a 3.5 times improvement in bug resolution.

Those are specific systems and controlled tasks; version 0.9 is one personal case. What connects them for me is the chance to examine a proposal, correct it, and see the effect of the correction. I want that opportunity built into the way the agent works.

The prompt needs two modes and a real stop

I now think the agent should receive two explicit operating modes before the run begins.

In execution mode, it performs the agreed function. In tactical pause, it stops further execution, preserves the current state, shows the evidence and waits for a decision on changes that affect architecture or business meaning.

The transition can start from either side. I can call it when the visible result looks wrong. The agent can call it when it hits a defined condition.

Here is the practical version:

Work in execution mode. If I say "pause," or if you detect a schema mismatch, a missing required field, a failed test or a result outside the defined range, stop and enter tactical pause. Tell me directly that you found an error. Show the observed facts, name the likely cause and propose options. Do not change architecture or business rules without my decision. After the approved change, rerun the same scenario on the same input and show the result before and after.

The stop has to be real. An agent that reports an error and continues processing has not paused. It has added a warning to a bad result.

Pausing this agent doesn't freeze external services or other people working on the system. Keep an input snapshot for the comparison, then check the current external state before resuming live work.

The rerun matters too. If the input changes, the database changes and the code changes at the same time, you don't know what fixed the problem. Use the same case. Keep the evidence. Compare before and after.

What I mean by partnership

There is a shared object in front of us. The agent can act on it. I can inspect what it did. Either side can trigger a stop. During the pause, the agent contributes technical analysis and I keep authority over architecture, business meaning and whether we continue. Then the agent acts again and we both see the consequence.

What I liked was being able to stay with the problem while it changed. We could discuss the connection, try another version, and see what happened in the running product.

That evening we pressed resume. Version 0.9 used the field correctly and the analysis finally matched the database.

I knew exactly what I was looking at.

I still said wow.

Practical takeaways

Give the agent an execution mode and a tactical-pause mode before it starts.
Let either side initiate the pause. The human can call it from the visible result, and the agent can call it from prompt-defined conditions.
Define observable stop conditions: schema mismatch, missing field, failed test, unexpected record count or a result outside a known range.
During the pause, allow inspection and proposals. Keep architecture and business-rule changes under human authority.
Rerun the same scenario on the same input and show the result before and after.
Preserve the conversation, logs and change history. The shared state is what makes the loop work.

In brief

The same agent can execute a live workflow, stop and help change the system, then return to execution in one conversation.
A tactical pause can be initiated by the human or by the agent under conditions defined in the prompt.
The feeling of partnership comes from shared context, turn-taking, visible evidence and the ability to affect the same running object.
The rerun makes the effect of the joint change visible in the working product.

Sources

Eric Horvitz. Principles of Mixed-Initiative User Interfaces. CHI, 1999.
Saleema Amershi et al. Guidelines for Human-AI Interaction. CHI, 2019.
Shraddha Barke, Michael James, Nadia Polikarpova. Grounded Copilot: How Programmers Interact with Code-Generating Models. OOPSLA, 2023.
Sarah Fakhoury et al. LLM-Based Test-Driven Interactive Code Generation: User Study and Empirical Evaluation. IEEE Transactions on Software Engineering, 2024.
Yasharth Bajpai et al. Let's Fix this Together: Conversational Debugging with GitHub Copilot. IEEE VL/HCC, 2024.
Valerie Chen et al. Need Help? Designing Proactive AI Assistants for Programming. CHI, 2025.
Robert DeLine and Danyel Fisher. Supporting exploratory data analysis with live programming. IEEE VL/HCC, 2015.
OpenAI. Integrated terminal.
OpenAI. Built-in Browser.
OpenAI. Add macOS telemetry and inspect live app logs.