KDCube Use Cases: Problem In, Solution Out

The format is strict: problem in, solution out. Features appear only when a problem summons them.

The whole article at a glance. Jump to the number that hurts.

1. Scheduled pipelines that sometimes need judgement

"Most agent use cases can be done with a cron that calls an LLM. I don't get the fervor."

Correct — and KDCube agrees. What decides between a cron and an agent is the trigger:

The clock can take the fixed path. The other three triggers cannot.

Clock + known path → cron. The news pipeline (gather, rank, publish daily) is exactly "cron calls LLM", running in production.
A person asks → agent turn. "Find the receipts, check the Slack thread, file a task" — one intent, four domains, the plan made mid-turn.
An event fires → agent turn. Alerts and callbacks land directly in the app's @on_reactive_event hook; they start work or extend a live turn with extra iteration budget. A cron would poll, then run a fixed script anyway.
A wall appears → dialogue. Missing consent becomes a question to the user, answered with one click — and dialogue is not schedulable.

Both run in the same app, on the same budget line. When a scheduled step starts needing judgement, that step becomes an agent turn — no rewrite.

See: Claude Code agent · app lifecycle · conversation events

2. Agents and the keys to your accounts

"I built credential handling for my agents myself — and every week something breaks."

Credentials are a lifecycle (consent → refresh → live rejection → explain → upgrade → revoke); homegrown builds cover the happy path. Connection Hub covers the loop — and the agent never touches a secret:

The agent asks for a claim; the broker does the rest.

Tools resolve claims, never keys. The broker returns a short-lived credential handle; client secrets live in descriptors tool code cannot read.
Live 401 → refresh once → retry once → only then mark the account and show a reconnect card deep-linking it, with the provider's real error.
Every denial is structured: reason, labeled account candidates, a retry hint, and an absolute Connection Hub deep link that lands on the exact fix — from chat or from an external agent relaying it.
External agents get their own grants (mail:read, slack:write), tier-picked by the user at consent time — separate from provider claims, revocable, consent-snapshot-bound.

See: Connection Hub · delegate to an external client · props & secrets

3. One workspace, many humans

One agent demo is easy. Ten colleagues sharing agents, data, budgets, and integrations — with each person's stuff staying theirs — is where prototypes die.

Multi-user is the default: identity (tenant / project / user) travels through every layer.

Sharing the room shares nothing else.

Per-user everything: conversations, memories, boards, connected accounts, budgets.
Per-user tuning inside an admin grant: users toggle tools and pick models from the chat composer; nothing can widen beyond what the admin declared (section 13 is the deep dive).
The scene is the shared room: chat, boards, tasks, memories, usage as summonable widgets; auth gates the chips; cross-widget drag resolves under the dragging user's identity.
Per-user economics from day one: budgets, live usage cards, "who spent what on which agent."

See: scene · economics

4. Context that stays lean as capability grows

The context fills with tool definitions, stale history, and copied payloads — quality drops before the window overflows.

One principle, applied everywhere: context holds handles; the platform holds bytes.

Context holds handles; the platform holds bytes.

Tools: ~ten generic operations replace one-tool-per-integration; domains self-describe at runtime, so twenty domains cost what two cost.
Payloads: search returns lean hits (ref · title · snippet); get fetches on demand; binaries travel as signed URLs — a 300KB screenshot costs zero tokens.
History: past turns are searchable (conv:), never replayed; working summaries compress each turn to goal, outcome, anchors.
Cache: durable instructions stay cached; a per-turn ANNOUNCE tail carries only what changed — customization has a named prompt-cache price.

See: agent-friendly named services · context caching · files over MCP

5. Knowing where the context came from

When an answer is wrong, the lineage of what the agent saw is the first thing you need — and usually the first thing lost.

Lineage survives because context enters as addressable objects, never pasted text.

“What was it looking at” becomes a query.

Everything is a ref (conv:fi:…, mem:…, cnv:…, mail:…:attachment:…) that both sides resolve later.
Search hits carry their paths back to the turn and event they came from.
Board pins keep provenance; sharing a board shares it.
The per-turn timeline is the ledger: what the agent read, produced, and executed — "what was it looking at" is a query.

See: canvas / pin board · conversation as a named service

6. Memory that survives the session

Every session starts from zero. The agent asked my stack yesterday and asks again today.

Two kinds of remembering, separated because they decay differently:

