When the first line tears — what steps in? A hypothesis.
LogPy is a research initiative for a second line of societal coordination — bottom-up (from below, out of the people themselves, not ordered by authorities), worn on the body, augmented by multi-agent systems. As its orchestrator substrate, LogPy uses “LogpyClaw”, a local multi-agent framework. Here I sketch a hypothesis that emerged from existing components and a few coincidences — a LoRa documentary on Arte gave one of the nudges: whether the substrate could carry a layer that steps in when the first line tears. Three-tier architecture (wearable, mesh peers, resilience centers), antifragility as a possibility, a clear risk axis. Crisis is the litmus test, not the purpose. I don’t know whether it works. I want to find out whether it works.
Where the first line tears
There’s a reason I’m reluctant to start with the Ahr valley. I don’t want to turn 2021 into an emotional template, into a shock argument, into an opening that traffics in wounds.
But it was a signal. Today, a few years on, with tools that didn’t exist in this form back then, we read it more precisely.
What tore was not just infrastructure. It was the quiet assumption that one line of societal coordination holds under every load. Phones gone, radio overloaded, authorities overwhelmed. People didn’t know who was still alive, who was where, who needed help. Help came. But late. Some too late.
The signal doesn’t say “make the authorities better.” The authorities weren’t the problem — they were overloaded, as was predictable. The signal says: “the assumption that one line is enough was wrong.”
Climate crises aren’t getting fewer, cyberattacks on power and water are no longer theory, aid organizations are losing staff while the situations grow. What became visible in the Ahr valley will repeat itself — in other regions, other forms, with other first lines that break.
(gdg: no, it emerged from the components!)I’ve been asking myself for months: what if there were a second line? One that steps in when the first isn’t enough. Bottom-up, person to person, augmented by machines we wear on our bodies.
I don’t know whether it works. But I want to find out whether it works. The initiative behind it is called — by me — LogPy.
What it would have looked like with the system
Up front: mesh radio, wearables, P2P protocols — the parts existed in 2021. What didn’t exist were AI models that could have brought the whole thing usefully onto a wrist. Today they exist. Barely, but they’re here. That’s why I can write this vignette now and couldn’t have written it four years ago.
(gdg: too complex, it has to become clear in 1 min what the system is, video_todo)
Picture the night of 14 July 2021 once more. This time with the system on your wrist.
22:47. The power has been flickering for twenty minutes. Mobile signal: one bar, then none. You check your smartphone — WhatsApp won’t load.
The device on your wrist vibrates. Not loud, not alarmist.
Ahr water level, local: 4.7 m, measured 90 s ago. Trend rising 18 cm/min. Rate of rise: unusual. Recommendation: reach high ground. Confidence: high. Source: 3 mesh peers + Tier-3 gauge-archive interface.
You tap “Family.”
Father (verified), seen as a carrier 8 min ago, currently offline. Last known position: at home. Half-life of this statement: 15 min under current conditions.
A map. Two routes to his house. One green (“Brücke West, confidence high, 12 min computed”), one red (“valley road, water level rising rapidly, not recommended, confidence high”).
Above the entry, one line: Computed time, not experienced. Plan in a stress reserve.
You set off.
On the way, a neighbor two houses down checks in. Verified skill: first aid. Offers to walk with you — she has a spare battery for radios, you don’t. Your two devices pair on the local mesh.
The authorities’ networks are still overloaded. But you’re not out there alone. Seven carriers within an 800-meter radius, and the system knows that without anyone coordinating it centrally.
That’s what it would have looked like. Not as a miracle. As a layer that steps in when the other one breaks.
What already stands
A quick clarification of terms, because the layers matter: LogPy is the initiative — the entire system with brand, front, identity stack, mesh layer. LogpyClaw is the orchestrator engine within it, a local multi-agent framework that came together over several phases. LogpyClaw has value outside LogPy too (everyday multi-agent uses on your own Mac). LogPy uses LogpyClaw as its kernel and builds the mesh, the tier-3 architecture and the public front around it.
What LogpyClaw carries as a substrate today:
- Frame architecture — each agent has its own reasoning frames, versioned reads, causal ordering.
- Time provider with proper time — fast agents (small models) and slow agents (frontier models) have different proper times (γ), against which drift can be measured.
- Causal Dilation Clock (CDC) — a data structure that classifies cross-agent merges into four relations: ordered, causal-drift, concurrent-drift, inconsistent.
- Temporal Policy — side-effect skills (mail, Telegram, LinkedIn) are rejected when drift gets too large, instead of being executed blindly.
In parallel on dillenberg.net: at rent-a-human.dillenberg.net, an A2A-spec-compliant agent endpoint (JSON-RPC 2.0, AgentCard, SendMessage/GetTask) has been running since 2026-05-04. That’s the first productive agent-to-agent test I’m running in the open net.
The substrate carries single-agent use cases today. The question in this paper is: could it also carry a societal mesh?
Three tiers, three availabilities
The naive question “local or cloud?” has a naive answer: neither. The architecture I’m putting up for discussion has three layers — each with its own availability and its own trade-off between resilience and performance.
Tier 1 — Personal Device (on the body)
A wearable or smartphone with a small LLM (3–7B parameters, NPU-accelerated). Connects over LoRa, Bluetooth or mobile. Concrete hardware sketch: → LogPy — the Communicator.
Availability: always.
Strength: personal, private, reachable any time.
Weakness: small model, limited context.
Tier 2 — Mesh peers (~10 km radius)
Other LogPy carriers within local radio range. LoRa mesh, Bluetooth mesh or local Wi-Fi. Compute is pooled, skills are shared, the situational picture emerges from the sensors of several carriers.
Availability: opportunistic.
Strength: emergent intelligence, no central dependency.
Weakness: needs carrier density, low bandwidth, latency.
Tier 3 — Resilience Centers
Hardened data centers with a guaranteed minimum uptime (X hours via UPS / diesel / solar). Frontier LLMs, storage, cross-region routing. Reachable primarily over the internet, secondarily over LoRa gateway.
Availability: guaranteed within time windows, plannable.
Strength: massive capability, persistent logs, large models.
Weakness: not everywhere, not always, governance question open.
Tier 3 is optional, but a capability uplift when reachable. The agent prioritizes: if Tier 1 is enough for the task → solo. Tier 2 reachable and useful → collaborate. Tier 3 reachable and the task is large → escalate.
The system works on every single tier. It gets better with each additional tier. No tier is a single point of failure. That is graceful degradation by design — the standard pattern from distributed systems, carried over to societal infrastructure.
The model for Tier 3 is Tor directory authorities and IPFS pinning services: specialized, opportunistically usable nodes that the network doesn’t need, but that make it stronger when they’re there.
What happens between the tiers
Three substrate layers would have to come together for the mesh to become possible at all.
Identity. Each agent has a cryptographic identity with which it authenticates itself to others. Web of trust, no certificate authority, no big-tech anchor. Reputation is kept locally: your agent trusts the agents it has had good experiences with — and cautiously inherits trust from your immediate circle.
Time and order. In a mesh without a synchronous wall clock (no NTP over LoRa, RTC drift on cheap hardware, long offline phases), you need hybrid logical clocks for causal ordering. The γ axis from LogpyClaw additionally provides effort information: who has thought how much since the last sync? When merging two agents, that’s the difference between “you’re behind” and “you’re on a different track.”
Routing and capability discovery. An agent looking for help broadcasts its need locally. Other agents check whether they fit — skill, distance, availability. The A2A spec sets the technical vocabulary; the skill matching on top of it would be our own contribution.
Four phases — the adoption path
The mesh doesn’t emerge by proclamation, but by adoption. For adoption to work, each phase must be valuable on its own too. The phase below must not have to wait on the phase above.
| Phase | What it delivers | Value per carrier | Minimum adoption |
|---|---|---|---|
| A | Solo agent: personal productivity | immediate | none |
| B | Local skill matching, mutual aid in the neighborhood | medium | ~3 % local |
| C | Crisis coordination, swarm triage | high (rare) | ~10 % regional |
| D | Societal resilience layer | systemic | ~20 % national |
Phase A must stand on its own. That’s the critical condition. Whoever fails to convince a LogPy carrier that the device is useful on day one will never reach phases B–D. That’s the lesson from every comparable mesh network of the last 15 years — Meshtastic, Briar, Helium, Bridgefy. All technically solid, all stranded at cold start.
Crisis as litmus test
We talk about crises because they show what otherwise stays invisible. But the mesh isn’t built for crises, it’s tested against them.
The canonical scenario: a volcanic eruption within a 10 km radius. Mobile networks overloaded, power unreliable. LogPy carriers in the area connect over LoRa and local Wi-Fi. The situational picture emerges from the carriers’ sensors. Skills are matched locally: three people needing medication, two with first-aid training, one with an off-road vehicle — the agents suggest a meet-up, the humans decide. If a resilience center is reachable, routing runs through it; if not, locally.
I’m honestly cautious in this description. Real crises are messy. The child is crying, the first responder is having a panic attack, the patient dies on the way. Algorithms fail exactly where improvisation is needed. What the mesh can do is: make suggestions, reduce friction between helpers, share the situational picture. What it can’t do: “solve” the crisis.
A second example that matters to me, because it shows where the layer could become dangerous: an agent can reunite families — “your brother is in sector 3, here’s the shortest way” — but it can also not do that, when the risk assessment says otherwise (rubble zone, gas leak, suspected violent situation). In both cases a rule applies that I consider non-negotiable: the recommendation always carries its decision level with it. What information does it rest on? With what confidence? From what source? When was this information last measured, and how fast does it go stale? And most important of all: is the time in it computed or experienced? An agent that says “you have 20 minutes” is saying something mathematical — not experienced human time, which stretches under stress and compresses under fatigue. It has to mark that as “computed, not felt,” so the human can correct with their own gut. An agent that says “don’t go there” without disclosing why is an agent that secretly exercises power. That’s exactly what we don’t want.
So the honest claim is: gain seconds, prevent duplicated effort, find knowledge that would otherwise be lost — and make decisions visible instead of automating them away. Not: replace the disaster-response authority.
The risks we have to think through
A vision without an honest risk analysis is marketing. Here are ours.
1. Trust is the actual core feature, not skill matching. If your agent believes a stranger’s agent that says “I’m a paramedic,” what happens when that’s a lie? In crises, trust explodes — faked skills, panic manipulation from outside, bot swarms flooding the network. The identity and reputation layers are 80 % of the complexity. Skill matching is 5 %. Whoever doesn’t solve the trust problem builds nothing that holds.
2. The hardware doesn’t yet exist in the mass market. A local-inference-capable wearable that lasts a whole day and runs a 7B model locally: in 2026, not yet in the form the mesh needs. The realistic option is smartphone-in-pocket mode for the first few years. That’s fine — it just means we live with form factors that exist, instead of waiting for the perfect one.
3. Cold start is the killer problem. Adoption isn’t a question of tech elegance, but of value-on-day-one. If a LogPy carrier’s value only begins after 3 % local adoption, the 3 % never come together. Phase A (solo) has to carry, otherwise it stays a demo.
4. Tier-3 governance — the delicate point. Who operates resilience centers? State → single point of control. Private → single point of failure. Cooperative → never tested at scale. The Tier-3 model is the point where top-down creeps back in. The question “who operates it” decides whether the mesh stays resilience or becomes a parallel structure.
5. Dual use is real. Mesh + identity + skill matching is neutral infrastructure. It amplifies whatever goes in. Mutual-aid networks get better with it. Vigilante swarms, violence-prone groups with skill matching do too. “Whoever isn’t in the network doesn’t belong” is a terrible threshold that emerges on its own once the network gets useful enough. Self-limiting mechanisms have to go in early, otherwise they can’t be retrofitted later.
6. LLMs have mathematical time, not experienced time. An LLM can compute “240 seconds,” but it can’t feel how 240 seconds feel in a crisis with crying children. It knows no stress dilation, no fatigue compression, no intuition for fluctuation in sensor data. Recommendations with a time reference (“in 20 minutes,” “urgent,” “soon”) have to be explicitly marked as computed, so the human can correct with their own gut. Fluctuation detection in sensor streams isn’t the LLM’s job — statistics deliver that (z-score, rate of change), the LLM contextualizes it. Separation: numbers are computed, language comes from the LLM. Never the other way around.
7. The verification wave is coming — the only question is who builds it. EU DSA + eIDAS 2.0, the UK Online Safety Act, Australia’s under-16 ban, France’s SREN law — mandatory identity on the web is becoming reality, whether we want it or not. On top of that comes the flood of bots and AI agents in the open net, including from our own agents. The honest question isn’t “mandatory verification, yes or no,” but “central top-down solution (Apple/Google/state collects) or self-sovereign bottom-up variant (the carrier carries their identity, nobody collects it centrally).” LogPy positions itself as the bottom-up answer, not as opting out of the topic. Whoever confuses “giving up a little freedom for security” with central data collection has only seen one of the two variants. Selective disclosure + web of trust + law-enforcement-with-a-warrant-but-no-default-access is axis-A-compliant — to suppress it would be denial of reality.
The axis decision
There are two visions that look technically identical but are politically worlds apart.
Axis A — resilience layer. The mesh helps when institutions are overloaded or have failed. It cooperates with authorities where possible. Otherwise it’s invisible. It has self-limiting mechanisms that keep it from taking over tasks institutions do better. It’s compatible with an open society.
Axis B — parallel structure. The mesh sets itself up as an alternative to institutions. It refuses cooperation. It is “autonomous in the strong sense.” It’s compatible with accelerationism, crypto-anarchy, secessionist currents.
The tech is identical. The effect is opposite.
My gut feeling is clear: I believe in axis A. A layer that can work with authorities, not against them. That doesn’t make law enforcement impossible. That doesn’t force pseudonymity. That carries its self-limiting mechanisms in code, instead of merely promising them. Concretely, that means at least:
- no escalation calls to carriers
- no encryption that makes law enforcement impossible for real crimes — but no default access for authorities, only by judicial order against a single carrier
- identity is bottom-up and self-sovereign: selective disclosure per application (“I’m >18”, “I’m a paramedic with verified training”) without revealing the full name. No central data collection. No forced anchoring to state or big tech. Web of trust without a CA.
- every agent recommendation carries its decision level with it — confidence, source, justification, age of the underlying data, half-life of the statement, time type (computed vs. experienced) — no secret power through black-box suggestions
My head knows: I have to test this, not assert it. This research phase will write down the conditions under which axis A can be preserved at all. If those turn out to be untenable, the paper comes back openly.
What is certain: the axis decision becomes irreversible later on. Whoever once builds on B doesn’t come back to A. Whoever starts without self-limiting won’t retrofit it. That’s why it belongs in the discussion now, not later.
What the research phase has to test
This paper is a hypothesis, not a product. The next step isn’t a manifesto, but a validator.
2-device demo (4–6 weeks, ~€150 hardware). A Mac (existing infrastructure) as the “strong agent,” a Raspberry Pi 5 with a Hailo NPU as the “wearable proxy.” Bluetooth or a LoRa pair for the non-internet stretch. A single E2E use case: I dictate a task to the Pi, it passes it to the Mac, which carries it out and syncs back. Drift reject once with wall clock, once γ-aware. Measure the difference.
What the demo should answer:
- Does the auth story work between two LogPy carriers (LogpyClaw-to-LogpyClaw)?
- Where does wall-clock sync break once LoRa latency comes in?
- What’s the demo value for a single carrier, without a network?
- Are token costs and latencies as the γ heuristic assumes?
- Can decision transparency (confidence + source + justification per recommendation) be implemented so it stays readable for the carrier — not hidden in a machine log?
If the demo holds, the tech hypothesis is validated. If not, it was a cheap validator for the admission that there’s a gap the current substrate can’t close.
To be examined in parallel:
- evaluate HLC (hybrid logical clocks) as the standard ordering, instead of blindly kicking off LogpyClaw’s phase-6 migration
- compare Tier-3 governance models — cooperative, foundation, municipal-utility tier — which one carries the axis-A decision?
- sketch self-limiting mechanisms as code, not as a promise — including the decision-level requirement for every recommendation
- Open: whether a dedicated LLM OS (Karpathy 2024) is worth it for the stack — the same kernel from wearable to resilience center, instead of a generic model with lossy tier transitions. Only worthwhile with a university or industry partner who brings model-training expertise.
- Open: two-axis proper time as a substrate —
γ_machine(LogpyClaw’s CDC axis, reasoning effort per wall-second) andγ_human(stress-/fatigue-induced perceptual dilation). If a mesh knows both axes, it can mediate between them — e.g. tell an overloaded machine “deliver slower sentences, this human is currently in stress dilation.” That’s not phase-6 cosmetics, that’s a research path with a real use case.
Conclusion
I don’t know today whether LogPy will have 100 or 100,000 or 1,000,000 carriers in two years. I don’t know whether Tier 3 will be operated by a cooperative or by the THW or by Hetzner. I don’t know what the crisis looks like in which the network would first be truly needed.
What I do know: that the first line is under loads it can’t handle. That a second one simply doesn’t exist right now. That the parts for the second one — small models, mesh radio, agent protocols, identity stacks — are all already here and would only need to be honestly assembled.
This paper is a call to co-research. Voices from disaster response, distributed-systems research, mutual-aid practice, crypto engineering, political theory and hardware engineering are welcome. Where I tie myself in knots, tell me. Where you have your own data that tests or refutes my hypothesis, tell me that too.
The next piece of evidence I want to deliver is the 2-device demo. That’s the next update that will appear here.
— H.G.O. Dillenberg, 2026-05-09
Appendix: Status of the components
| Component | Status |
|---|---|
| LogpyClaw substrate (phases 1–5) | built, in production |
| LogpyClaw phase 6 (τ-based proper time) | open, deferred |
| A2A endpoint (single-agent, JSON-RPC 2.0) | live on rent-a-human.dillenberg.net |
| ALICE single-agent UI | live on dillenberg.net/alice/ |
| Identity / web of trust | conceptual |
| HLC spike | not started |
| 2-device demo | not started |
| Tier-3 governance model | open |
Appendix: Relationship to existing movements
We build on shoulders, not on a green field. Connections to:
- Meshtastic — LoRa mesh stack, ~100k devices worldwide. We learn from the form factor and the cold-start trajectory.
- Briar — Bluetooth/Tor P2P messaging, identity layer without a server. We learn from the trust model.
- Freifunk — Wi-Fi mesh in Germany, ~50k nodes, 20 years of experience with cooperative governance.
- Solid (Tim Berners-Lee) — personal data pods. We learn from the data-sovereignty concept.
- A2A spec — industry standard for agent-to-agent communication, the basis of our cross-tier protocol layer.
Whoever comes from these movements and fits the mesh picture is welcome. What we don’t promise: that everything from these worlds combines seamlessly. What we do promise: that we’ll try honestly.
Leave a Reply