Platform configuration

Which layer a setting belongs to

Start by deciding which layer a setting belongs to. That determines who may change it and whose work the change affects.

Deployment-level settings are maintained by operations or an administrator: the model gateway, the Git service catalogue, sandbox providers and run policy, enterprise instant messaging, knowledge retrieval models, marketplace management and connector exposure policy.

Workspace-level settings are maintained by a Workspace administrator: the Workspace model policy and quota, private capabilities inside the Workspace, and content authorisation.

Personal-level settings are maintained by each member: personal access tokens, personal model credentials, personal memory and preferences.

Model gateways

The platform manages model invocation entry points by capability class.

The conversation gateway carries model calls other than embedding — currently dialogue and reasoning, reranking, vision and speech recognition — using each model's own protocol according to its capabilities. It must not disguise a reranking, vision or speech request as an ordinary dialogue call.

The embedding gateway carries text embedding and batch embedding calls, and has its own address, model catalogue, dimension probing and runtime health contract.

Even when the two point at the same underlying gateway, their domain identities are not merged.

Credentials come in two tiers. A platform credential is the managed credential a platform agent uses to reach a global gateway, and is managed by an administrator. A user credential is a member's private credential for a particular gateway, unique per member and gateway, usable in any Workspace that member has access to.

An agent running in a Workspace does not fall back to a user credential. An ordinary member can neither read nor write platform credentials.

An administrator cannot read a user credential in plaintext.

Git services

A Git connector is a deployment-level catalogue entry. An administrator configures the provider, instance address, API address, certificates and network policy globally.

It contains no user token, and it is not duplicated per Workspace.

A user token is a member's private credential for a particular Git connector, unique per member and connector, usable in any Workspace that member has access to. Tokens are stored encrypted and do not enter the execution specification.

An ordinary user cannot create a duplicate global service. They can only save, rotate or revoke their own credential under the corresponding connector.

Sandboxes and providers

A sandbox's base image, pod compute specification and maximum retention time are deployment-level run policy. They do not belong to a Workspace, a project, a repository or a personal setting.

The control plane holds a single-instance run policy configuration, updates it under revision concurrency control, and resolves the current revision when a task is created. The public task API does not accept a client-submitted image or resource specification.

A runner image must carry an explicit version tag or digest. Untagged images and movable tags are refused.

The provider owns creating, observing, binding and cleaning up the runtime environment. A task freezes the provider identifier, plugin version, template reference, image digest and capability digest, and does not hot-swap them while it runs.

Knowledge and retrieval models

The knowledge data plane carries parsing, chunking, embedding, indexing and in-namespace retrieval of published documents.

An Organization binds exactly one retrieval instance, and each knowledge base uses its own namespace.

The dialogue, embedding, reranking and vision models needed for text and image ingestion are configured separately. Embedding uses the dedicated embedding gateway; the rest use the conversation gateway. A Workspace may be given its own credential per gateway, and inherits the corresponding platform default when none is assigned.

Knowledge governance metadata is held by the control plane, while raw document content is written to object storage.

The two systems may share a database cluster, but they must use separate databases, roles, schemas and migrations, and cross-database joins are forbidden. The two are backed up, restored and upgraded independently.

Enterprise integrations

Enterprise instant messaging configuration is Organization-level. The single Organization may hold several provider configurations but may activate only one. Authorisation and synchronisation must freeze the Organization, the external tenant and the configuration revision.

Content authorisation and sign-in authorisation are two independent authorisations, using different callback addresses.

Connector exposure policy

Connector management configures Workspace exposure policy and custom authenticated connectors. Client secrets are stored encrypted, and after a member authorises one, the proxy injects it into the managed environment under a short-lived lease.

Observability

Platform telemetry presents in-cluster resources, observability runs and task associations.

Logs, traces and metrics go to the enterprise's existing observability back end. By default only session and tool metadata is recorded — not full prompts, replies or command output bodies.

When a session body exceeds the event payload limit, the supervisor stores the complete text content-addressed by content digest inside the sandbox the task belongs to, and carries only a preview and an immutable content reference in the event. The control plane reads it through a task-scoped interface in bounded chunks each time, and does not copy the body into the business database.

The payload limit on connection messages is a protocol guard against abnormal events. It no longer decides what agent output is visible.

When a configuration change takes effect

A settings update affects only subsequent tasks. Run policy, model gateway and capability versions are frozen at task creation and cannot drift underneath an existing task.

An ordinary secret rotation affects new tasks only; an emergency revocation takes effect by terminating the affected sandboxes.

So if you change run policy and the behaviour of an existing task does not change, that is the expected behaviour and not a caching problem.