Deep dives from building an event-first, multi-user AI platform.
Search covers titles, summaries, tags and full article text.
The same person is not the same as one user_id . They arrive through many channels, each with its own verified identity. The platform keeps those ids separate , links them into a family , and asks two different questions of that family: who is this for? and what may this execution do? This Deep piece defines the foundational vocabulary the rest of the Con...
A KDCube scene mounts independent app surfaces — chat, pinboard, memories, tasks, stats — into one usable workspace without making them a monolith. The design rule is one sentence: the scene knows where surfaces are and how to reach runtimes; providers know what objects mean and what actions are allowed. This Deep piece walks the four registries, multi-ru...
An app owns a realm — task: , mem: , cnv: — with its own schema, search, actions, and rendering. Named services let a ReAct agent enter that realm without learning any of its private domain rules. The agent gets one generic interface ; the provider remains the owner of meaning. This Deep piece walks the four agent surfaces, the pull/read materialization p...
A normal app — its own backend, data, and UI — becomes a connected realm the moment you expose it once through a generic named-services surface. After that, agents and people across a whole network of runtimes can search it, pin it, cite it, and act on it — with no host ever learning what your domain "is."
The pinboard isn't a database — it's a board of proxies . Each pin holds a canonical object ref from one of many realms, never the provider's data. A conversation is an object too — pin a chat to reopen it later — and anything a chat produces can be pinned the same way, because these are generic proxies as well. Name a board and it becomes portable contex...
Every time an agent thinks, it receives exactly one thing : an ordered block of input, read top to bottom, assembled fresh for that call. This short maps its structure — the parts, in order — and the provenance of each part, with one fact framing the whole thing: the input is per agent.
The agent receives one long input every round. Where does it know to look first for what's true right now ? This short opens the tail we kept pointing at: the attention zone at the very end — a tail pair of sources pool and live view — and what lives in that live view, why it's never cached, and how a signal in it lives a short, deliberate life: refresh n...
Sending a long input every round is pure waste — most of it doesn't change. This short follows the input across calls : how the expensive prefix is reused instead of re-sent, how the freshest signals stay fresh, and how the agent can drop junk early without busting the cache. The trick isn't pretending context never changes — it's shaping what stays visible.