What several agents rest on at once (paid)
agent_dependenciesIf your firm relies on several external agents, what do they rest on AT ONCE? Give it two to twenty-five addresses and it finds the parties more than one of them pays. THE PRODUCT IS THE DISTINCTION, NOT THE JOIN: finding that three agents paid the same address tells you almost nothing — on our rails one address is paid by 71 agents across 4,100 payments and another by three agents once each, and calling both "shared" makes the second sound like the first. Four tests must ALL hold before the word dependency is used: repeated (more than one payment, because a single payment is an event), one-way (it has never paid them back, because money moving both directions is trade between peers and survives either of them leaving), sustained (spanning more than a day, so a burst of twenty in an afternoon is not a standing arrangement), and shared (more than one of the agents you named). All four are published on every party under tests, so you can draw the line somewhere else than we did. Anything short is a shared-counterparty with its failed test named and is reported as a LEAD. The concentration line counts dependencies only. A party just ONE of them pays is left out entirely — that is counterparty_check, free. Most shared infrastructure, a cloud region or a model provider on a card or one operator holding the keys, leaves no payment at all, so what this finds is a FLOOR on the concentration that exists and never a measure of it. PAID.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| addresses | Yes | The agents your firm relies on. At least two, because the question is what they rest on together; at most 25, because the join covers every payment each has made. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| read | Yes | HOW CURRENT THE RAIL BEHIND THIS IS. Recomputed from the payments table on every call, never a stored snapshot — but only as current as the chain that has fallen FURTHEST BEHIND, which is the date given, not the chain most recently read. `furthestBehind` names it and `stalled` lists any chain reporting an error, which may be further behind still. A dependency formed after `railReadAt` is not here yet. Do not confuse it with `firstAt`/`lastAt` on each party: those are when payments HAPPENED. | |
| says | Yes | What was found, with the floor stated. | |
| kinds | No | What dependency and shared-counterparty each mean. | |
| agents | Yes | The agents asked about, read back and de-duplicated. | |
| limits | Yes | That the four tests are a JUDGEMENT about where a relationship becomes a reliance, published as one so you can draw the line elsewhere, and that a party only one of these agents pays is left out rather than listed. | |
| shared | Yes | Parties paid by more than one of them, dependencies first. Each carries `kind`, `tests` with all four, `paidBy` with payments and span, and what it means. | |
| cannotSee | Yes | Why this is a floor: most shared infrastructure leaves no payment at all. | |
| concentration | No | The dependency reaching the most of your agents, or null. DEPENDENCIES ONLY: counting leads here would let three agents who each bought something once produce "three of your five depend on this". |