Deep dives from building an event-first, multi-user AI platform: agents, credentials, memory, runtime.
Search covers titles, summaries, tags and full article text.
The complete hands-on authoring story: nouns and refs, search vocabulary, role-guarded use cases, honest guards, the presentation layer — and the test that a realm now has two readers : an agent that works it from the schema, and a user who understands and controls it from its service card.
Two ways into a running KDCube — a one-command clean bootstrap that stages a configured ecosystem, and a descriptor set that reproduces an environment as a reviewed artifact — and the one operating loop you live in afterwards.
Sixteen real problems, stated the way practitioners state them — each answered with the concrete KDCube mechanism that solves it. Problem in, solution out, links to go deeper. A living piece: new problems get appended as we meet them.
Named services give an agent one small grammar — list, search, get, act — and let every domain teach its own vocabulary at runtime. A domain models itself once, as a realm : typed objects, self-contained refs, its own search questions, and role-guarded use cases. Any operator — the chat agent, an external agent over MCP, a UI — works every realm through t...
An app creates a ReAct agent mostly by declaring it: one config surface defines the agent's teaching, its tools/skills inventory, and its allowed models; the user tunes within it from the chat composer; and the platform keeps the result never wider than granted — with every customization's prompt-cache cost named honestly.
A signed-in KDCube user can now mint a short-lived bearer token for their own automation, scoped server-side by resource_grants ( resource → grants[] ) plus selected operations. The token is only a handle — the guard loads the server-side grant record and enforces resource-grant matching per call. Grants never union across resources: {A: read, B: write} c...
KDCube can turn a browser user into a platform user through Cognito, multiple Cognito pools, a local SimpleIDP, or an application-hosted login. These are not interchangeable — they differ in who proves the user, which credential is written, and which verifier accepts it. This overview puts all methods side by side, anchored on one contract: Connection Hub...
Sometimes the product already has a login page, a branded sign-in, or an upstream proof like Google. An application can host the platform login and consent screens while Connection Hub owns the authority registry and KDCube still verifies a standard platform session. This piece walks the split: the app hosts the door, Connection Hub registers what the doo...
A conversation is not a request and a reply — it is an ordered event bus , one lane per conversation, and a turn is a consumer that briefly owns it. Everything lands there in order: a prompt, a widget save, a webhook, a mid-flight "stop." The hard part is not delivery — it is ownership when turns overlap, and guaranteeing a stale turn can never commit. Th...
An external client speaks MCP and wants a KDCube service. The lazy answer — a shared secret — fails the moment you ask whose data it acts on, what it may do, who pays, and how to turn one connection off. KDCube's answer is a delegated credential : a bearer KDCube issues, scopes to one resource, narrows to consented tools and grants, and records back to th...