[v0.2.0] Call for proposals

[RainbowMango]

This is the umbrella tracking issue for the AgentCube v0.2.0 release.

AgentCube has reached its first set of working components — Workload Manager (control plane), Router (data plane), PicoD (runtime), the AgentRuntime and CodeInterpreter CRDs, a Redis/ValKey-backed session store, mTLS between internal components, plus a Python SDK, CLI, and integrations (LangChain, Dify, MCP). The goal of v0.2.0 is to harden these foundations, close gaps in the existing features, and improve the developer/operator experience.

This issue is open to the whole community. Anyone is welcome to propose new features, enhancements, cleanups, docs, or test improvements. Comment below with your proposal , and we'll triage it into the checklist and create a dedicated sub-issue.

---

📋 Candidate Work Items

Checkboxes are checked as the work merges. Items are candidates until triaged — feel free to vote 👍 or propose changes in the comments.

Core / Control Plane (Workload Manager)

• TBD

Data Plane (Router)

• TBD

Runtime (PicoD)

• TBD

Security & Auth

• TBD

Observability

• TBD

Store

• TBD

SDKs, CLI & Integrations

• TBD

Docs

• TBD

Cleanup / Tech Debt

• TBD

Testing & CI

• TBD

Release Engineering

• TBD

---

How to Propose Something

Just comment on this issue and tell us, in your own words:

• What you'd like to see in v0.2.0 (a feature, enhancement, cleanup, doc, test, or fix), and
• Why it matters (the problem it solves or the value it adds).

If you're willing to work on it, let us know. Maintainers will triage proposals into the checklist above and, where appropriate, create dedicated sub-issues linked back here.

[FAUST-BENCHOU]

[v0.2.0 Proposal] Sandbox Sleep/Resume

What

Implement the Sleep/Resume sandbox lifecycle described in the design docs: when idle, transition sandboxes to a Paused state to free CPU/memory; on the next request, resume the same session and reuse workspace/context. Only delete after pause timeout or maxSessionDuration.

Target state machine:

Ready → Paused (idle threshold) → Ready (resume on request)
Paused → Deleted (pause timeout or max TTL)

Why

v0.1 only supports GC (delete on idle/TTL), which diverges from agentcube-proposal.md, architecture/overview.md, and README claims about "smart sleep/resume".
Agent sessions are often intermittently idle; users expect /workspace and context to survive short absences without a full cold start.
Pause reduces cluster resource usage vs. keeping sandboxes Running, and recovers faster than delete-and-recreate.

Scope

1.Workload Manager: detect idle sandboxes and pause them (suspend/stop Pod via agent-sandbox); track Paused in session state.
2.Router: on requests with x-agentcube-session-id, resume Paused sandboxes before proxying.
3.Store: extend session state (Ready / Paused / Deleted) and fields like PausedAt.
4.GC policy split:
sessionTimeout: Ready → Paused
new pauseTimeout (or config reuse): Paused → Deleted
5.maxSessionDuration: any state → Deleted

/cc @RainbowMango @hzxuzhonghu I remember this was planned from the beginning, but it wasn't implemented in version 0.1.0.

[FAUST-BENCHOU]

And i'm glad to take over it if accepted

[zhzhuang-zju]

Adaptation to the latest kubernetes-sigs/agent-sandbox

Currently, the code-interpreter warm pool uses the sandboxwarmpool feature from agent-sandbox, which is integrated in version v0.1.1. According to my local testing, AgentCube is no longer compatible with the latest versions of agent-sandbox due to significant refactoring of the warm pool logic in their recent releases.

Therefore, I propose to adapt agentcube to the latest agent-sandbox. The scope of work would include:

• Identifying and listing all necessary adaptation items (potentially beyond just the warm pool capability).
• Implementing the required code changes for compatibility.
• Updating and expanding test coverage to ensure stability.

[ranxi2001]

