Your App As A Service Provider In The Agentic Network

KDCube is an app interaction network. An app can start as an ordinary thing — its own backend, its own data, its own UI — and be useful entirely on its own. What KDCube adds is a way to connect that app's domain into a shared world, so other apps, a composed UI, and AI agents can all see and use it.

The shift is small to make and large in effect. You stop thinking of your app as a closed product and start thinking of its domain as a realm: a set of objects and actions you own. Once the realm is exposed, events make it observable, APIs/MCP make it callable, the Data Bus makes it commandable, Cron makes it autonomous, named services make its objects explorable and actionable by agents, and scene/canvas/chat make it visible and usable by people.

This entry is the big picture: how a realm gets connected — for humans and agents — and why most of it is configuration, not plumbing.

The interaction planes

A connected app participates through several planes at once. None is mandatory; each adds a capability. Reachability planes make the realm callable, observable, commandable, and autonomous; named services is the pivot — the generic object/action surface that lets agents and human-facing surfaces compose and use it.

The KDCube landing scene is itself the proof: every panel on it is a live app widget — a usage card, a stats dashboard, a news feed, a chat — wired through these planes and annotated with the app and component that owns it.

From a standalone app to an agentic realm

The journey is incremental. You can stop at any rung and still be useful; each further rung makes the realm more reachable. Nothing here forces a rewrite — an observable app just emits an event; a callable app just registers an operation. The interesting rung — the one that turns a product into a realm — is the named-service provider.

The pivot: expose your realm as an actionable surface

A named-service provider is a thin, app-owned adapter that answers a generic set of questions about your objects: about (label, namespace, capabilities), schema, search, get, resolve (what can I do with this right now?), action, and upsert where it makes sense.

The unit of exchange is the object ref — a canonical, opaque handle the provider owns, e.g. task:issue:TASK-12 or mem:record:9f3a. Everything else in the network passes that handle around without knowing what's inside it.

This is the whole trick. The provider owns the grammar, the schema, the action semantics, the presentation, and the rendering policy. The generic parts of the network — scene, canvas, chat, ReAct — only route and compose. They never hardcode what a task: or a mem: means.

The payoff is leverage: implement the generic interface once, and your realm becomes usable by every generic host — without any of them learning your domain.

How an agent sees your app

An agent doesn't get a bespoke integration with your app. ReAct — the agent KDCube ships and runs — works through a harness that hands it a governed set of tools, and your realm is one of the things those tools reach. Three families matter, and only one of them is named services.

• Named-service tools — the generic object surface a realm exposes, starting with about (the realm describes itself) and schema, then search, get, resolve, action, and materialize (pull a provider-rendered block the agent can read and cite). A realm is self-describing: an agent learns what it is and what it can do with no prior knowledge — that's how any realm becomes usable without a custom integration.
• Custom tools — for what named services deliberately don't cover: overrides of built-in platform tools (an app redefines, say, a rendering tool) and specialized, fine-grained tools that don't map cleanly onto the generic object surface. Plain domain operations usually belong in the provider, not here.
• Custom skills — higher-level composed capabilities (instructions + steps) the agent invokes as a single unit.

This isn't ReAct-specific. ReAct is the resident agent, but the named-services surface is agent-agnostic. It is a plane, not a ReAct feature: the same about / schema / search / get / resolve / action operations will be exposed over MCP (with auth), so any agent — yours, a third party's, a coding agent — can reach a realm the same way. Custom tools and skills extend the resident agent; named services let any agent reach your realm.

Block production and block rendering. When ReAct touches a remote object it does not scrape your UI or guess your schema. The provider's block-production policy turns the object into a renderable block; block rendering is how that block appears to the agent and in the turn output. The provider — not the agent — owns what its objects look like when read or cited.

Policies, strategies, validation. The harness governs the whole surface: which tools are visible to which agent (policy), how the agent may drive them (strategies), and validation of tool calls and outputs before anything is acted on. Two rules keep it all generic: actions come from object.resolve / object.action, never from local kind inference, and presentation comes from the provider's rendering policy, never from frontend hardcoding.

How users bring objects into context

People connect realms by moving objects, not by copying data. A user drags a task, a memory, a news issue, a usage figure onto the pinboard or into chat. What travels is the object ref plus its provenance — where it came from — not a snapshot of the provider's schema.

