Cosmonic

Agents act in outside systems through tools, each built as its own sandboxed component. A developer writes a typed tool as an ordinary interface, adds it to a session and grants it exactly the hosts, folders and secrets it needs, so a ticketing tool can update tickets on one host while a CRM reader only reads users on another. MCP servers run as sandboxed services beside custom tools, and Launchpad offers ready made ones such as a GitHub server that reaches GitHub's API and nothing else. On Desktop, MCP servers that need credentials are not supported yet.

Sourcecosmonic.com/docs/agent-sdk/give-an-agent-a-toolread 2026-11-09

The host drives each agent run: the harness loop sends the conversation to a model, runs the tools it asks for and repeats, while every model and tool call is journaled before it starts and after it ends so a restarted run picks up where it stopped. Runs in one session take turns, one at a time. Workloads chain components into pipelines over NATS subjects or Kafka topics, and Control scales them with demand. There is no coordinator that delegates work to other agents, branches between them or runs them in parallel.

Sourcecosmonic.com/docs/agent-sdk/how-an-agent-runsread 2026-11-09

Cosmonic runs the agent's code and tools rather than a store of the customer's knowledge. A tool can be granted one folder and search it at call time, and volumes and blob stores hold files that components read, but nothing indexes, embeds or maintains the customer's documents for retrieval across runs. A retrieval service the team runs elsewhere reaches the agent only as a sandboxed tool or MCP server with a narrow grant.

Sourcecosmonic.com/docs/agent-sdk/tool-granularityread 2026-11-09

People decide what an agent may use rather than approving each action. On Desktop, the tools a session can call are the ones a person approved for it, an MCP server's tools need approval again whenever a tool definition changes, and a new version that asks for a new host or folder needs a new grant. On Control, the reviewed workload manifest is the approval. A tool call whose effect is unknown after a restart is marked unresolved for a person to check instead of being repeated. Nothing pauses a single action until someone signs off.

Sourcecosmonic.com/docs/agent-sdk/why-capability-drivenread 2026-11-09

Cosmonic Control maps tenants to Kubernetes namespaces with namespace scoped roles, so a team manages only its own workload deployments, HTTP triggers and artifacts while the operator alone holds the cluster role. Admission policies cap what any tenant may grant its workloads, and each tenant namespace gets Pod Security enforcement and quotas. Images are digest pinned and signature checked, secrets resolve as references that never appear in manifests or the UI, and model keys stay with the host. Cosmonic lists no SOC 2 report, ISO certification or trust center.

Sourcecosmonic.com/docs/operations/tenant-rbacread 2026-11-09

Every model call and tool call is written to the session journal as it starts and as it ends, with its arguments, outcome, author and time, and the journal can be followed live from a chat window or dashboard. On Desktop, the session panel shows the model, the spend, each tool's reach and image digest and every call each tool made, beside structured logs for the daemon and its workloads. Cosmonic Control ships an OpenTelemetry stack with Prometheus, Loki, Tempo and Perses dashboards, and workloads emit their own traces, metrics and logs into it.

Sourcecosmonic.com/docs/observabilityread 2026-11-09

Each agent workload keeps one session, a journal of every message, model call and tool call that the host stores outside the agent: encrypted files on Desktop, with a key per session that is destroyed when the session is deleted, or an encrypted NATS JetStream bucket on Control. Any instance can resume the conversation after scaling to zero or a restart, and compaction summarizes older context without deleting history. Tools get small stores of their own for cursors or caches. A session is capped at 64 MiB and has to be cleared when full, and nothing carries one conversation into another.

Sourcecosmonic.com/docs/agent-sdk/where-sessions-liveread 2026-11-09

The whole stack runs where the customer puts it. Cosmonic Desktop runs on macOS, Windows and Linux, online or off, with workloads and data kept on the machine. Cosmonic Control installs with Helm on any Kubernetes, including EKS, AKS, GKE, OpenShift and VMware vSphere, in the customer's cloud or data center, and supports fully air gapped installs by mirroring every chart and image to an internal registry. No hosted sandbox service sits in the path, and model calls go from the customer's host to the provider it picks.

Sourcecosmonic.com/controlread 2026-11-09

Starting points come ready to run rather than as finished agents built for a business task. Desktop's Launchpad is a curated catalog of templates, apps, samples and MCP servers that launch in one click, already sandboxed and signature checked. The template catalog adds HTTP server, TypeScript MCP server, NATS, Kafka and blob store starters, and Build picks one from a prompt. Harness images of Pi, OpenAI Codex and Goose, plus a small reference harness in Rust, run on Desktop's Agents page and on Control.

Sourcecosmonic.com/docs/agent-sdk/harnessesread 2026-11-09

Work reaches an agent on Cosmonic Control in two ways: an HTTP request in the OpenAI Responses API format, or a message on a NATS subject, each starting a run on the agent's session. HTTP triggers route traffic from the built in ingress to workloads and can require a bearer token on every request, and components consume NATS and Kafka messages as handlers. Idle workloads scale to zero and wake on the next request or message. On Desktop, a person starts runs from the Agents page.

Sourcecosmonic.com/docs/agent-sdk/run-on-controlread 2026-11-09

The host makes every model call, so the model is a setting rather than code. On Desktop a person adds model sources (a local Ollama, Anthropic, OpenAI or any OpenAI compatible service), picks the source and model for each new session and can switch between runs. On Control, the operator lists sources with a base URL, a default model, an optional allowlist of models and a key held in a Kubernetes secret, and each workload picks a source by name. Agents and their tools never see a key.

Sourcecosmonic.com/docs/agent-sdk/choose-a-modelread 2026-11-09

Control is driven through Kubernetes: custom resources for workloads, workload deployments, artifacts, hosts and HTTP triggers, with a published API reference, Helm charts and GitOps delivery through Argo CD. Agents are built against the open cosmonic:agent interfaces, licensed Apache 2.0 and published as a WIT package, and runs start over HTTP in the OpenAI Responses API format or over NATS. Desktop adds the cosmonic CLI and an MCP server that lets Claude Code, Codex, Gemini CLI or any MCP client build and deploy sandboxed workloads.

Sourcecosmonic.com/docs/api-reference/control.cosmonic.ioread 2026-11-09

There are no test cases, scoring or quality gates for an agent's behavior. The session journal and the Desktop session panel show what a run did and which tools it called, which helps trace a fault after the fact, and a developer can change the harness code, rebuild it and run the session again by hand. Comparing agent versions or grading their output is left to tools the team brings to the sandbox.

Sourcecosmonic.com/docs/agent-sdk/build-your-first-agentread 2026-11-09

No browser or desktop for an agent to drive comes with Cosmonic. Components are WebAssembly programs that start with no screen, files or network, and a tool reaches the web only through HTTP calls to the hosts it was granted, so a page fetcher reads what a granted site returns without operating it. The Desktop app is where people inspect, approve and run workloads, not an interface an agent operates.

Sourcecosmonic.com/docs/agent-sdk/how-an-agent-runsread 2026-11-09