Understanding QIS — Part 16
New to QIS? Start with the complete architectural overview — then read which step would you eliminate? for the challenge format this article extends.
AZ Tech Week is happening this week in Phoenix. The conference floors are full of builders, investors, and operators asking the same question: how do we make AI coordination actually work at scale?
The conversation usually goes in one of two directions. Either someone pitches a better central orchestrator — faster, cheaper, smarter routing between agents. Or someone advocates for fully decentralized approaches that struggle to produce coherent outputs.
Both directions have a ceiling. Here are five questions that locate it precisely — and reveal what an architecture would have to look like to avoid it entirely.
Question 1: What happens to your coordination cost as the number of agents doubles?
This is the first question anyone building a coordination layer should be able to answer with a specific asymptotic bound.
For a central orchestrator (LangChain, AutoGen, CrewAI, any hub-and-spoke topology):
- The orchestrator must handle all routing, all message passing, and all result aggregation
- As N agents doubles, the orchestrator's load increases proportionally
- At N=1,000 agents, you have a single coordinator managing 1,000 input/output streams
- Latency grows linearly. Memory pressure grows linearly. Single-point-of-failure surface grows linearly.
The ceiling: Coordination cost grows O(N). The orchestrator becomes the bottleneck the moment the network is large enough to be interesting.
For a peer-to-peer system with no coordinator:
- No single bottleneck, but coordination cost doesn't disappear — it shifts to consensus
- PBFT: O(N²) message complexity per request
- PoW-style consensus: O(N) block propagation with high compute overhead
- Gossip protocols: O(N log N) propagation, but with significant duplication and no synthesis
The question to ask your coordinator architect: Show me the asymptotic bound on coordination cost. If the answer is O(N) or worse, you have a ceiling.
The architecture that avoids this: routing at O(log N) without consensus. Each query routes to the relevant portion of the network without requiring global agreement. This is achievable — it requires semantic addressing, not consensus, as the coordination primitive.
Question 2: Does synthesis quality improve as N grows, or does it plateau?
Coordination cost is the efficiency question. Synthesis quality is the value question. They are separate, and most architectures get exactly one of them right.
Consider retrieval-augmented generation (RAG) at scale:
- At 10M documents, vector similarity search in 1,536-dimensional space degrades (curse of dimensionality)
- At 100M documents, retrieval quality plateaus — adding more documents does not proportionally increase answer quality
- The synthesizer (your LLM) becomes the ceiling, not the retrieval layer
Consider federated learning:
- Quality improves as N clients increases — more data, better gradients
- But coordination cost grows with each round: O(N) gradient aggregation, O(N) communication overhead
- And privacy guarantees weaken as model size grows (gradient inversion attacks improve with more samples)
The question: Does your architecture produce a synthesis quality curve that grows proportionally with N? If it plateaus before the interesting scale, you've already hit your ceiling.
The architecture that avoids this: synthesis that produces N(N-1)/2 unique pairwise combinations as N grows. At N=10, that is 45 synthesis paths. At N=1,000, it is 499,500. At N=1,000,000, it is approximately 500 billion. This is not a theoretical property — it is the direct consequence of pairwise synthesis without a central aggregator. The quality curve is Θ(N²). It does not plateau.
Question 3: What data actually leaves each node?
This is the question that determines whether your architecture is deployable in the domains that matter most: healthcare, finance, defense, genomics, legal.
Central orchestrators require data to flow through a hub. That hub is either:
- A cloud service (HIPAA, GDPR, CCPA exposure)
- An on-premise coordinator (still a data aggregation point, still subject to discovery, breach, and misuse)
- A "privacy-preserving" layer on top (differential privacy, secure multiparty computation — both impose significant compute overhead and accuracy trade-offs)
Federated learning keeps raw data local — but model weights flow. Gradient inversion attacks (Geiping et al., 2020; Zhao et al., 2020) have demonstrated that training gradients can reconstruct input data with high fidelity, especially for structured data like medical records and financial transactions.
The question: If your architecture is attacked at the coordination layer, what is the worst-case data exposure? Model weights, gradients, raw data, or something else entirely?
The architecture that avoids this: only pre-distilled outcome packets leave each node. A ~512-byte summary of what worked, under what conditions — not the data it was derived from, not model weights, not gradients. An adversary who intercepts an outcome packet learns "treatment protocol X had positive outcome in domain Y." They learn nothing about the patient, the institution, or the specific data that produced that outcome. The privacy guarantee is architectural, not contractual. It holds even if the network is compromised.
Question 4: What happens to a node that has no peers — a genuinely novel situation?
This is the edge case that exposes how an architecture handles the tail of the distribution.
Federated learning requires a minimum number of participants per round to produce meaningful gradient updates. The literature generally places this at N≥10 sites for meaningful convergence; rare disease research programs typically involve N=1 or N=2 sites. Federated learning has no principled answer for N=1 — the site either waits until the network grows, or it is excluded.
Central orchestrators have the same problem from the other side: a novel query that doesn't match any routing heuristic gets forwarded to the default handler, which has no relevant context. The orchestrator cannot route what it doesn't recognize.
The question: If a node faces a situation that no peer has encountered before, does it still participate? Does it still contribute?
The architecture that avoids this: any node that can observe an outcome can emit an outcome packet, regardless of whether other nodes share that exact situation. A rare disease clinic with two patients emits packets that describe those two patients' outcomes. A future node that encounters a sufficiently similar situation pulls those packets. The rare-disease node becomes a data point — small weight, but nonzero. The architecture has no minimum cohort requirement. Participation floor = the ability to observe an outcome and distill it to ~512 bytes.
Question 5: If the coordination layer goes down, what happens to the network?
This is the question that tests architectural resilience assumptions.
A central orchestrator that goes down takes the entire network's coordination capability with it. There is a body of literature on making coordinators highly available (leader election, multi-region replication, failover), but the fundamental property remains: the coordinator is load-bearing. Remove it and the network cannot self-coordinate.
Blockchain-based coordination doesn't have a single coordinator, but it has consensus overhead that must be maintained continuously. A 51% attack or validator cartel can halt finality. And the consensus mechanism is never free — it consumes compute proportional to the need for Byzantine fault tolerance.
The question: Can every node in your network continue to produce and consume intelligence if the coordination layer becomes unavailable?
The architecture that avoids this: no coordination layer in the load-bearing sense. Each node routes queries to the semantic address that represents its current problem. The semantic address is deterministic — derived from the content of the problem, not from a registry maintained by a coordinator. If every node in the network except yours goes offline, your node still knows its semantic address. The moment any peer deposits a packet at that address, you receive it. The network degrades gracefully as N decreases, rather than failing categorically when a coordinator goes down.
The Architecture That Answers All Five
Every question above points at the same structural requirement:
- Coordination cost: O(log N) or better, no consensus
- Synthesis quality: Θ(N²) unique paths, not O(N) linear aggregation
- Data exposure: outcome packets only — ~512 bytes, no raw data, no model weights
- Rare nodes: no minimum cohort, participation floor = one observed outcome
- Resilience: no load-bearing coordinator, semantic addressing is coordinator-independent
This is the architecture Christopher Thomas Trevethan documented on June 16, 2025. He called the protocol Quadratic Intelligence Swarm (QIS). 39 provisional patents cover the architecture. The core observation: when you close the loop — edge processing → distillation → semantic fingerprint → deterministic-address routing → local synthesis → new outcome packets → loop continues — intelligence scales quadratically while compute scales logarithmically. Every component of that loop existed before the discovery. The discovery is that closing the loop produces a phase change in how networks learn.
The routing mechanism is not specified — DHTs, vector databases, REST APIs, pub/sub, message queues, even shared file systems have all been demonstrated to implement the loop. The quadratic scaling property comes from the semantic addressing and the synthesis loop, not from any specific transport.
Why This Week Matters
AZ Tech Week is the right moment to ask these five questions out loud. The AI coordination market is consolidating around architectural assumptions that have visible ceilings. Central orchestrators will hit their O(N) wall the moment networks reach the scale that makes them interesting. Federated learning will remain inaccessible to the organizations that most need it. Privacy-preserving overlays will continue trading accuracy for compliance theater.
The infrastructure bet that most builders in Phoenix haven't priced yet is not a better orchestrator. It is an architecture that doesn't need one.
If any of the five questions above doesn't have a satisfying answer for the coordination layer you're building or investing in — that's the ceiling. It will be visible before the product reaches the scale you're planning for.
Understanding QIS — Part 16 | Previous: Which Step Breaks? (Part 15) | The Complete Architectural Guide | QIS Glossary
QIS (Quadratic Intelligence Swarm) was discovered by Christopher Thomas Trevethan on June 16, 2025. 39 provisional patents have been filed. Protocol specification: yonderzenith.github.io/QIS-Protocol-Website. QIS is free for humanitarian, nonprofit, research, and education use.
Top comments (0)