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 → conversation work. Reactive ingress appends the event to the ordered lane and admits a wake for @on_reactive_event. A live turn folds eligible events; only eligible followups add bounded iteration credit.
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 while trusted integration code, not the model or generated-code executor, resolves provider credentials:

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

Tools declare claims, not secret handling. The SDK resolves the current user's connected account and provider token inside trusted server-side code. Normal OAuth/OIDC services can be configured from endpoints, connector-app secrets, and claim-to-scope mappings; unusual protocols can still supply an adapter.
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

Ten colleagues use the same app and workers. Each request still needs the right conversations, data, integrations, capabilities, and budget.

One deployment is bound to one tenant/project and may serve many users concurrently. The runtime carries the authenticated user and authority through request and cross-runtime boundaries.

One tenant/project deployment serves many users; each request keeps its bound user and authority.

Scoped stores and resolvers: user-owned conversations, memories, connected accounts, settings, and budgets resolve through the current request identity, not a model-supplied user id.
Per-conversation tuning inside an admin grant: users can save a model and capability set for one conversation; nothing widens beyond the app inventory (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: context carries bounded representations and refs; owning services hold bytes.

Context carries bounded refs; owning services keep the bytes.

Tools: a fixed named-service grammar replaces a growing set of near-synonym integration verbs; each realm self-describes its nouns, filters, operations, and action payloads.
Payloads: lean hits carry ref, title, and snippet; bytes are fetched or hosted outside model context through workspace materialization, signed downloads, or staged uploads.
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 when context enters as addressable objects instead of anonymous pasted text.

“What was it looking at” becomes a query.

Context objects retain canonical refs (conv:fi:…, mem:…, cnv:…, provider-owned refs); the owning resolver decides what the current requester may read.
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.
Linked identities can resolve to one platform subject through explicit connection edges and authority projection; raw external identity does not silently become platform authority.
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 authorization gates, one coherent operation:

Delegated grants at the KDCube boundary; provider claims inside the connected account.

Two gates, explicit: delegated namespace grants authorize the calling client at the KDCube boundary; connected-account claims authorize trusted KDCube code to call the provider for the current user.
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.

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

8. Deploy and update an app without rebuilding its product logic

The product logic already works. Now it needs REST, streaming, jobs, widgets, configuration, secrets, storage, accounting, and a repeatable way to deploy updates.

A KDCube app adds those runtime seams without requiring every product to use every KDCube surface:

Keep product logic; add and deploy only the runtime seams the app needs.

Declare only what this app provides: agents, API operations, jobs, MCP, widgets, named services, or a website can be added independently.
Keep product dependencies explicit: surfaces.as_consumer connects Python tools, MCP servers, named services, and UI components without publishing them as the app's own surfaces.
Configuration, secret references, storage ownership, interfaces, tests, and release metadata travel with the app package and stay synchronized.
Deploy or update from source/ref: descriptor-driven loading and app reload preserve the product boundary while the platform supplies ingress, identity, streaming, and accounting.

See: write a KDCube app · delivery & update · app descriptor

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 without ambient platform access

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 separates the requester, the materialized workspace, the isolated executor, and trusted tools:

The requester, resolver, sparse workspace, executor, and trusted tools are separate boundaries.

The agent proposes; trusted resolvers decide. Logical refs and paths are untrusted locators; the resolver binds the current tenant/project/user/authority before materializing bytes.
The executor receives a sparse workspace: in split Docker it has no network, platform or app storage roots, deployment descriptors, provider credentials, or another user's workspace.
Trusted tools stay outside: approved calls cross the supervisor socket and execute under the carried request identity, grants, provider claims, and economics context.
The contract is reusable: KDCube ReAct and externally authored agents such as LangGraph can use the same pull/workspace/ISO-exec boundary. Declared files are hosted and delivery is verified rather than assumed.

See: execution boundaries · cross-runtime context · ISO runtime

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 conversation, one saved agent setup

"The same user wants a research setup in one conversation and a cheaper, narrower setup in another. I cannot let one picker change every thread."

The app config grants the ceiling; each conversation stores its own full selection:

The app grants the ceiling; each conversation saves its own narrower choice.

Config grants the inventory: surfaces.as_consumer.agents.<id> and supported_models define what the app allows; the user can only narrow it.
Each conversation owns a saved selection: model, tools, skills, MCP tools, named-service operations, and helper-agent choice do not leak into another conversation.
Edits are a local draft: only Save changes persists them. Sending a message does not silently save capabilities; switching conversations discards unsaved edits.
A future-conversation baseline is optional: a new conversation materializes it once, or starts from app configuration. Later baseline edits do not rewrite old conversations.

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 a lane scoped by tenant/project/user/conversation/agent; a live turn folds eligible events in lane order.
Wakeup and meaning are separate: reactive ingress atomically stores the event and admits a bodyless wake. A retained task_payload decides whether unconsumed work can start a continuation; passive events wait for a live or future turn.
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

17. We already have an agent — rewriting it is not an option

"Our LangGraph, CrewAI, Claude Agent SDK, or custom loop already contains the product logic. We need production services around it, not a replacement for it."

Keep the decision runtime and connect only the seams the product needs:

Keep the agent; add runtime seams independently.

The existing loop stays responsible for decisions: graphs, prompts, tools, checkpoints, and domain code keep their jobs. One execute_core seam maps bound turn input into the agent and maps its stream and answer back to KDCube.
Scaled serving is stateless between turns: a fresh graph instance is built for one user/conversation turn and then discarded. Shared/checkpointed storage carries continuity; only true connections are reused, so another worker can serve the next turn.
Serve it through the surface you need: REST, webhook, Telegram, streaming chat, MCP, or a KDCube widget can point to the same hosted agent.
The reference is concrete: ported-langgraph-agents@2026-07-13 hosts two LangGraph agents behind one dispatcher, with conversation reload, conversation-scoped capabilities, shared storage, and optional KDCube workspace/ISO-exec tools without turning them into ReAct.

See: port your solution · hosted-agent conversation · ported LangGraph reference

18. One app needs to provide services and consume others

"Our workspace exposes chat and APIs, calls an MCP server, uses mail and tasks, and mounts a widget from another app. One flat integrations list cannot express that safely."

KDCube makes the direction part of the app contract:

What the app exposes and what it may call are two different declarations.

surfaces.as_provider says what this app exposes: API, widget, MCP, app visibility, managed auth, and default-chat intent.
surfaces.as_consumer says what this app uses: Python tools, MCP service connections, named-service namespaces, UI resolvers, and Scene components.
Each agent gets its own inventory: two agents in one app can consume different tools and service operations without changing the app's public surfaces.
The directions do not leak: consuming another app's MCP server does not republish it; exposing an API does not automatically make it callable by the app's agents.

See: app descriptor · consumed MCP · agent integration

19. The app needs a real website, not only a control-plane view

"The main view is already a complete site. We need clean public paths, several app sites in one deployment, SPA routes, and CDN caching — without hardcoding apps into the proxy."

Declare the built main view as an application-hosted website:

Descriptor to validated catalog to in-memory routing to CDN-served app files.

The declaration stays with the app: alias, hosts, and default status live in bundles.yaml, beside the main-view build they expose.
Routing is validated and hot: an immutable ApplicationSiteCatalog carries the resolved app target; Redis distributes ordered generations and each proc routes from memory.
Multipage and SPA paths work: direct files, directory indexes, and root index.html fallback share the standard app UI storage lifecycle.
The CDN forwards and caches: it preserves the viewer host and rewrites to site-root; it does not own the registry. @public_content remains the separate indexed-record mechanism.

See: application-hosted sites · website recipe · app descriptor

The pattern behind the answers

Five moves keep solving different problems: identity and authority survive every boundary; untrusted requesters ask trusted resolvers; provider and consumer directions stay separate; domains describe themselves behind a fixed grammar; every denial explains its own fix. Most difficult agent problems are product-runtime problems, and builders should not have to rebuild that runtime around every agent.