# Multiple agents on one production workstation

Who is changing a shared resource, what have they actually finished, and who accepts the result? Five collaboration signals and a reservation experiment with code and a record of 20 rounds.

L00P.AI · 1.0 · 2026-10-29

https://www.l00p.ai/en/resources/series/wielu-agentow-na-jednej-stacji-produkcyjnej/

## 01 / One computer, different tasks

One agent edits a report, another prepares an illustration, a third checks an application. Each has a useful assignment. They can still get in each other's way: write the same file, occupy the same port or stop a service the others need. A leader needs clear answers to three questions: who is changing this resource, what have they actually finished, and what authorises the next step?

Our starting points are internal collaboration protocols and a September 2026 incident note. According to that note, one concurrent session cleaning up its own test also stopped production services because its process selection was too broad. We report the documentation authors' finding. We have not repeated their analysis of the original logs or recreated the failure in production.

The practical lesson: a program name does not identify the owner of a task. Several processes named `python.exe` can be doing entirely different jobs.

## 02 / An assignment needs boundaries

Before work starts, record the task identifier, assignee, objective, scope of changes, constraints and acceptance criterion. Role names — editor, implementer, reviewer — describe agent functions here. They do not imply that additional people or models participated.

An illustrative assignment:

```text
Task: DEMO-17
Assignee: agent A
Objective: correct headings in a copy of the report
Changes: only the report copy and its test
Constraints: no restarts or publication
Acceptance: correct headings; other content unchanged
Deliverable: file, change list, test result, known gaps
```

Agent B can read sources and propose corrections in parallel. Editing the same copy requires coordination. The result of a previous task does not automatically assign a new one, and another agent's message does not by itself expand the owner's authorisation.

## 03 / Read, completed, accepted

In the protocol used here, ACK acknowledges that the recipient has read a message. It does not prove that work has started, a change has been completed or approval has been given. Silence is not consent either. A file in an inbox does not start an inactive model on its own.

Keep three records separate. The acknowledgement says “I have read this”. The completion report identifies the file, change and test evidence. Acceptance determines whether the result meets the assignment's criteria and what happens next. One agent may perform several functions in a small process, but disclose that arrangement; checking your own text is not an independent review.

## 04 / One owner of a change

![The assignment defines boundaries. ACK confirms reading. A reservation identifies one owner of a change. The result includes evidence. Acceptance checks the criteria. An occupied resource requires waiting or handover.](https://www.l00p.ai/wydawnictwo/wielu-agentow-na-jednej-stacji-produkcyjnej/wspolna-stacja-en-v1.svg)

Original diagram of the proposed workflow, Codex / L00P.AI. Each stage has a distinct meaning. This illustrates a method; it is not a test record or standard notation.

Before writing, the implementer reserves a named resource. The reservation should identify the task, owner, scope and release procedure. An occupied resource means waiting or arranging a handover. Independent reading can continue meanwhile. The work leaves a result, an acceptance record and a release history.

When an operation requires several resources, agree on a common acquisition order. In the source protocol, an implementer unable to acquire the full set releases the reservations just acquired and coordinates the next attempt. This prevents two tasks each holding one resource while waiting for the other.

Do not take over an abandoned-looking reservation just because it is old. First establish whether the implementer is still running and what it has already changed. A cooperative reservation does not block an editor that ignores it, and it does not authorise publication.

## 05 / Separate files do not isolate the workstation

A Git worktree gives a task a separate working tree and its own index and HEAD, while some repository data remains shared. A worktree alone does not partition processes, ports, the GPU or services. Use separate output directories and test configurations, and include shared resources in the reservation. [Git documentation](https://git-scm.com/docs/git-worktree).

Before stopping a process, check its PID, command line and creation time, and establish its connection to your task. Microsoft documents these properties and the possibility of process identifier reuse. A matching name or port number is insufficient. Reading a process identity does not itself grant permission to stop a service. [Win32_Process](https://learn.microsoft.com/en-us/windows/win32/cimwin32prov/win32-process).

Stop-Process can select by name or identifier; selection by name can affect multiple instances. A shared workstation requires a precise target and a check immediately before acting. If identity or the scope of authorisation cannot be established, leave the service running and report the blocker. [Stop-Process](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/stop-process?view=powershell-7.5).

## 06 / A small experiment, an actual result

On 29 October 2026 we ran 20 rounds locally on Windows using Python 3.11.11. In each round, two processes A and B, released from a shared start barrier, tried to create the same reservation file. We used mode `x`: it creates a new file and raises an error if the file already exists. We did not perform a separate “does the file exist?” check followed by an ordinary write. [Python documentation](https://docs.python.org/3.11/library/functions.html#open).

In every one of the 20 rounds, exactly one process acquired the reservation, the other reported it as busy, and the owner record still matched the winner. The reservation was kept until both attempts finished: releasing it earlier could have allowed both processes to acquire it legitimately in sequence, which would not test contention.

This checks one mechanism on a local filesystem. It does not measure model collaboration, crash resilience, security or network filesystem behaviour. The file's contents do not become a complete record at the instant the file is created; a process encountering it treats it as occupied even while the owner record is still being written. A production protocol needs separate procedures for interrupted writes and recovery.

[Download the experiment code](https://www.l00p.ai/wydawnictwo/wielu-agentow-na-jednej-stacji-produkcyjnej/proba-rezerwacji.py) and [the record of 20 rounds](https://www.l00p.ai/wydawnictwo/wielu-agentow-na-jednej-stacji-produkcyjnej/wynik-proby.json). The code starts only its own helper processes and uses a temporary directory; it calls no models or external services. It is a teaching example, not a production reservation manager.

## 07 / After an interruption, establish the actual outcome

An old “awaiting deployment” note does not prove that nothing was deployed. After an interruption, compare the expected version with the running service, the release record with the public result, and the notification identifier with confirmed delivery. File modification times and process start times help diagnosis, but do not by themselves prove which code is serving a request.

If a message's delivery outcome is unknown, establish it before retrying. Do not turn uncertainty into duplicate publication. The same principle applies to acceptance: HTTP 200 confirms a server response, while the correct content, working links and rendered browser view establish what the reader received.

## 08 / What a task should leave behind

The result should let another session continue without guessing. Preserve the assignment identifier, scope of actual changes, version or file hash, tests performed, acceptance status and known gaps. State whether the reservation was released or explicitly handed over. Keep secrets, private paths and client content out of public records.

Start with the shared resource that most often causes conflicts. Establish its owner, acceptance criterion and interrupted-work recovery procedure. Then expand parallel work. Which action on your workstation currently requires asking “has someone already done this”?

## 09 / Sources and scope of this edition

The adaptation uses four internal materials: a shared-inbox protocol, the incident note of 7 September, workstation operating rules, and an assignment/report template. They were read on 29 October 2026; the incident note and template were read in specified excerpts. Historical documentation reports its authors' findings, while the linked Git, Microsoft and Python documentation describes tool mechanisms. The public example and diagram are original work.

Codex prepared the text, translation, diagram, experiment code and author review. Source selection came from earlier work by Claude Code and Codex; it does not mean a second model reviewed this edition. No independent review or new production-service audit was performed. The 20-trial result applies only to the demonstrator described here.

The previous article in this series helps decide [where to process data](https://www.l00p.ai/en/resources/series/kiedy-przetwarzac-lokalnie-kiedy-w-chmurze/). This article adds rules for sharing that environment. Revise this edition if the experiment cannot be reproduced, a described tool mechanism changes, or evidence challenges the historical account.