Your App as a Service Provider in the Agentic Network

---

A KDCube app (bundle) can remain an ordinary backend, UI, API, or MCP service. It does not have to contain chat, an agent, or a named-service provider.

When the app does own a reusable domain, KDCube also lets it expose that domain as a realm: canonical objects, schemas, search scopes, actions, events, and presentation owned by the app. Other apps, composed UI surfaces, and configured agents can then use the realm without copying its database or hardcoding its object types.

This is an incremental integration model. Expose only the surfaces the app needs. Each surface adds reach without forcing a rewrite.

00 Highlights

The concepts the article builds on, in one place:

01 Provider and consumer are directional roles

The clearest way to read an app descriptor is by direction. surfaces.as_provider says what the app offers; surfaces.as_consumer says what the app uses. An app may be both: a reporting app can expose a dashboard and MCP endpoint while consuming connected mail and a memory namespace.

02 The interaction planes

These planes are independent:

• An app can expose MCP without named services.
• A named-service provider can exist without a UI.
• A widget can use ordinary app operations without exposing MCP.
• A scheduled app can have no human-facing surface.
• Any agent harness can consume the generic named-service tools when configured.

03 Grow the app one surface at a time

There is no mandatory order. The named-service rung matters when the app owns objects that should be discovered and acted on generically. It is not a gate in front of MCP or API integration.

04 What named services standardize

Named services separate a fixed platform operation grammar from a provider-owned domain contract. The platform-level provider protocol includes:

provider.about        object.get        object.action
provider.capabilities object.schema     object.host_file
object.list           object.resolve    object.upsert
object.search                           object.delete

event.resolve         block.produce     block.render

Not every operation is exposed directly to a model. A configured agent receives the bounded generic tool grammar:

named_services.provider_about      named_services.object_schema
named_services.list_objects        named_services.object_action
named_services.search_objects      named_services.host_file
named_services.get_object          named_services.upsert_object
                                   named_services.delete_object

The schema describes the realm in terms an agent can use; it is not a dump of provider endpoints. It names objects, selectors, filters, actions, and required authority. The provider adapter resolves those domain requests to provider IDs and performs the necessary API calls. A caller can ask for a document by title or a comment by topic when the realm declares those selectors; it does not need to know the provider's file, tab, or comment identifiers.

For a large realm, object_schema is progressive. Its root returns a recursive capability catalog; schema_path browses one branch; query searches the provider's capability declarations; and object_kind plus schema_operation expands one exact contract. This is separate from search_objects: capability search indexes only the app-owned schema declaration, while object search stays inside the provider and is only as semantic as that provider can honestly make it.

05 Three layers an agent uses

The old shorthand “about, schema, materialize” hides important ownership. The actual path has three separate layers.

The projection layer is shared runtime infrastructure: sdk/runtime/harness/events/resolver.py, sdk/runtime/harness/workspace/pull.py, sdk/runtime/harness/workspace/layout.py, and sdk/runtime/harness/timeline/projection.py. ReAct exposes react.pull and react.read as one adapter. Ported agents can use the same resolver, workspace, and timeline contracts without adopting the ReAct protocol. The materialization responsibility belongs to the harness runtime, not to the named-service tool grammar, canvas, scene, or ReAct as a framework.

06 Humans move the same canonical refs

People can drag a memory, conversation, file, metric, or provider object into chat or onto a canvas board. What moves is the canonical ref plus provenance, not a copy of the provider database.

Raw text is the exception that proves the rule: canvas hosts it as a versioned canvas-owned cnv: object first. The resulting card still points to a canonical ref. The same provider contract therefore supports agent discovery and actions, browser capability menus, pinboard proxy cards, opening an object in its rich owning widget, and on-demand workspace/timeline projection.

07 What configuration connects

A provider entry connects ownership and transport. It declares where a namespace lives and how its operations are invoked: an app registry operation, an app operation, or a module endpoint.

08 Auth is selected platform policy

The interaction network does not require one hardcoded IdP. A deployment may use the configured platform authority and session model, including Cognito, application-hosted session authority, or local/simple mode where appropriate. The relevant invariant is not the provider name. It is:

request enters with a verified platform identity or delegation
  -> runtime preserves tenant/project/caller context
  -> each fenced operation validates roles and claims
  -> accountable usage remains attributed across boundaries

An agent is not silently treated as the user. It acts through the identity and delegation assigned to that execution.

09 A live composition

The current KDCube scene demonstrates independent planes:

No one host needs to know every domain.

10 Provider checklist

For an app that should expose a named-service realm:

• Choose stable namespace and canonical ref formats.
• Document object kinds, provider-supported selectors, and actions in the schema.
• Keep provider API identifiers and call sequences inside the provider.
• Implement only the list/search/get/upsert/delete operations the domain supports.
• Return choices for an ambiguous selector; do not guess which object the caller meant.
• Advertise only operations the provider can execute through its current, configured API surface.
• Expose semantic search only when the provider supplies it; do not build a shadow index over the provider's object space.
• Return capabilities through object.resolve; execute effects through object.action.
• Return presentation metadata without making it behavioral.
• Enforce caller roles and claims inside provider operations.
• Emit important domain events when other components need to react.
• Implement byte resolution and block.produce/block.render only when objects need workspace/timeline projection.

An app may expose several provider namespaces. A provider namespace is not the same thing as the app package.

11 Consumer checklist

For an app or agent that should consume a realm:

• Add the namespace under surfaces.as_consumer.
• Grant only required named-service tools to each agent.
• Inspect provider_about and object_schema instead of guessing filters.
• Preserve canonical refs and provenance end to end.
• Route UI open/actions through provider object.resolve/object.action.
• Use runtime workspace/timeline materialization only when bytes or bounded context are actually needed.
• Keep detached-runtime calls behind the configured Data Bus boundary.

12 What to build first

Choose the smallest surface that proves the app’s value:

• Expose one ordinary API or MCP operation if callers need a command.
• Emit one event if other components need to react.
• Add a scheduled job if the app must act without a request.
• Add a widget if people need a rich surface.
• Add a named-service provider if the app owns reusable objects.
• Add an agent definition only if the app benefits from a resident agent.

That path keeps the integration small and observable.

· Closing

KDCube does not turn every app into the same kind of app. It gives each app several explicit surfaces and lets builders choose. An app can provide API, MCP, UI, events, jobs, agents, and named-service namespaces; it can consume those same classes of capability from other apps. When named services are useful, canonical refs let generic hosts compose the domain while the provider keeps ownership. Inside the runtime, configured transports cross execution boundaries. Outside it, explicit authenticated API/MCP surfaces and delegated claims govern access.

The network is connected by declared surfaces and accountable boundaries, not by hidden federation.

· Read more