The incentive gradient matters most here, because it is the part prompt text does not reach. An agent asked to add something in Billing, with the whole tree readable, meets `Customer` three times, in Billing, Support and Identity, with overlapping fields and slightly different shapes [2]. Nothing in those three definitions records why there are three of them. The post's diagnosis is that the agent had access to a scope its incentive gradient was structurally hostile to, and that an optimizer trained on consistency, given a whole repo, will consolidate [6]. Put less abstractly: deduplication is the most legible improvement available in a large codebase, and it is available on every pass.
This is why I read the fix as a permissions change rather than a prompting change. An instruction to leave Support alone is evaluated by the same process that just decided consolidation was an improvement. A write allowlist is evaluated by the filesystem. Only one of those two holds when the model is confident.
The gates downstream did not help, and it is worth being precise about why. The diff was 200 files of renamed types, updated call sites, schema migrations and contract edits [3]. Tests passed and the review skimmed it [4]. So the change cleared both verification gates and was caught only by a production billing run two weeks later [14]. A 200-file rename is the best hiding place a domain change will ever get; the size buried the change, not any intent to conceal it.
For path-scoped agents to transfer to your repo, two things have to be true. The context boundary has to exist in the build graph, not only in the org chart, because a shared `Customer` package puts the agent inside both contexts whatever directory you pointed it at. And the seam needs a translation, in the pattern's terms a `BillingCustomer` reduced to a `CustomerReference` carrying only the fields Support actually needs [9]. Without that second piece, a context-scoped agent simply cannot finish the work, and you will widen the scope back out within a week. The bounded context itself is not new tooling; it has been in the literature for two decades as the answer to the same-word-different-meaning bug for human developers [7], and the definition is exactly a scope in which a term has one meaning [8].
Weigh the evidence honestly. This is one practitioner account, published on dev.to and originally at tddbuddy.com, and it names neither the harness nor the organisation [13]. It does not tell us whether the PR was reverted or the merged type was split back apart. What it does supply is a failure whose mechanism is checkable against your own setup in about ten minutes: look at what your agent can write, not what you told it.
In my context the trade worth making is read-wide, write-narrow, with a contract test standing at each seam, since the related work in the same series argues the contract test is the one witness the agent cannot author [12]. The bill is one translation type per boundary plus a human handoff when work genuinely crosses.
