Who owns the answer
Duplicate services and duplicate facts both fail quietly. The difference is that you can count the services. Nothing anywhere enumerates the facts, so the first person to find out can be a customer.
The argument
Every team that cannot get an answer keeps a copy of its own. That is a fork, the same as a forked component, except that nothing anywhere reports the divergence.
A person handles two conflicting answers by knowing who to trust. An agent has no such prior, so it does not hesitate. Which makes this an ownership question before it is a tooling one.
Two teams end up with two implementations of the same thing. Neither of them breaks. They run side by side and drift, and one day a customer is locked out of one channel and not the other, or two totals disagree. Nothing pages anybody for that. But the duplicates can at least be counted, and another note covers how they get there. Each has a repository, a deployment, a bill and a name, so an organization that decides to go looking will find them.
Now the same thing in the record. Support keeps its own description of how a feature behaves, because asking took too long and the release could not wait. Engineering changes the feature. Nothing reports that the two have drifted apart, and this time there is nothing to count either. No repository, no bill, no name. You cannot build the list. Nobody finds out until a customer is told something engineering stopped believing.
Why a person survives this and an agent does not
People carry an unwritten prior. Trust the team that owns a thing over the team that consumes it. Trust the recent page over the old one. Trust the person who actually wrote it. None of that is written down anywhere, and it is the thing that makes a scattered record workable.
An agent has none of it unless somebody encodes it. Handed two answers that disagree, it has no tie-breaker, so it will be wrong and it will not hesitate. It also pays that cost on every request rather than once, because every breakdown of a request pulls from whatever it can reach and reconciles them again.
Two tiers, and the second one is not authoritative
The shape that works mirrors the ownership already in place. Each part of the estate owns what it says about itself: what it does, how it behaves, how to use it. Above that sits a layer holding the things no single part can own, the decisions that span them, and those are genuinely owned there and are the real thing.
The same layer also carries a current-state view of everything underneath. That view is not authoritative and should never be treated as though it were. The parts are. It exists so that whoever is breaking a request down, a person or an agent, can see across the estate well enough to route it.
And the layer has to mark which of its contents is which. A person infers it from context and from tone. An agent reads a mirrored fact as a settled decision and acts on it.
None of this shape is new, and it still does not hold
Anyone who has run a service catalog has this already: an entry for each part, living as a file in that part's own repository, with a loop that re-reads them and refreshes the view. It works. The same shape, under an older name and fed by discovery rather than by files, has been in enterprise estates for a long time. So the argument here is not that somebody should build the thing. A reader who needs it can probably already point at one.
It is that the thing gets built and then is not believed, and the reasons are not tooling reasons. A part that writes down something wrong gets mirrored faithfully, and the wrong answer now travels further and looks endorsed. Two parts describing the same interface differently both qualify as saying what they say about themselves, so the mirror ends up carrying the disagreement, sourced and owned, with no rule for settling it. And the mirror only ever sees what somebody chose to publish.
Which is the caveat on the best part of this. A blank entry fails loudly only if something reads the blank. Left alone, a catalog fills with parts that have an owner and nothing else, and no one is paged for that either. Making absence loud takes an explicit completeness check with a threshold and a name against it. That is the machinery, and it is the part people skip.
What keeps it current, and what that costs
A job polls the parts for what changed since it last looked. The view is generated rather than written, and that is what makes "not authoritative" a property of the thing rather than a rule somebody has to remember. A central architecture document that people edit by hand is a fork with a better name.
The cost is that the view is always slightly behind. Between two runs it describes a system that has already moved, and a routing decision made inside that window can be wrong. The interval is an architecture decision rather than a detail.
And a mirror is not the only way. Where the parts can answer a query, the better answer is to compose the shape of the estate centrally and resolve the contents on demand, which has no staleness in it at all. What is centralized then is the map, not the state. Polling is what you are left with when the parts are of different generations and most of them cannot serve a query. That is a constraint, not a preference, and it is worth knowing which of the two estates you have.
Consolidated means addressable, not centralized
One warning about that word, because it is where this gets built wrong. Consolidating the record means one place to address, with each slice owned by whoever owns the thing it describes. It does not mean one team owning all of the knowledge. That team ends up owning everything and knowing nothing, and it rebuilds the middle layer this whole shape exists to remove. The consolidation is in the addressing, not in the authorship.
The part worth having, and it inverts the failure
A projection can only show what a part actually wrote down. So a part that documents nothing shows up blank. Compare that with the case this replaces, where the same gap gets filled by somebody else's copy: plausible, sourced from nobody, and true once. Same missing information, opposite visibility.
Both fail quietly. Only one of them can be listed. That is the whole trade, and it is worth making.
What is not known, and one thing this does not solve. The separation between addressing and authorship is an intention rather than a mechanism. Nothing in the shape enforces it, and the gradient runs the wrong way: every genuinely hard question is one no single part can own, so it arrives upstairs, and the layer thickens one reasonable decision at a time. Keeping it thin is a discipline somebody has to defend, and this note has no answer for what happens when nobody does.
The rest is a shape rather than a result. I have not run it across an organization, and the interval question is open: nothing here has measured what a stale view costs a routing decision, which is the number that would tell you how often to poll. The argument is about which failures can be found, not about what any of it saves.