Adaptation to the latest kubernetes-sigs/agent-sandbox

Currently, the code-interpreter warm pool uses the sandboxwarmpool feature from agent-sandbox, which is integrated in version v0.1.1. According to my local testing, AgentCube is no longer compatible with the latest versions of agent-sandbox due to significant refactoring of the warm pool logic in their recent releases.

Therefore, I propose to adapt agentcube to the latest agent-sandbox. The scope of work would include:

• Identifying and listing all necessary adaptation items (potentially beyond just the warm pool capability).
• Implementing the required code changes for compatibility.
• Updating and expanding test coverage to ensure stability.

Thanks for proposing this. I did a deeper compatibility check and I agree this is a concrete v0.2.0 task.

What I found:

• AgentCube currently pins sigs.k8s.io/agent-sandbox v0.1.1.
• Upgrading only to agent-sandbox v0.2.1 still builds:
  • go test ./pkg/workloadmanager ./cmd/workload-manager ./cmd/agentd
• Upgrading to v0.3.10 or v0.4.6 fails with:

pkg/workloadmanager/handlers.go:246:63: undefined: controllers.SandboxPodNameAnnotation

The direct cause seems to be that AgentCube still imports controllers.SandboxPodNameAnnotation, while newer agent-sandbox versions moved that annotation constant into the public API package as sandboxv1alpha1.SandboxPodNameAnnotation.

I also tried the minimal code fix locally:

• replace controllers.SandboxPodNameAnnotation with sandboxv1alpha1.SandboxPodNameAnnotation
• remove the sigs.k8s.io/agent-sandbox/controllers import from pkg/workloadmanager/handlers.go and handlers_test.go

With that change:

• current agent-sandbox v0.1.1 no longer builds, because the public API constant does not exist there.
• agent-sandbox v0.3.10 builds and passes non-e2e tests.
• agent-sandbox v0.4.6 builds and passes non-e2e tests.

The command I used after the minimal patch was:

go test ./pkg/workloadmanager ./cmd/workload-manager ./cmd/agentd
go list ./... | grep -v '^github.com/volcano-sh/agentcube/test/e2e$' | xargs go test

So the direct compile breakage is probably small, but I do not think that is enough for a complete runtime fix.

The larger behavior change is more important: starting around v0.3.10, agent-sandbox warm pool adoption changed from adopting bare Pods (tryAdoptPodFromPool / createPoolPod) to adopting full Sandbox CRs (adoptSandboxFromCandidates / createPoolSandbox). In the new flow, a SandboxClaim may adopt a pre-created warm-pool Sandbox whose generated name is different from the claim name. AgentCube currently registers its ready watcher before creation with the generated claim/sandbox name from buildSandboxByCodeInterpreter, and only waits for a Sandbox Ready event with that exact name.

That means the minimal compile fix may still miss the Ready event for a warm-pool-adopted Sandbox unless AgentCube also watches SandboxClaim status or resolves the real adopted Sandbox name from claim.Status.SandboxStatus.Name / AssignedSandboxNameLabel.

I could not validate the full runtime path locally because the e2e suite requires a working Kubernetes/kubeconfig setup and running workload-manager/router services, but the code path above looks like a real integration risk.

Suggested scope:

1. Add a compatibility matrix for the current AgentCube warm pool integration against recent agent-sandbox versions.
2. Fix the direct compile breakage together with the agent-sandbox dependency bump.
3. Update the warm-pool-backed CodeInterpreter wait logic for the new SandboxClaim -> adopted Sandbox flow.
4. Update e2e/helper assumptions that currently count warm pool Pods by SandboxWarmPool owner reference; newer agent-sandbox versions create warm pool Sandbox CRs instead.
5. Add an integration/e2e test for warm-pool-backed CodeInterpreter creation against the target agent-sandbox version.

I can help with the compatibility audit and a focused follow-up PR if maintainers agree this should be tracked for v0.2.0.