KDCube
← Our Journal
2026-07-10 · Journal

The Portable Context Room

runtime portable-spec request identity named services the situation travels

A tool call leaves the process — a subprocess, a sandboxed container, a remote task. What must follow it is not the infrastructure but the situation: who is asking, which app is acting, what the call may touch. KDCube packs that situation into one JSON-safe room, ships it across the boundary, and rebuilds everything else from descriptors on the other side.

KDCube executes work in more places than one process: the host proc, local subprocesses, isolated Docker executors behind a privileged supervisor, remote tasks. Code on the far side still calls the same SDK accessors — request context, bundle call context, named-service discovery — and they answer correctly because a portable context room traveled with the work.

ONE ROOM, THREE LIVES Host proc task bound contextvars REQUEST_CONTEXT BUNDLE_CALL_CONTEXT NAMED_SERVICE_DISCOVERY run_ctx · accounting live services stay here PORTABLE_SPEC_JSON JSON-safe, small, auditable comm_ctx snapshot (identity, authority, call context, discovery) named_services_context client_id + as_consumer policy no handles · no secrets · no blobs Target runtime subprocess · docker supervisor · remote restores the same contextvars rebuilds services from descriptors same SDK accessors answer; named-service calls carry the same allowances as direct calls snapshot restore The situation travels; the infrastructure is rebuilt. Provider calls on the far side authorize through the carried identity, never a model-supplied one.
One room, three lives: bound in the host, serialized as JSON, restored in the target runtime.

What travels

  • Request identity and authority. The actor identity (which may be a surface identity such as a Telegram subject) plus the resolved authority projection — platform user, roles, economics owner — travel already-resolved. Downstream checks read the projection; they never re-derive who the actor is.
  • Bundle call context. The bundle-owned corner of the room: ids, execution modes, correlation ids, request-scoped policy snapshots. Small, JSON-safe values only.
  • Named-service discovery. A four-field descriptor (schema, backend, tenant, project) — the target runtime reconstructs the provider lookup from it. The directory itself never travels.
  • Named-service client policy — the newest member. The acting client_id and the surfaces.as_consumer descriptor subtree the policy reads. With it, a named-service call made from generated code carries exactly the allowances of a direct agent call: a send the agent may perform, its code may perform. A spec without this member leaves the child on the read-only operation defaults.

Reconstruction, not serialization

The room's discipline is what it refuses to carry: no connection pools, no live clients, no secrets, no large payloads. The target runtime rebuilds Redis, model services, and the tool subsystem from descriptor-backed settings, then binds the restored context around them. That keeps the room small enough for any transport — an env var into a subprocess, a container override into a remote task — and keeps every boundary crossing auditable: what the far side knows is exactly what the room says.

Provider calls from the far side still run through runtime bridges, and they authorize through the carried request identity — never through a model-supplied user id.

Related documentation