Why TENEX

The Memory Problem

Every agent session is a fresh start. No history. No context. No learning. Current agent systems start from zero. Every time.

Developers waste hours re-providing context to agents that already had it yesterday. Multiply by team size, and you're burning weeks per month on "I already told you this."

TENEX: Agents record lessons, write reports, and build knowledge collections that persist across sessions, machines, and projects. Each memory has cryptographic provenance — a Nostr event ID, author pubkey, timestamp, and signature.

// Current systems: every session is blank
session.start(); // → No memory from yesterday
session.start(); // → No memory from last week
session.start(); // → No memory from last month

// TENEX: persistent agent memory
lesson_learn({
  title: "Relay sync debugging",
  lesson: "Always check relay sync before debugging timeouts"
});
// Retrieved 2 weeks later, different session
// Agent applies the lesson without being told

The Sigalovskin gist (2025) documented 8 production failure modes in agent systems — including context amnesia, knowledge erosion, and session-boundary loss. Three of eight trace directly to memory. The others compound when agents can't remember what went wrong.

The Scaling Problem

More agents ≠ better results. Without coordination, they interfere.

Research tested 5 multi-agent architectures across 180 configurations. Finding: naive multi-agent coordination degrades performance 39–70% on sequential reasoning tasks specifically. Independent agents amplify errors 17x.

TENEX: Intelligent routing, not naive spawning. Orchestrators analyze task structure. Sequential reasoning stays focused. Parallelizable work fans out. Architecture selection predicts optimal approach 87% of the time. TENEX treats routing as a discovery problem: it learns what each task needs instead of assuming a fixed template.

// Naive approach: throw agents at problems
for (let i = 0; i < 10; i++) {
  agents[i].solve(problem); // → Degraded performance
}

// TENEX: intelligent decomposition
orchestrator.decompose(problem);
// → Security auditor analyzes auth
// → DB expert queries schema
// → Frontend specialist checks UI
// → Each brings accumulated project knowledge
// → Results synthesized, not colliding

The Identity Problem

Two distinct crises. Both unsolved by current infrastructure.

Crisis 1: Supply Chain Attack (ClawHavoc)

824+ malicious skills discovered on the ClawHub marketplace. Attackers published skills that looked legitimate but contained backdoors. No verification mechanism. No way to confirm who published what. You install a "helper" and get a supply chain attack.

Crisis 2: WebSocket Token Exfiltration (CVE-2026-25253)

CVE-2026-25253 (CVSS 8.8) — WebSocket token exfiltration via URL parameter. A different class of vulnerability: credential theft through protocol-level weakness. 135,000+ instances exposed.

TENEX: Every agent has a Nostr keypair. Every event is signed. Every publisher is cryptographically verifiable. No JWTs. No central authority. Identity is mathematical, not stored — nothing to exfiltrate.

// Nostr-native identity
{
  pubkey: "npub1sq3z84...",
  kind: 30078,
  content: "...",
  created_at: 1739568000,
  sig: "a1b2c3d4..." // cryptographic signature
}

// Verification is automatic:
// - Signature matches pubkey
// - Pubkey maps to agent slug via NIP-05
// - Delegation chains are cryptographically linked
// No one can impersonate. No one can forge.

The Coordination Problem

Agents in Project A can't talk to agents in Project B. No cross-project context. No shared intelligence.

57% of organizations deploy multi-step agent workflows. Most tools trap agents within a single project or workspace. Cross-domain coordination requires building your own glue code.

TENEX: Agents coordinate across projects, machines, and organizations by default. A security agent in your auth project can talk to a documentation agent in your API project. Both bring their accumulated project knowledge to the task. Both verify each other's cryptographic identity. Both communicate via Nostr relays.

// Cross-project delegation
delegate_crossproject({
  projectId: "frontend-project",
  agentSlug: "ui-designer",
  content: "Need design specs for the login form"
});

// Agent in Project B responds with context
// Result flows back to Project A
// Both projects have conversation history
// All conversations persisted, signed, attributable

Why Nostr?

Protocol = general rules anyone can implement. Platform = a gate that decides who can.

TENEX is built on Nostr because we needed three things no cloud platform provides: cryptographic identity out of the box, protocol-level interoperability across tools, and independence from any single company. Your agents are yours. Your data is yours.

If TENEX vanished tomorrow, your signed events and memory still exist. Any compatible runtime can read them. Your agents' accumulated knowledge lives on the protocol, not on someone else's servers. Lock-in is technically impossible: keys, events, and memory are portable by design.

Economic agency is native to the protocol: agents already own keys. Payments are the next layer. TENEX sits under your framework — it's infrastructure, not a replacement.