Give concurrent agents separate files

Two agents can each make a correct change and still produce an unusable combined result. One renames a field while the other writes code against the old name. Each local explanation is reasonable, and the conflict appears only when somebody tries to use the two changes together.

When I specified multi-agent work for Kelpie, the document application, in January, I assigned the intertwined foundations to one agent. Two other agents would work concurrently after those foundations were complete, without changing the same files. That is a documented coordination requirement, rather than proof that the planned arrangement ran successfully.

Separate file ownership gives each worker a defined set of files to change, even when all workers can access the same directory. Every worker may be able to see the same files, and every edit can change what another worker encounters. The permissions granted by a tool also may be broader than the assignment, so the assignment has to state its own limits.

Draw the ownership boundary around a real interface

Consider an illustrative application with a document editor and a PDF exporter. One worker owns the editor component and its tests. Another owns the export module and its tests. A coordinating worker owns the document schema that both components use.

The schema needs to exist before the two workers begin. It specifies which fields identify the document, how diagram content is represented and how edits are passed to the exporter. Without that common definition, disjoint filenames merely allow the workers to build incompatible systems without encountering a merge conflict.

Give each worker the exact interface and the files it may change. Also name the files it may read but must not edit. A worker that discovers a missing schema field should send the proposed interface change to the coordinator, explaining which behavior requires it and what consumers would be affected.

That communication costs time. So does integrating two incompatible implementations, usually after both have accumulated more code. The purpose of ownership is to make the shared decision visible while it remains small enough to review.

At handoff, have the editor worker save an example document using the shared schema and have the exporter worker consume that saved example without translating it manually, because a manual translation can conceal the disagreement that the integration test needs to expose. If the document fails validation, preserve the failed input with the schema version and return the mismatch to the interface owner before either worker revises the contract independently.

Keep the integration operation owned

Suppose the editor worker adds a revision identifier to its output. The exporter worker has already completed its implementation against the earlier schema. The coordinator should not quietly copy the new field into the shared definition and assume that the work remains compatible.

Instead, update the contract deliberately, tell both workers which version applies and rerun the interaction that depends on it. The editor must supply the identifier correctly, and the exporter must either consume it or explicitly ignore it without corrupting the document.

A useful integration check starts with the editor’s actual output, which the reviewer passes into the exporter without a hand-written translation, then follows that document through the export operation and opens the resulting file to inspect it. This catches disagreements that separate unit tests can miss when each worker invents its own convenient example.

Watch for shared files hidden outside the feature directories

Ownership often fails in configuration files. Two workers can remain inside their assigned source directories while both changing a dependency manifest, a lockfile or the same test configuration. Those files affect the entire project and need an owner as much as the visible feature code does.

Generated files also need an explicit rule. If a build rewrites a shared index, either centralize that build step or arrange isolated working copies with a controlled integration process. Do not ask workers to infer whether an unexpected change belongs to another worker or is safe to replace.

The review should finish with an account of what each worker changed and which shared interactions were exercised. Separate file ownership reduces one class of collision; it does not establish that the combined application works. In the editor-and-exporter example, the parallel tasks are ready for acceptance only after the edited document passes through the real export path and the reviewer opens the resulting PDF.

Source notes

Drew Wiberg, Kelpie multi-agent specification, 20 January 2026. Contemporary author record; establishes the proposed ownership and sequencing policy.

Worked examples and review procedures in this article are instructional applications, not additional historical project results.