Two kinds of remembering, separated because they decay differently.

Episodic recall (conv:): the temporal record — every turn indexed with its production context. "What did we decide in May" is one search.
Durable knowledge (mem:): co-managed typed notes — the agent proposes, a reconciler merges, the user edits in the memory widget.
Reads can aggregate across the user's linked identity family — one person, several sign-ins, one memory.
Both feed the turn as retrieved, cited context under the lean-hits discipline.

See: memory reconciliation · conversation recall

7. Working the company's mail and Slack on delegated trust

The assistant should search my Gmail and post to our Slack. An all-powerful token is out of the question; per-provider plumbing is a quarter of work.

Two consents, one move:

Two consents, one move — zero provider tokens near the agent.

Two consents, explicit: the user connects the provider account once, picking claim tiers (read yes, send maybe); the agent receives only the namespace grants approved for it — revocable, never wider.
Consent is demand-driven — the attempt is the ask. Tools stay available; the one that hits a missing claim returns a structured ask scoped to exactly that tool's claims (never the provider's union) and raises a consent card with two exits — approve, or turn off the tools that need it — while the turn keeps working.
Multi-account is explicit: results carry account labels; actions never pick an account silently.
Files cross the boundary through signed download URLs and upload slots — bytes over HTTP, never inside tool calls.

Live-verified end to end: an external agent searched mail, sent a mail with an attachment, posted a file to a channel, and pulled screenshots out of a thread — four generic verbs, zero provider tokens near the agent.

See: mail over MCP · Slack integration · files over MCP

8. From notebook to production app, updated live

Production means REST, streaming, MCP in and out, jobs, widgets, secrets, zero-downtime upgrades — suddenly the AI part is the smallest problem.

A KDCube app is one deployable unit built for exactly that shape:

You write the app; the platform is the rest of the checklist.

One unit carries it all: agents, API operations, cron jobs, MCP surfaces (served and consumed), widgets with their build pipeline, config/secrets contract.
The platform supplies the rest: ingress, auth, per-user accounting, isolation, hot reload, CI/CD.
Upgrades are descriptor changes, applied to a live deployment.
Products compose as apps of apps — preferences + news + knowledge base + two agents, each upgraded independently.

See: app developer guide · delivery & update

9. A coding agent inside automation, trusted by machines

A human reviews a coding agent's work with their eyes. A pipeline can't.

The Claude Code harness makes the work machine-checkable:

The agent declares its work; machines check exactly what was declared.

Dedicated, mapped workspace per session — the agent works only there.
Framed structured output: the agent declares what it did, in which files.
Validators inspect exactly the declared edits; only validated work is committed.
Deterministic session binding to user + conversation — follow-up and steer turns resume the same context. Running in production inside the news pipeline.

See: Claude Code agent · app agent integration

10. Machine access that is born disposable

A script needs to file tasks every night. Nobody wants it holding a person's session.

Automation access is its own credential type:

A credential born to be thrown away.

A token bound to declared resources and grants, with an expiry.
Created and revoked in Connection Hub → Delegated by KDCube: the Granted access list shows every grant — manual tokens and OAuth-connected apps alike — each with its own Revoke.
Revocation is immediate: the record is deleted, the bound session logged out, the next call rejected.
Same guard rails as human access — per-operation grants, accounting — on a credential meant to be thrown away.

See: delegated automation access

11. Generated code you can trust like a tool

The agent writes useful code — and the only way to run it is a shell tool with the agent's hands on it. Security says no, and they are right.

KDCube makes execution a contracted tool call, never a shell:

Running code becomes a tool, with a tool's trust profile.

Declare, then run: the agent submits the code and declares the expected output files — user-facing deliverables vs internal intermediates.
Run in isolation: Docker with a split container strategy, workspace quotas and a monitor. Isolation level is deployment config, never agent choice.
Outputs honor the contract: user-facing files are hosted and shown — delivery verified, never assumed (delivery_failed.file_hosting fires otherwise); everything, including failures, lands in the turn timeline.
Bounded I/O composes with tool guards — accounting, inventories, user toggles. Running code stops being the special scary tool and becomes a tool.

See: app runtime · SDK tools · custom tools & declared files

12. Agent output the web can actually find

The agent produces excellent reports and articles — and they live in chat, where no search engine, shared link, or newsletter will ever reach them.

A KDCube app publishes selected artifacts as first-class public web content:

