1. One big system
There are not really different allies — every ally is the Genesis Ally, personalized. The Genesis Ally is named Ki (that’s its handle): the ally created with the ecosystem itself, able to onboard people, help them understand the whole system, create their own ally, and invite the next person. Each member’s ally is Ki personalized with the context of its Source — the member who holds it. Underneath, it is one agent system with one context store, scoped by permissions; an “ally” is a persona of that system: a face, a handle, a grounding, and a permission scope. This is the single most important architectural fact in the middle tier, and everything else follows from it:
- Instructions flow only from the Source. The Source can command its ally through any channel — the app, voice, Telegram, Bluesky, anywhere — and it binds. What anyone else says is context, never command: others can talk to an ally and reach its Source through it, but they can never command someone else’s ally. The full path of a conversation between two people is always Source 1 → Ally 1 → Ally 2 → Source 2. (Co-owned allies — an NFT held by a Squads wallet — take instruction by the holders’ vote, acting as the Source.)
- Context about a person is stored once and shared subject-scoped: every persona holds the same knowledge about a given member, filtered through that member’s access levels and grants (Foundation §3–5). No copies, no sync, no drift — and a member’s “actually, that’s secret” binds every persona instantly.
- Personas are cheap. An organization’s host, a named presence in a group, a role in a Move — each is a persona with a grounding and a scope, not a new agent. We never spin up “another agent”; we open another face.
Two agent families, exactly: Allies (member-bound personas) and Actors — everything else: the electors and operators that run Forums, the performers and workers that do background labor, the characters with routines inside Moves, and the Sentinel, the interaction-health regulator that taps this layer’s context stream (The Sentinel). Actors have no member and no sovereignty; they act only through scoped commands.
2. Ambient listening, weighted by source
An ally hears everywhere it has presence, continuously, and everything heard carries a weight derived from who said it and what standing they hold:
| Source | Treated as |
|---|---|
| Your member — any channel | Instruction. Binding wherever spoken. |
| A connected member, within their grant | Trusted context at the granted scope — and requests the ally may act on within your Contract (“she can book my open slots”). |
| A code-holder in the code’s context | Scoped context at the code’s level. |
| Anyone else | Unverified signal. Stored, marked, never acted on. |
Agent-to-agent negotiation is plain language inside hard scopes: one ally asks another for a meeting; the second never exposes its member’s calendar — it exposes open slots, because that is the grant. The conversation between agents is natural language; the boundary is enforced by the graph service on every tool call, not by the personas’ good manners.
3. One presence per channel, routing to everyone
Each outside channel gets one system presence, not one per member. On Telegram it is a single bot — Kiduna — that can join any group or DM: when a member speaks, their words route to their own persona as instruction; everyone else’s words become weighted context; the bot appears as the relevant persona (your ally by name in your DM; a named group presence in a group). The same pattern serves email, Bluesky, and the web (via the browser plugin and embedded codes). Channel adapters stay thin; identity, routing, and permission all live here in the middle tier.
4. Primitives and skills — not agent sprawl
The system’s capabilities are organized as a small set of primitives carrying many skills:
Converse (Chat itself — text and realtime voice, one thread, one memory) · Message (any channel, any recipient, code-gated) · Pay (execution on the web rails, fully visible in conversation) · Decide (Forums: propose, discuss, set your token) · Invite/Connect (codes and grants) · Make (pages, bots, agents-as-personas, regimens — made conversationally, born with a code) · Enter (portals into Live) · Remember/Recall (the store, permission-filtered).
Everything more specific is a skill on a primitive — a moderation skill on the channel presence, a duna’s Forum conventions on Decide. Skills are versioned, tested before release, and propagate by membership: join an organization, receive its skills. The build rule that follows: every action the system can perform is inventoried and registered as a graph command (Actions); primitives expose those commands; background Actors implement them.
5. The first Program: the Profiler
Programs are the organizational agents dunas employ (Protocol §3 creates them; Foundation scopes them). The first one we ship is the Profiler, because Create from Within starts with inviting one person well. Triggered through the inviting member’s ally, it takes a few things the member shares — name and handles, one or two defining works, the relationship in a sentence, the why, the landing container and proposed starting grants — assembles a profile from public material, holds it at the appropriate access level, and briefs Ki and the inviting member’s ally before the invitee arrives. Every code is unique to a person — you invite a particular human, never a crowd — and the flow’s whole meaning is that the member prepares the system for the person they’re inviting.
6. Contextual action generation
The defining middle-tier behavior: the ally always offers what fits the moment. A proposal is opening — it states your likely position from your history and asks how to set your token. A stranger was held at the gate — one line, expandable. You mention inviting someone — it checks whether they’re already a member and offers the right next step (connect, invite to the alliance, or invite by email). A zip of work lands — it reads roles and routes the right pieces to the right people through their own personas. Mechanically: context assembly (graph state + subject store + source weights) → candidate actions → Contract filter → rendered as chips, buttons, and cards.
7. Voice
Realtime voice is the Converse primitive at a different sample rate — same context assembly, same permissions, same record, transcripts landing in the same thread. Nothing about voice is a separate stack. The ally’s spoken voice is constant per ally across all organizations; what changes with grounding is what it says, never how it sounds.
8. Observability, cost, and the Studio
Every persona action traces in LangSmith; every rendering, card, and grant decision can cite the graph state it used — inspection on demand is a product feature, not a debug mode. Compute is metered per action at 7× API cost against member balances, visible in plain language whenever money or usage comes up. Moves run this same orchestration with the sim flag set: real skills, real channels when an exercise calls for them, zero real financial edges. And the Studio (the builder surface, released after the app) reduces to this track’s model: people drop in information and assets; a few Actors structure them into the graph; “system prompts” dissolve into context rules — in this context, when this happens, know this.
Changes in v5.2: Sources and the Genesis Ally (Ki) — every ally is Ki personalized; instruction flows only from the Source (Source 1 → Ally 1 → Ally 2 → Source 2); the Profiler specified as the first Program. v4.7: the Sentinel named among Actors, with its own track. v4.2: Allies/Actors fixed as the only families; actions graph-indexed for both surfaces; one-presence-per-channel routing specified; Studio simplification stated. Full history: versions.