Your coding agent wrote a Python tool. What happens on the second run?

The first run of a Python tool written by a coding agent can feel satisfying. The dependencies are installed, the command finishes, and the output files appear. Whether it organizes files, converts data, or generates reports, it seems to do the job.

There is another question worth asking: what happens if you run exactly the same command again?

Does it overwrite the previous results? Append the same data twice? Skip completed items and carry on with the rest?

“The command succeeded” does not answer any of those questions.

When handing an automation task to an agent, I like to include the second run in the requirements. It brings behavior into view that is easy to miss while getting the first run working.

Decide what running it again should mean

“Write a batch-processing script” sounds specific, but it still leaves the agent with several decisions.

If an output file already exists, should the script overwrite it, report a conflict, or choose another name? If one input is invalid, should the whole batch stop? If an input changes, can the previous result still be reused?

There is no single correct policy. A daily report might need to replace an older result. A tool organizing original documents might need to preserve existing files.

Leaving these choices unstated means the agent has to make them. If its assumptions turn out to be wrong, the implementation and its checks both need revisiting.

I would add a short behavior agreement to the task:

Preserve the input files and write results to a separate output directory. If a target file already exists, report a conflict without overwriting it. Record individual processing failures and continue with the remaining files. Report separate counts for successful items, conflicts, and failures. Return a nonzero exit code if any items remain unfinished.

Here, reporting a conflict is the chosen policy. Other policies are valid too. What matters is choosing one explicitly and making the implementation and checks agree with it.

One file mode can change the tool's behavior

Python's "w" and "x" file modes differ by one character, but their behavior is quite different.

Opening an existing file with "w" truncates it. The "x" mode creates a file exclusively and fails if it already exists. These behaviors are documented in Python's open reference.

For the policy “preserve existing results,” a small test can capture the requirement:

from pathlib import Path

import pytest


def write_result(target: Path, content: str) -> None:
    with target.open("x", encoding="utf-8") as file:
        file.write(content)


def test_rerun_preserves_existing_result(tmp_path):
    target = tmp_path / "result.txt"

    write_result(target, "first result")

    with pytest.raises(FileExistsError):
        write_result(target, "second result")

    assert target.read_text(encoding="utf-8") == "first result"

Save this example as test_output_policy.py and run python -m pytest -q test_output_policy.py in an environment with pytest installed.

The test checks a specific behavior: the first write succeeds, the second raises FileExistsError, and the original content remains intact. Pytest's tmp_path fixture provides a temporary directory for the test.

In an actual project, import the real writing function from the tool's module. Keeping a separate copy of the implementation inside the test would only test that copy. Testing the real function gives the agent a constraint that should survive later refactoring.

There is a limit here: "x" prevents overwriting an existing file. It does not guarantee a complete write. A failure after creating the file can still leave partial output, so recovery needs separate attention.

An existing file is not necessarily a completed result

A batch may stop after creating some output files. On the next run, “skip anything that exists” can accidentally skip unfinished work.

Before asking the agent to implement recovery, ask what it will use as evidence of success.

For structured output, that might include checking readability and required fields, along with the expected record count or the task's completion conditions. A CSV missing several rows can still open successfully. Readability alone is insufficient.

For a longer batch, the tool could record the outcome for each input and mark it successful only after writing and checking the result.

This does not mean every short script needs a task-management system. For a small, one-off batch, a clear list of successful and failed items may be enough. Persistent progress becomes more useful for tools that run regularly or process longer jobs.

Previous success records can also become outdated. Inputs change, and processing rules evolve. You need some way to identify which input and rule versions produced a result; matching filenames alone tells you too little.

During development, use temporary data to check three cases: rerunning after success, rerunning after an item fails, and rerunning with incomplete output already present. Inspect the actual results each time.

Recovery then has a concrete meaning: which results can be reused, which need processing again, and which require a decision from you.

Separate model-request retries from script reruns

So far, this is about running the finished Python tool. During development, a different interruption can occur: the coding agent's own model request fails.

The agent may already have edited the code and executed the script. The interruption might happen in the next round of analysis, after its tools returned their results.

Telling it to “start over” could execute that code again. If the script changes files, writes to a database, or creates resources, those repeated actions deserve a closer look.

There are two things to consider: how model requests recover, and how the agent recognizes work already completed.

The model service can handle part of the request recovery. At XylemNode, our Auto group selects request paths based on channel health and supports retries across groups when a channel fails. The caller continues using the same model name. Here, a channel means a path used to handle a model request.

For coding agents that support custom model services, this can reduce manual connection switching during development. The service connects to the coding tool, supporting the agent as it analyzes, edits, and checks the Python project.

Whether the script has already executed, and whether its output is complete, still needs to be established from tool records and actual files. Check that progress before deciding to continue verification or run the script again. This is where the rerun policy becomes useful during development too.

Include the second run in the handoff

For the next Python automation task, add something like this:

Alongside the normal flow, explain what happens on repeated runs, how existing results are handled, and how the tool recovers from an interrupted run. Verify these cases with temporary data while preserving the inputs. Finish by listing the checks actually performed and anything still unverified.

If the tool calls external services or writes to a database, check the effects of repeated execution separately. A file-writing test cannot establish correctness for those operations.

These requirements add some checking to the first delivery. They also make the behavior easier to anticipate when debugging, changing inputs, or handing the tool to someone else.

A dependable Python tool answers a few practical questions: where are the results, what remains unfinished, and what happens when you press Enter again? Making those answers explicit helps agent-written code become useful in everyday work.