Engineering deep dives, industry perspective, implementation notes, and practical recipes.
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 named service presents itself to a connecting agent at three levels, not one: the always-on catalog intro , the on-demand provider.about , and the just-in-time object_schema . The difference between them — cheap-and-always, deep-on-demand, precise-just-in-time — is the whole point.
The named-services discovery service is the registry that lets a consumer find and reach a namespace published by another app — by namespace, not by hardcoded address . A provider publishes once on load; any consumer that declares the same namespace resolves to it, across app packages.
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...
ReAct — KDCube's resident agent — gets a sharper picture of its own disposable, distributed workspace: a live view that shows what is local right now versus what it must pull first, so it stops tripping over objects it should have fetched.
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.