Agent Deployment Modes
Back to main doc
Rossoctl supports two agent deployment modes that coexist in the same cluster.
Mode 1: Custom A2A Agents (Rossoctl-managed)
Custom agents deployed as K8s Deployments with A2A JSON-RPC 2.0 protocol. Used for production agents with custom code and frameworks.
- Image: Custom Dockerfile per agent
- Interaction: A2A JSON-RPC 2.0 (programmatic)
- Lifecycle: Long-running Deployment
- Session management: Rossoctl backend PostgreSQL
Custom agent types in the PoC
| Agent ID | Framework | LLM | Supervisor | A2A Skills |
|---|---|---|---|---|
weather_agent | LangGraph | No (MCP weather tool) | No | N/A |
adk_agent | Google ADK + LiteLLM | LiteMaaS (llama-scout) | No | PR review via tool |
claude_sdk_agent | Anthropic SDK / OpenAI-compat | LiteMaaS (llama-scout) | No | Code review via prompt |
weather_supervised | LangGraph | No (MCP weather tool) | Yes (Landlock+netns+OPA) | N/A |
Mode 2: Built-in Sandboxes (OpenShell-managed)
Pre-installed CLI agents created via OpenShell gateway Sandbox CRs. The base image includes Claude Code, OpenCode, Codex, Copilot, Python, Node.js, git.
- Image:
ghcr.io/nvidia/openshell-community/sandboxes/base:latest(~1.1GB) - Interaction: SSH exec or
ExecSandboxgRPC (Rossoctl backend adapter in Phase 2) - Lifecycle: Ephemeral sandbox (Sandbox CR, on-demand create/destroy)
- Session management: Workspace PVC + Rossoctl backend PostgreSQL
Builtin sandbox types in the PoC
| Sandbox ID | CLI Agent | LLM | Works with LiteMaaS? | Rossoctl Skill Support |
|---|---|---|---|---|
openshell_claude | Claude Code CLI | Anthropic API | No (needs real key) | Native (.claude/skills/) |
openshell_opencode | OpenCode CLI | OpenAI-compat | Yes | Via tool/prompt system |
openshell_generic | None (bare sandbox) | N/A | N/A | No agent to run skills |
Pre-installed CLIs in base image
| CLI | Binary | LLM Protocol | Notes |
|---|---|---|---|
| claude | Claude Code | Anthropic /v1/messages | Best for rossoctl skills (native .claude/skills/ support) |
| opencode | OpenCode | OpenAI /v1/chat/completions | Good with LiteMaaS |
| codex | OpenAI Codex | OpenAI-specific | Needs real OpenAI key |
| copilot | GitHub Copilot | Proprietary | Needs GitHub subscription |
Architecture with Both Modes
Both modes share the same namespace, LLM routing (LiteMaaS/Budget Proxy), and Istio mesh. Custom agents use A2A protocol; builtin sandboxes use SSH/exec, with the Rossoctl backend serving as the unified session manager.
Target: Unified Supervisor for ALL Agents
The ideal architecture runs ALL agents under the OpenShell supervisor for both egress control and zero-secret credential management.
Current blocker: The supervisor creates a network namespace that blocks
kubectl port-forward and K8s Service routing to the agent port. A2A
tests and production traffic cannot reach the agent.
Solution: Port bridge sidecar
# Sidecar bridges pod network → netns agent port
containers:
- name: port-bridge
image: alpine/socat
command: ["socat", "TCP-LISTEN:8080,fork,reuseaddr", "TCP:10.200.0.2:8080"]
ports:
- containerPort: 8080
Benefits of unified supervisor:
- Zero-secret credential injection for ALL agents (gateway provider store)
- OPA egress control on ALL agents (not just supervised variant)
- Landlock filesystem isolation on ALL agents
- Seccomp syscall filtering on ALL agents
- Single credential management plane (OpenShell gateway)
- No K8s Secrets needed for agent API keys
What's needed:
- Port bridge sidecar (simple socat container) — can implement now
- Supervisor binary delivery via init container (proposal's Option C)
- Test that A2A works through the bridge
- OR: upstream OpenShell
--expose-portflag for native reverse proxy