Publish is an app operation; the web presence is the platform’s job.

The app declares a public-content provider (@public_content): which items, under which public alias — the platform renders crawlable HTML with JSON-LD, canonical and OG tags at stable URLs.
Sitemaps come from the registry: publish and retract update the per-alias sitemap; a retracted item serves 410, so stale copies fall out of indexes.
Publishing is an operation — batched (publish_many: one lock, one generation bump), so a nightly pipeline and a Publish button are the same code path.
A CDN fronts the origin through rewrite mapping (public URLs stay stable); the app remains the single source of truth.

See: public content solution · provider declaration · publishing recipe

13. One agent config, many users

"Every user wants a different agent — fewer tools, a cheaper model, no MCP — and we ship one config."

The config is an admin-granted inventory; each user narrows it for themselves:

Users can only remove — nothing widens beyond the grant.

Config grants the inventory: surfaces.as_consumer.agents.<id> declares the tools/skills; the admin-allowed model list is supported_models.
The chat "+" menu narrows it: deny-lists for tools, skills, MCP servers, and namespaces, plus one model pick — stored per (user, app, agent).
Applied per turn as configured ∩ chosen, clamped on write, fail-open — a broken selection never breaks the agent.
New config entries default ON for everyone; system tools stay locked on.

See: construct a ReAct agent · user settings · chat with a ReAct agent

14. Prompt-cache costs nobody can attribute

"Long conversations got expensive, and cache rebuilds are invisible — nobody can say which action caused what spend."

KDCube places context by lifecycle, marks every cold turn, and hands the rebuild decision to the person who pays:

The user pays for the cache, so the user decides when to rebuild it.

Placement by lifecycle: durable teaching lives in the cached instructions; turn-local state in the uncached ANNOUNCE tail — the volatile costs nothing.
Every deliberate invalidation is marked: the [CACHE] cold-turn marker and cache_cold_turn accounting metadata join the rebuild premium to the causing action — one identifiable component within the turn's spend sum.
The user holds the policy: accept · confirm · defer-cold · defer-conversation (admin default + bounds); under confirm the composer turns a costly switch into an inline choice.
Both switches are named, neither silent: a model pick rebuilds in a per-model cache namespace; a capability toggle colds one turn, then caching resumes.

See: context caching · construct a ReAct agent · user settings

15. Every new internal tool is a new frontend project

Every team needs its workspace page — chat here, tasks there, usage somewhere — and each one becomes its own web app to build, wire, and upgrade.

A scene is config + content over a shared host; the widgets come from the apps that own them:

A new alias in config mounts another app's widget — shipping the page is editing configuration.

Components are served widgets iframed from their owning apps — pinboard, chat, memories, usage — declared in surfaces.as_consumer.ui.scene.components (bundle_id + widget_alias).
Behavior is config: placement: docked|floating, rail, gated auth, drop patterns routed to a target_surface.
Context moves across surfaces: cross-surface drag, provider-resolved open actions, and surface commands — one widget summons and directs another through a declared contract — are built into the host.
The reusable host is @kdcube/components-react/scene — a new alias mounts any deployed app's widget.

See: scene configuration · scene recipe

16. The answer arrives while the agent is still working

"The agent asks for something — an approval, a callback, a human — and the answer shows up mid-run. Most stacks make it fail now and start over later."

Every conversation carries an ordered event lane; systems the agent triggers answer back into it, and the answers feed the input loop:

The grant lands as an event, folds into the live turn, and the agent finishes — no nudge, no restart.

The consent flow is the worked story: a tool attempt raises the ask; the user approves in Connection Hub in parallel; the grant lands in the lane as a conversation event, folds into the live turn — and the agent circles back and finishes.
Any system can answer back: approvals, callbacks, and alerts publish into the conversation's lane; a live turn folds them mid-work, otherwise they wait as the context the next turn opens with.
Events inform; reactive hooks act: a lane event never starts a turn by itself — starting work is the explicit @on_reactive_event contract from section 1.
Folding is total: every consumed event advances the turn's bookkeeping, even one that renders nothing — an unreadable event can never wedge a completion.

See: conversation events & ReAct output · bundle events · Connection Hub

The pattern behind the answers

Four moves keep solving different problems: identity travels everywhere; context holds handles, the platform holds bytes; domains describe themselves behind a fixed grammar; every denial explains its own fix. Most "agent problems" are platform problems wearing an agent costume.