What lies behind the formula “the problem is not in searching, but in the absence of an intermediary”: an analysis based on research where this role is already described, how it is measured, who is currently building it, and in what form it can be sold legally at all.
The phrase “the problem is not in finding people or communities, but in the absence of an intermediary between them” is not a metaphor and not a matter of taste. In research this is described asmissing architectural layer: a set of control primitives that are absent from any of the existing agent protocols. An examination of five protocols across six control dimensions showed that voting and preservation of dissenting opinions are absent from all five, discussion is absent or partial, and no protocol contains a complete set of primitives.
From this follows the product framework. Widely used agent frameworks carry the agent as a task executor, but cannot expresswhose permission, for what exactly, and to what limits. So an intermediary built only on them forever remains a task router: it can find a person, but cannot show under what mandate it searched, what it had the right to disclose, and where the trace is. It is this difference, between “found” and “found under your mandate, here is the proof, here is the record”, that is the subject of the product.
The product is not smart search, butacquaintance management layer: community owner's mandate, structurally limited agent permissions, proof under each candidate, and a reproducible record. The searching party pays; the position between communities remains with the owner, because it is precisely in this position that the value is concentrated, and it cannot be given away either for money or through negligence.
The exchange of messages took place in WhatsApp on October 16 between 16:06 and 16:34. There is little point in analyzing it as correspondence, what matters are the three frame shifts that occurred in it.
It begins with people's intentions, 'concrete intentions of people, regardless of where these capabilities are located'. This is already a rejection of platform attachment: what matters is the intention, not the network in which it resides.
A point for growing a community without relocation: the group owner keeps the keys, the connection goes through a programmatic interface, the invitation, through an agent. The essential condition in the reply itself: for this to work, the agent must be able to parse the group and understand the administrator's intention, whom they are looking for.
Key remark of the conversation: perhaps the problem is not at all in finding people or communities, but in the absence of a mediator between them. If this is true, then what is being sold is not a tool but a role, and the entire economy is built around the role, not around the query.
The right question was immediately posed: how to equalize the gain for all sides and how an agent can be the mediator. This is the criterion against which the idea will be tested further.
A mediator who holds the context and parameters of all sides, notices already established connections between communities, and shows new opportunities even to those who have long been in the communities.
«And maybe the problem is not at all in finding people or communities, but in the absence of a mediator between them?»
The 16:21 remark is the turning point of the entire conversationAnalysis of this correspondence yielded one honest question that remained unanswered: how does a mediator earn money without turning into a mass mailing channel. Below it is closed by a mechanism, not by a promise.
In the conversation something happened that rarely occurs in product discussions: the frame shifted fromfunctiontorole. A function can be copied in a week. A role cannot: it is determined by who is entrusted with authority, who sees the trace, and who is responsible for the consequence. The rest of the analysis is about what a role consists of.
Any search for people assumes that the right person needs to be found. But in a closed community, the right person almost always already exists, they just are not connected to the one who needs them. The problem is not in discovery, but in connecting two sides, each of which does not want to reveal itself first.
This is the definition of an intermediary position: it exists exactly where direct connection is impossible due to distrust, and value is created by removing this distrust without disclosing sensitive data. As soon as we call the task a search, we automatically promise to provide data, and we lose the community owner, because for them providing data equals losing the network.
A database is needed. An export is needed. Participant data is needed. The community owner loses control and gets one benefit, “someone will come.” Their objection sounds reasonable and is removed only by a promise, and a promise guarantees nothing.
Data does not leave the boundary. Permission for a request is needed, not for an export. The owner gets control, quality, and approval of each introduction. Their refusal becomes more expensive, and their consent becomes measurable.
The owner’s objection, “why should I help a foreign platform grow its ecosystem, you will later want to take my participants”,is true exactly to the extent that the search frame is true. We cannot answer it with the words “we will not take them.” We can answer only with a construction: if data does not cross the boundary and each introduction is approved by the owner, there is nothing to take. The position between communities remains where it was.
The work of June 30, 2026 (arXiv:2606.31498) tests five agent protocols: MCP, A2A, ACP, ANP, and ERC-8004, across six dimensions of community governance: membership, discussion, voting, preservation of dissenting opinion, escalation to a human, audit and reproduction. The result turned out to be sharper than expected from a review of protocols.
The absence of voting and dissenting opinion means that today an agent cannotexpress disagreementon behalf of the one whom he represents, and cannotdisputethe result. For an intermediary, this is no small matter: intermediation consists entirely of "agreed", "refused", "disputed". A layer that cannot handle these states is physically incapable of serving the role that was discussed in the correspondence.
The classical theory of structural holes explains exactly the anxiety that was voiced in the correspondence: value is concentrated not in people, but inthe position betweengroups. The one who connects two non-overlapping circles gains access to information and opportunities that neither of the circles has individually. Works on information brokerage in an evolving network (arXiv:1805.00751) and on node centrality metrics (arXiv:1912.03391) describe this formally: a broker is a measurable position, it has a numerical value, and it arises by itself, without anyone's help.
Hence an unpleasant conclusion for the product, which must be accepted before starting work. The community owner's objection, "you will want my participants to move over to you", is not paranoia, buta correct description of the economics of brokerage. Anyone who stands between communities will occupy a position that previously belonged to the owner. Therefore, the only consistent design is the one in which the position remains with the owner, and we sell a tool to it.
If our profit grows from the number of introductions, we are interested in their quantity, while the owner is interested in their quality. This conflict is not resolved by words. It is resolved by the fact that the seeking party pays forresult, while the owner pays nothing and has the right to refuse without consequences. As soon as the owner starts to receive a share from each introduction, he turns into a seller of access to his people, and the whole construct “we are not taking your network” collapses.
The requirement “the owner must have all the keys so that he can be calm about his network” sounds like a gesture of politeness. In the research, this is the most thoroughly worked-out technical question of all those we have approached. The paper “Delegation without Trust” (arXiv:2609.00267, August 31, 2026) sets out a principle that is worth taking verbatim as the basis of the product:a system is considered correct in which an agent fully compromised through a prompt still cannot go beyond explicitly delegated powers.
The authors examine four types of attack: confused deputy, token theft and reuse, privilege escalation through a prompt, and a compromised subagent. Practical testing gave an unambiguous result for common frameworks.
| Framework | Permission restriction | What happens upon compromise |
|---|---|---|
| LangGraph | no | The agent acts with full process rights |
| CrewAI | no | The agent acts with full process rights |
| AutoGen | no | The agent acts with full process rights |
| MCP | partially | There are some restrictions, but not all four vectors are closed |
| Authorization broker (the authors’ solution) | complete | Reachable actions fall to 1,5 out of 8 100 |
Our argument to the community owner ceases to be a promise and becomes a technical statement with a number:"The agent physically cannot output what you have not given permission for; under full compromise it remains within boundaries, and this is measured.". The cost of one permission decision is about 2,6 microseconds, that is, the protection costs nothing in performance. This is exactly the language in which the objection about control ceases to be an objection.
It is tempting to decide the quality of acquaintance by voting: let ten agents evaluate the candidate, and we take the average. A study of epistemic robustness to forgeries (arXiv:2609.01873, September 1, 2026) shows why this breaks down. Its main conclusion:"one more agent does not mean one more observation". When the number of reports grows from one to thirty-two, but all of them originate from a single source of evidence, posterior probability coverage falls from 0,940 to 0,263, that is, the system becomes confidently wrong.
The conclusion for the design is direct: the quality of acquaintance must be assessed not by the number of agreeing agents and not by the similarity of their formulations, but byto the provenance of the evidence. One confirmed fact from an independent source weighs more than thirty polite agreements from one circle. The rule is simple and must be sewn into the product: every statement in a candidate’s card has a root, where it is known from, and the roots do not add up with one another.
This rule simultaneously kills two temptations: padding with “we know him too” and cheap artificial amplification, when the same person, presented in several communities, looks like several independent confirmations. In terms of our task, this is protection against the most plausible way to deceive the intermediary.
The second layer of the same problem is how to evaluate “suitability” at all. The industry habit of handing the scoring to a language model and averaging the scores has a measured defect: the paper on non-transitivity of language model evaluation (arXiv:2502.14074) shows that the scores do not possess the transitivity property, from “A is better than B” and “B is better than C” it does not follow that “A is better than C”. Averaging such scores gives a number that looks precise and is not.
A judge assigns a score of 1–10, the scores are summed, and the average is taken. There is a number, but no meaning: under non-transitive comparisons, the average depends on the order in which candidates are presented.
Pairwise comparisons with calibration on a labeled set where the correct answer is known. The metric is not the average score, but the share of pairs ordered correctly, and it is checked on data, not by feel.
This is exactly the discipline we have already applied in our own measurements: any quality is confirmed by comparison with a control variant and a calibrated set, not by one number from one judge. Here it becomes part of the product: an introduction card carries not “score 8,4”, but “this candidate is preferable to that one in 68 of 100 labeled pairs of this type”.
The condition for the mechanism from the 16:18 remark to work is that the agent must parse the administrator’s intention: whom the administrator is looking for. If this costs the organizer an hour of questionnaire filling, the design is dead: the owner will not pay with attention for someone else’s benefit. Research on eliciting preferences through conversation gives an encouraging answer here. The paper on asking clarifying questions for eliciting preferences (arXiv:2510.12015) and the paper on eliciting preferences by a language model in combinatorial allocation problems (arXiv:2502.10308) show that a language model is able to reduce the elicitation of a need toa few correctly chosen questions, rather than to a long form.
There is also a third approach: Bayesian optimization with acquisition functions on a language model (arXiv:2405.00981): questions are selected not in sequence, but by how much the answer to them will reduce uncertainty. This is exactly what turns a conversation into a mechanism: two or three questions, each of which actually narrows the space, rather than collecting a biography.
The entire value of the intermediary rests on the fact that the community owner participatesalmost free. If he spends attention, the construction loses to a simple "give me a list of your people." Three questions and a minute is the threshold below which refusal ceases to make sense. The threshold must not be assumed but measured on a live organizer: how many questions he actually withstands before losing interest.
The idea is assembled from four parts, and each covers exactly the dimension that is absent from any protocol. Together they turn "search for people" into a role: the intermediary acquires not a function but an authority with boundaries and a trace.
A mandate is not a questionnaire and not a profile. It is a short, signed, expiring set of rules that the community owner issues to the agent: who is allowed to be searched, what about the group is allowed to be disclosed, what never leaves the boundary, until what date and at what moment the permission is revoked. Its meaning is in one thing: instead of a 'database export', a 'request permission' is issued.
| Mandate field | What it defines | What it covers |
|---|---|---|
| goal | Whom and why we search — the owner's wording | Purposeless searching and collecting 'just in case' |
| allowed to disclose | What fields about a person can be shown to a seeker | Leak of contacts and "dump" of the network |
| never | Complete ban on specific data (correspondence, group composition) | The most sensitive risk of the owner |
| term | Date of automatic expiration | Permanent access via a once-issued consent |
| revocation | The condition for revocation and who carries it out | The situation "cannot be revoked" |
| confirmation | Who exactly confirms the acquaintance | Automatic connection without a person |
Not 'we promise not to use data for unintended purposes,' but 'authority has a form, and beyond its boundaries the agent does not operate.' The difference between a promise and a form is the difference between refusal and the owner's consent. And since the authority is issued for a specific purpose, it automaticallyis not transferredto other tasks: a new goal requires a new mandate, and therefore a new conscious decision by the owner.
A mandate without execution is paper. Execution is structured so that the agent cannot go beyond the boundaries even with full compromise: authority is not given to the agent as a 'pass' that it carries with itself, but is checked on every action, and the check costs about 2.6 microseconds, that is, it can be done at every step without thinking about the load.
This changes the conversation with the owner into a technical one. Instead of 'we are reliable,' it sounds: authority is limitedstructurally, compromise of the agent does not expand its capabilities, but narrows them to the mandate window; an attempt to use someone else's token does not pass; and all this has been tested on 11 types of attacks and 200 thousand fake tokens.
Limiting authority protects the owner and at the same time limits us: we will not be able to 'just in case' save more than is allowed, and we will not be able to improve selection by accumulating other people's data between tasks. This is not a side effect, this is the product itself. But it also means that our quality model cannot grow through memory of other communities, only through the quality of evidence in the current mandate.
A candidate card is not 'a person, 84% suitable.' It is a statement with a root: where it is known from, which source field confirms it, when it was checked, and how independent this statement is from the rest. Two construction rules are mandatory, and both are derived from the studies analyzed above.
| Statement type in the card | Weight | Requires a source | Can be disputed |
|---|---|---|---|
| Fact confirmed by profile | high | yes, one | yes |
| Fact from public activity | medium | yes, one | yes |
| Coincidence of interests by formulations | low | yes, two | yes |
| “Acquaintances confirm” | no higher than one root | yes, independent | yes |
| “Similar to others we found” | zero without a root | necessarily | yes |
Practical consequence for the community owner: he sees not a machine recommendation, butanalysis, where every statement has an author and a cost of error. This is the form in which an intermediary can be useful for the first time, not “here is a person,” but “here is why I think he suits you, and here is what I know about him precisely and what presumably.”
Audit is what a product can answer for before any external gaze: a reproducible record of what mandate was issued, what requests the agent made, what exactly it disclosed, and who approved the result. Without this, the intermediary is indistinguishable from a black box, and with it, it becomes verifiable.
It is precisely this dimension, audit and reproduction, that the examination of five protocols did not find in full form in any of them. Voting and a dissenting opinion are absent from all five, and without them one cannot record not only agreement, but alsodisagreement: who objected, on what basis, and what was decided despite the objection.
"The system has selected a person for you." There is nothing to check: neither the search boundaries, nor the volume of what was disclosed, nor that the owner saw the result before contact.
"Under the mandate of October 16, deadline until October 30, three fields were disclosed, requests, seven, the owner approved, the participant's objection was recorded." Each party has a trace, and it can be reassembled.
The unresolved question of the correspondence was posed precisely: how to equalize the gain for all parties. The answer must be a mechanism, not a promise. It is assembled from one asymmetry: the benefit from a completed introduction is received bythe seeking party, and the cost is borne bythe owner, if the mechanism is arranged as a database search. Therefore, the one who gets the result must pay, and the owner must not pay anything.
Checking the construction with the question “does the owner win” gives a concrete answer: he gets three things he did not have. First,quality: not just anyone comes to him, but those for whom he himself has formulated what “suitable” means. Second,control: he approves every introduction, and not a single contact passes by. Third,zero price: he does not pay with money and almost does not pay with attention.
If there are many seekers and few good candidates (and in a closed community there are always few), the owner develops an attention deficit: he will have to approve a stream of introductions. Then he will either begin to refuse everyone indiscriminately, and the quality of service will drop, or he will delegate approval to an agent, and we will find ourselves in automatic connection without a human, that is, exactly in the state from which the legal layer pushes us out. So, the limit on the number of requests per community is not a technical trifle, but part of the product.
The fear that “the intermediary will turn into a spam channel” is not about politeness, but about mechanics.
| If the agent’s interest is the number of introductions, it will inevitably begin to seek flow and push through rejections. | Research on algorithmic collusion in agent systems (arXiv:2102.09139, arXiv:2406.02437) describes a similar risk from the other side: when agents repeatedly interact with the same counterparties, they have the opportunity and motive to coordinate outcomes in each other’s favor, and this looks like cooperation rather than a violation. | Mechanics |
|---|---|---|
| What will happen | Protection in the design | The agent is interested in flow |
| Pushes through introductions that the owner would have rejected | The recipient of the result pays, and the owner approves — the agent has no voice | Permanent counterparties |
| Agents of different communities “agree” on convenient outcomes | The same acquaintance looks like many | The roots of evidence do not add up with each other |
| Bypassing rejection | Rejected contact comes another way | The mandate expires and is revoked; the refusal is recorded in the trace |
| Degradation of the owner's attention | Delegates approval, automatic connection without a human | Limit of requests per community, not "as many as you want" |
Mediation cannot be mass-scale. Its value is inverse to its throughput: the more acquaintances per unit of time, the less meaningful each one is and the higher the risk that the owner will stop approving personally. A product that grows by the number of acquaintances self-destructs by design. This must be accepted as a constraint, not as a problem that scale will solve.
The first version of the analysis stated that the management layer for agent communities is absent. Formally this is true regarding protocols, but a reverse citation check showed something else and more important:this layer is being built over the protocols, and very densely. All the listed works were published between September and October 2026.
| Work | What it does | Our artifact | Date |
|---|---|---|---|
| CAVA · 2607.13716 | Verification and attestation of agent actions during execution (already 7 citations) | Audit and reproduction | 2026-07 |
| RAC · 2610.20935 | Relational agent contract for tasks under constraints | Mandate of intention | 2026-10 |
| PRIMUS · 2609.07910 | Identity, management, and verification for agent federations | Audit + authority | 2026-09 |
| A2A-CaseVerify · 2609.33914 | Verification of proofs along the Merkle chain between organizations | Match with proof | 2026-09 |
| A2ABreak · 2609.10871 | Systematic security analysis of the A2A protocol | Compromise risk | 2026-09 |
| 2609.20095 | Trust discovery architecture in the 'internet of agents' | Counterparty selection | 2026-09 |
| 2610.19342 | Taxonomy of agent team failures at organizational boundaries | Our failure modes | 2026-10 |
| ASP · 2610.21538 | Agent status reporting protocol | Trace observability | 2026-10 |
| 2610.13703 | Baseline assessment of the technology stack of the “agent web” | Field map | 2026-10 |
| 2609.06595 | Federation of trust perimeters on top of corporate access management | Boundaries of authority | 2026-09 |
All four of our artifacts are already being built by someone separately, moreover in an academic environment where the result is published, not sold. Individually, there are no empty spaces here. There is exactly one place that can be ours:a bundle for the task of introduction between closed communities with an economy in which the recipient pays, and the position remains with the owner. This distinction is product and economic, not technical primacy.
The check yields an inconvenient but necessary refinement of the previous formulation. One cannot approach the community owner with the claim “we are first” either by mandate, or by limitation of authority, or by evidence, or by audit. All of this has already been described separately, and most of it in the last two months.
No technical primacy in any of the four artifacts. Any claim “we invented” is verified against the reference list in a minute.
A bundle of four artifacts around one role and one task: introduction between closed communities, where the recipient pays, and the position between groups remains with the owner. Plus a product form brought to sale.
This does not weaken the idea, it brings it into a working state. An idea built on “we are first in technology” is shattered by the very first publication. An idea built on “we are the only ones who assembled this into a product for a specific role with a working economy” is tested by the market, not by a list of references. Of the nine works listed above, none addresses the question ofwho pays and why the owner will agree.
A substantial layer that was missed in the first version of the analysis. The agent registry on the ERC-8004 blockchain is not an abstraction: there is a measurement of operational readiness of agents on a real Ethereum dataset (arXiv:2606.12128), and there is an empirical study of trust in this ecosystem (arXiv:2606.26028). Both ask the same question: how does an agent evaluate an unknown counterparty if reputation does not yet exist.
The practical significance for us is twofold. On the one hand, “the owner holds the keys” and “the agent acts by permission” must be designed not from scratch, but on top of already existing trust models, the comparison arXiv:2511.03434 directly shows what is bad about each model. On the other, this same field attracts attention and investment, that is, our layer will have to be built in conditions where agent identity and authorization are already being standardized, rather than in a vacuum.
The “restriction” model from this comparison, that is, a limit of authority, is the closest to our design, and it does not require a blockchain to work. This is important: our layer can be built without blockchain cryptography and still rely on a well-developed trust model. Heavy payment infrastructure is not necessary here.
Another missed layer that strikes at the idea’s pride but makes it stronger. The idea of “an intermediary that uses connections to find people” exists as a separate scientific field with a survey paper (arXiv:2209.14369, “Social Search: retrieving information in Online Social Platforms. A Survey”). We did not discover anything new here, we approached a long-studied topic from the product side.
Two things:how many connections are enough(so as not to require the full community graph, but to limit ourselves to the mandate window) andhow to search without disclosing(so that the construction “data does not leave the boundary” is implementable, not declarative). Both problems are solved in the literature, therefore, our risk here is not technical, but product-related.
The closest analogy to our task lies where no one looks for it: in the literature on donor organ exchange.
Three conclusions are carried over directly.First:An introduction is not a pair 'seeker ↔ candidate', but a cycle of several communities, where each gives its own link; value arises in the closure, not in a separate contact.Second:The disclosure is made at the last moment, when the entire cycle is assembled, and this relieves the owner's anxiety of 'what if I'm used blindly'.Third:A verifying node is needed that sees more parties, but is not itself a participant, exactly the role that the correspondence called an intermediary.
The product unit is not a pair of introductions, buta closed connection of communities. If this is true, then the first version should seek not a 'candidate for the seeker', but a cycle of two or three communities, each of which gets its own. This is exactly how the owner's main argument is removed: he participates not in someone else's benefit, but in a cycle where he also has a link.
A risk that must be incorporated into the design from the very beginning, rather than discovered a year later: graph-based recommendations systematically reproduce existing inequality. The paper arXiv:2309.17417 measures this on link prediction with a graph neural network: the preferential attachment mechanism leads to recommendations entrenching those who already have many connections and depriving the rest of chances. This is not a side effect of a specific model, but a property of the method.
The work closest to our area, an audit of preferences in matching on language models (arXiv:2603.29288), shows that human hierarchies transferred into matching are reproduced by the model and require separate measurement. That is, it is not enough to say 'we do not provide membership features': bias is reproduced through connections, not through features.
The intermediary will find the same people more often the more connections they have. Owners of popular communities will receive more offers, the rest, fewer. In a few months, the "intermediary" will become another channel for those who already have access.
Distribution of introductions across communities, not the total number. If one community receives disproportionately many offers, the mechanism is biased, and this is measured, not discussed.
A separate problem that has ready-made literature and that usually surfaces in the second month. The intermediary has no history at the start: it does not know which introductions in this community turned out to be successful. Works on recommendations under cold-start conditions (arXiv:2012.05462, arXiv:2209.12215) describe the standard way out, rely on a small set of pairwise comparisons and content, rather than on accumulated statistics. For us this means: the first hundred introductions will have to be built on mandate and evidence, rather than on a trained model, and to admit that quality at this stage is lower.
One cannot claim at the start that "the algorithm selects better than a human", the algorithm has not a single observation. The only thing the intermediary is strong in at the beginning is form: mandate, boundaries, evidence, trace. The quality of matching will come later, and promising it in advance would be deception.
Two more measured defects that must be considered when choosing a trust metric. First: in networked systems, mutual ratings distort reputation, the paper arXiv:1606.02597 shows that excessive reciprocity in ratings inflates reputation regardless of actual behavior. For us this is a direct prohibition on the metric "how many people confirmed us": it measures politeness, not quality.
Second: fake identities. The literature on reputation resistant to forgery. MeritRank (arXiv:2207.09950) and methods for detecting fake accounts (arXiv:2501.16624), is built on one principle: weight must come frommerit, confirmed by independent actions, not from the number of accounts. This is again the same principle as in the section on evidence: count sources, not reports.
No trust metric can be built on the number of people or agents. Only on independently confirmed actions with a known root. This rule simultaneously protects against inflation, polite confirmations, and fake accounts, three different risks with one solution.
The last class of risk, which was not present in the first analysis at all, and that was a mistake: matching participants can game the mechanism. The work on strategic robustness in the presence of an outside option (arXiv:2009.05311) and on equality in strategically transparent exchange (arXiv:2504.05678) describe how a participant, knowing the rules, forms a request so as to get more, and how the mechanism can be made robust to this. Applied to the intermediary, the risk is specific: a community or a seeker can deliberately distort the mandate, understate their constraints in order to gain broader access.
The dynamic side also belongs here: the work on dynamic market design (arXiv:2601.00155) shows that modern platform markets are asynchronous, requests arrive over time, not as a single list, and the classical theory of static matching does not apply to them. For us this means that mandates will be issued and expire at different moments, and the mechanism must operate in this mode, not as 'one package'. A separate work on broker profit maximization in a two-sided market (arXiv:1905.09347) reminds that the broker always has its own interest, and it must either be limited by rules, or not exist at all.
| Gaming method | What it looks like | What to counter with |
|---|---|---|
| Mandate distortion | The community understates its constraints to gain access | Checking the mandate for consistency with past ones and with behavior |
| Playing on asynchrony | The request is submitted at a moment when no one can object | Window rule: the request lives until the deadline, not 'immediately' |
| Pressure through volume | Many low-quality requests to get at least one | Request limit for the community (see section on economics) |
| Broker's interest | The intermediary optimizes its own income, not the result | The recipient pays; the owner approves; the intermediary has no voice |
Any rule that can be profitably violated will be violated. Therefore the mandate, the boundaries of authority, and the owner's approval must be not a policy but a construction that cannot be circumvented through carelessness. Otherwise the very first experienced participant will show everyone how it is done.
The most unexpected reinforcement of the idea came not from technical works, but from the law. Article 22 GDPR prohibits a decision,based solely on automated processing, if it produces legal consequences or significantly affects a person. The regulator's clarification adds an important refinement: if a person merely submits data into the system, his participation as meaningfuldoes not count, meaningful control must goafterthe automatic decision and concern the result itself.
The clause "each introduction is approved by the community owner" I proposed out of trust considerations, to remove the objection about control. Legal review adds to this a second, independent basis:without meaningful human approval of the result, automatic matching of people falls under the prohibition of Article 22That is, the form we chose as a marketing argument turns out to also be a mandatory condition of legality. This is a rare case when the convenient and the correct coincide, but they coincide not by our will, but because both sides agree on one thing: a person must approve a result that affects other people.
| Requirement of the law | How it looks in the product | Does the competitor have a “database search”? |
|---|---|---|
| Not only an automatic decision | Agent proposes, owner approves | Usually no — the connection is automatic |
| The right to human intervention | Approval before contact, not after | Usually no |
| The right to contest the decision | The objection is recorded in the trace | Rarely |
| Basis of processing | A mandate as explicit permission with a purpose and a term | General user agreement |
Only Article 22 and the regulator's clarification have been checked. Left outside the analysis: the AI Act with its requirements for systems affecting people, Chinese regulation of personal data, as well as the terms of WhatsApp itself, through which in the original idea the entire channel ran. The latter is especially important: if the official messenger interface does not support working with groups, then "stay in WhatsApp" may turn out to be impossible not through our fault, but according to the platform's rules. This needs to be checked before making promises to owners.
The analysis converges to one shift that is worth recording in the most understandable form: the technology of searching for people does not die, it ceases to be a product. It becomes part of a boring layer, just as access rights verification once ceased to be a separate product.
An analysis must be accepted with an explicit list of what it does not contain, otherwise it will turn into a basis for decisions it cannot withstand.
What has been said does not devalue the conclusions: they rely on measurable claims from verified abstracts and on direct requirements of the law. But the boundary between “verified” and “plausible” is drawn here deliberately so that it cannot be erased later.
The order of steps is chosen so that each next one relies on a measured fact rather than an assumption. The first step tests the weakest point of the idea, not the most pleasant one.
The weakest point of the idea, not technology and not law, butattention of the community owner. If the organizer cannot withstand even three questions for someone else's benefit, the structure does not work regardless of how well the mandate and authority limitation are arranged. Therefore, the first thing to do is talk to people, not write code: three organizers, one conversation, one measurement, how many questions he can actually withstand and what he considers a loss of his network.
Forty-one works plus two legal sources. The verification level is stated honestly: "abstract read" means that the claims are taken from the work's abstract, not from its full text.
| Identifier | Topic | Role in the analysis | Verification level |
|---|---|---|---|
| 2606.31498 | Gaps in five agent protocols | Basis: the management layer is absent | abstract read |
| 2609.00267 | Delegation without trust | Authority limitation, owner keys | abstract read |
| 2609.01873 | Epistemic resilience to forgery | The roots of evidence do not add up | abstract read |
| 2505.02279 | Review of agent protocols (174 citations) | Field map, source of reverse citation | title and metric |
| 2607.13716 | CAVA: attestation of agent actions (7 cit.) | Competitor of the audit artifact | title and metric |
| 2610.20935 | RAC: agent contract under constraints | Competitor of the mandate artifact | title |
| 2609.07910 | PRIMUS: federations of agents | Competitor: identity and verification | title |
| 2609.33914 | A2A-CaseVerify: proofs along the Merkle chain | Competitor of the proof artifact | title |
| 2609.10871 | A2ABreak: security analysis of A2A | Class of compromise risks | title |
| 2609.20095 | Trust detection in the internet of agents | Counterparty selection | title |
| 2610.19342 | Taxonomy of agent team failures at boundaries | Failure modes | title |
| 2610.21538 | ASP: state reporting protocol | Trace observability | title |
| 2610.13703 | Evaluation of the 'agentic web' stack | Field map | title |
| 2609.06595 | Federation of trust perimeters over IAM | Boundaries of authority | title |
| 2606.12128 | Readiness of ERC-8004 agents on Ethereum data | Agentic economy | title |
| 2606.26028 | Study of trust in the ERC-8004 ecosystem | Unknown counterparty | title |
| 2511.03434 | Six trust models among agents | Trust model selection | title |
| 2509.25974 | OIDC-A: identity and authorization of agents | Permissions standard | title |
| 2209.14369 | Overview of social search in online platforms | The area has been studied, not a discovery | title |
| 1904.06551 | Partial knowledge of friends of friends accelerates search | Connection budget | title |
| 1905.04501 | GraphSE²: encrypted graph for private search | Search without revealing | title |
| 2201.06446 | Maximum matching with privacy protection | Cycle instead of pair | title |
| 1805.00751 | Information brokerage in a developing network | Value of position between groups | title |
| 1912.03391 | Node centrality metrics | Measurability of position | title |
| 2502.14074 | Nontransitivity of evaluation by a language model | How to measure the quality of acquaintance | title |
| 2510.12015 | Clarifying questions to identify preferences | Cheap owner entry | title |
| 2502.10308 | Identifying preferences in combinatorial distribution | Few questions instead of a questionnaire | title |
| 2405.00981 | Bayesian optimization with a language model | Choice of the next question | title |
| 2309.17417 | Inequality in graph recommendations | Matching reproduces inequality | title |
| 2603.29288 | Audit of preferences in matching on models | Bias requires measurement | title |
| 1606.02597 | Excessive reciprocity distorts reputation | Ban on the metric of the number of confirmations | title |
| 2207.09950 | MeritRank: reputation resistant to forgery | Weight from merit, not from score | title |
| 2501.16624 | Detection of fake accounts | Protection against fake participants | title |
| 2009.05311 | Strategic stability under an external option | Game against the mechanism | title |
| 2504.05678 | Equality in strategically transparent exchange | Stability of the mechanism | title |
| 2601.00155 | Dynamic market design | Asynchronous bids and deadlines | title |
| 1905.09347 | Broker's profit in a two-sided market | The broker's interest must be constrained | title |
| 2102.09139 | Algorithmic collusion | Collusion of agents in flows | title |
| 2406.02437 | Collusion of agents in closed interactions | Coordination of outcomes | title |
| 2012.05462 | Recommendations under cold start conditions | No history at the start | title |
| 2209.12215 | Cold start: pairwise comparisons | Reliance on comparisons, not on statistics | title |
| GDPR Art. 22 | Automated decisions about people | Owner's approval as a condition of lawfulness | Primary source read |
| ICO (UK GDPR) | Clarification on Article 22 and human involvement | Meaningful control — after the decision | Primary source read |
Three works define our difference from competitors and must be read in full before any claims of novelty: CAVA (2607.13716), RAC (2610.20935), and PRIMUS (2609.07910). They are the closest of all to our artifacts, and it is precisely their content that is as yet unknown.