Conway's Law still holds

Systems mirror the organisations that build them.

Melvin Conway observed it in 1968: an organisation designs systems that copy its own communication structure. Every team boundary becomes an interface, and every interface has an owner.

That's not a technical problem to engineer away. It's how large software gets built at all. A feature someone asks for in one product usually needs a change in a service another team owns, a library a third team publishes, and something from a vendor nobody here controls.

So planning a real feature isn't purely technical. It's working out who owns each part, and coordinating with them.

An agent optimises for the repository it's standing in.

Ask an agent for a feature and it will find a way to deliver it from where it is. If the data it needs belongs to another team, it reads their database. If the API doesn't offer a field, it scrapes one. If a capability is missing, it rebuilds it locally.

Each shortcut works. Each one is the local optimisation that grows a jungle, except now the jungle spans repositories, and the team that owns the real thing doesn't know your copy exists.

Every repository declares what it owns, and what it doesn't.

At Camunda, each repository carries an ARCHITECTURE.md with a small, machine-readable front matter. It says what the component owns, what people commonly think it owns but doesn't (with the real owner), what it depends on, and how other teams should ask it for changes.

Each dependency also says how far you may go to work around it. For most, the answer is never.

It's written for humans first and structured enough for any agent to read. It's the same idea as derivation: declare the facts once, where they live, and derive plans from them.

Find the owner of each capability, transitively.

Our planning skill starts by rewriting the feature as capabilities: “The system must…”, without naming any repository. Naming one too early decides the owner before anyone has looked.

Then it follows depends_on to each dependency's own ARCHITECTURE.md, and onward, to find whoever is the source of truth. Owned here: plan it here. Owned by another team: write that team a requirement brief. Owned outside: use the extension points it offers, behind an adapter.

Speed never outranks ownership.

Before options are compared, five hard gates rule some out. An option that fails any one is gone, however fast it would be.

The survivors are ranked in order: architectural integrity first, then constraints, then delivery. The tiers aren't added up, so a workaround here can never outscore asking the owner. A deadline is a reason to cut scope, or to agree a temporary contract with the owner, with its replacement already planned. It's never a reason to build their part in your repository.

The coordination is part of the plan, not an afterthought.

The plan is a structured Markdown file, iterated in a pull request that's reviewed but never merged. Every part has an ID, so other plans can refer to it across repositories.

A brief goes to the owner the way the owner asked: through the intake in their ARCHITECTURE.md. Increments that need it are marked blocked by it. The owner answers each need in their plan, so they decide how to build it, not you.

Design and breakdown are separate phases. No issues are filed until the team and every owner it relies on have agreed the design.

A planning skill is code. Test it like code.

A validator checks every plan mechanically: IDs resolve, a permanent workaround is never chosen, “build it here” is only used for capabilities this repository owns, increments have no cycles, the diagram matches the tables, and each brief matches the plan.

And the skill itself was developed against evals: scripted scenarios run by agents and scored by separate grader agents against fixed rubrics. Each round's findings were fixed in the skill and checked in the next round.

From 51 graded runs on one real feature. Some scenarios haven't been run yet.