This keeps the workspace honest. The pinboard stores opaque refs, layout, comments, and provenance — it is a context workspace, not a mirror of every provider's database. Objects from different realms sit side by side because they're all just refs with a known owner. And provenance is part of the experience: opening an object routes back through the provider to the rich app behind it.

The ownership of a moved object stays cleanly layered — each part does its job and nothing reaches past it:

• Source widget — "I offer this object/text."
• Scene — "I know which configured surface this came from and where it should go."
• Canvas / pinboard — "I store and materialize it; I do not infer actions from its kind."
• Resolver / provider — "I decide what this object can do."

The host never guesses semantics, the canvas never owns schema, and only the provider decides actions. So a realm exposed once becomes: searchable by agents, pinnable by users, citable as evidence, and openable back into its full app — all from the same object ref.

The point: a generic realm, connected by configuration

Here is the sense of the whole thing. The hosts are generic. The provider is specific. The seam between them is configuration, not code.

• A scene declares which components it mounts, which surfaces they claim, and which context-drop targets accept which refs.
• A provider declares its namespace, schema, capabilities, presentation, and ReAct rendering policy.
• Presentation and actions come from the provider/config — never from frontend hardcoding. Change the policy, and every host reflects it.

That is why a new realm can join the network without anyone editing the scene, the canvas, the chat, or the agent. You connect a generic realm to its providing app with configuration, and the whole network — humans and agents — can use it.

A walk through the live scene

The current site composes four realms into one page; each shows a different mix of planes:

• Usage Card — subscribes to the accounting.usage event and refreshes from /api/economics/me/budget-breakdown. Event-driven refresh instead of blind polling.
• Stats — reads operations/dashboard_data, receives the kdcube.stats.snapshot event, and is fed by a scheduled job. Cron + Event Bus + API working together.
• Chat / ReAct — accepts dropped context and uses named services to inspect and act on other realms. User intent meets provider operations.
• Pinboard / Canvas — holds object refs and provenance from any realm, without owning any provider's semantics. Composition, not duplication.

Four apps, one scene, no host that knows what any realm "is."

Provider checklist

To turn your app into a named-service provider:

• Define a canonical object_ref format and own its grammar.
• Implement the provider-owned schema; expose search / get / resolve / action / upsert where they make sense.
• Return presentation metadata with objects, and capabilities/actions from the resolver — not from the ref prefix.
• Emit events for important changes; provide a block-production / rendering policy for ReAct.
• Preserve provenance end to end.

Configuration checklist

To connect the realm into the network:

• Declare the app's runtime, namespace, events, and data scope.
• Register API/MCP operations and any scheduled jobs.
• Configure scene surfaces and context-drop targets where relevant.
• Wire the named-services client so hosts can reach the provider.
• Keep presentation and actions in provider/config, not in the frontend.

What to build first

If you're starting today, build in this order — each step is independently valuable:

• Emit one event for your most important change. You're now observable.
• Expose one API/MCP operation. You're now callable.
• Stand up a minimal provider: about, schema, search, get. Your objects are now explorable.
• Add resolve + action. Your objects are now actionable by agents and UI.
• Declare a scene surface and a context-drop target. Your realm is now part of the composed experience.

Most of that is interface and configuration — not new infrastructure.

The full picture: realms, boundaries, and the network

Put it together and the boundaries become clear. A runtime hosts a scene, a set of provider realms, and the planes that connect them. The host composes; the providers own their domains; object refs and provenance flow between them. And because the unit is an opaque object ref and the interface is generic, the boundary of "what an agent or a user can reach" is not one app — and not even one KDCube. One runtime can reach another runtime's realms through the very same named-services interface.

That is the semantic scale of the model: connect a realm with configuration, and it joins not just one app's world but a network of runtimes — every app's domain reachable by agents and people across boundaries, with no host ever learning any realm's internals.

Closing

A normal app solves one problem well. A connected app becomes a reusable, observable, actionable realm — something an agent can search and act on, a user can pin and cite, and a scene can compose next to other realms. KDCube's job is to make that connection mostly a matter of exposing a generic surface and declaring some configuration. Expose the realm; the network does the rest.

Documentation on GitHub

Deeper dives — the live docs for everything above:

• Architecture of what you build
• Named services — overview
• Named services — providers
• Named services — clients
• ReAct object materialization
• ReAct object policy bridge
• Scene composition
• Canvas / pinboard module guide
• App component recipes