← Back to blog

Why We Built File Ownership Enforcement

2026-02-15 • 8 min read • orchex team

The Problem

When you run multiple AI agents in parallel, they will try to edit the same files. Agent A adds a function to utils.ts. Agent B refactors the imports in utils.ts. The result? A merge conflict at best. Silent corruption at worst.

This is the fundamental problem of parallel AI execution. Every tool that claims "parallel agents" either ignores it (hoping for the best) or serializes writes (defeating the purpose).

We decided to solve it properly.

The Solution: File Ownership

In orchex, every stream declares which files it owns (can modify) and which files it reads (can reference but not modify). When the orchestrator applies artifacts back to your codebase, it enforces these boundaries:

  • A stream can only write to files in its owns list
  • A stream can read any file in its reads list
  • Unauthorized writes are rejected — not silently dropped, rejected with a clear error

This means parallel agents literally cannot corrupt each other's work. The safety guarantee is structural, not behavioral.

How It Works in Practice

When you define streams, ownership is explicit:

(See the orchex documentation for YAML stream definition examples.)

Stream auth-api can import from src/types/auth.ts (it's in reads), but if the LLM tries to modify that file, orchex rejects the artifact. Only auth-types can write to src/types/auth.ts.

Why This Matters

Ownership enforcement is what makes parallel execution trustworthy. Without it, you're just running multiple agents and hoping they don't collide. With it, you have a deterministic guarantee: same input, same execution boundaries, every time.

This is the difference between "fast and broken" and "fast and correct."