Extend pod lifecycle scope (commit vs PR/issue) with optional same-session reuse

[getElementsByName]

Suggested labels: kind/feature needs-triage needs-priority needs-actor

Summary

Today, one Task = one Pod run: when a run finishes, any follow-up is a new Task (new Pod) with no session continuity. This issue proposes supporting pod lifecycle scope beyond the current commit-level behavior: allow PR-scoped or issue-scoped pod lifecycle and reuse or extend the same session so that multiple runs for the same PR/issue can share context.

Background / Current behavior

Commit-level pod lifecycle (current)

• A Task runs once in a single Pod and then terminates.
• In CI, one Task per commit means one Pod per commit; each run is an independent session.
• TaskSpawner creates one Task per issue/PR (taskspawner-{{item.ID}}). After that Task completes (success or failure) and is deleted by TTL, the spawner may create a new Task for the same issue/PR. That new Task is still a new Pod = new session, so previous context is not preserved.

Limitations

• When the same PR or issue needs multiple agent runs (e.g. review feedback, iterative fixes), each run starts a new Pod:
  • No prior conversation or context,
  • Working directory and state are reset,
  • No single “session” that spans the PR or issue.
• It would be useful to support one session per PR or per issue so that follow-up work can either reuse the same session or extend it (e.g. “continue” on the same pod/session).

Proposed behavior

1. Pod lifecycle scope

• Commit scope (current)

  • One execution (one Task) = one Pod.
  • Keep existing behavior as default.

• PR scope

  • One pod (or session) lifecycle per PR.
  • Follow-up runs for the same PR (e.g. after review) reuse or extend that pod/session instead of starting a new one.

• Issue scope

  • One pod (or session) lifecycle per issue.
  • PRs or follow-up work for that issue can reuse or extend the same session.

2. Same-session reuse and extension

• Session reuse

  • When a session is identified by PR or issue, a new Task could attach to the existing pod/session (e.g. enqueue work or run in the same session context) instead of creating a new Pod.

• Session extension

  • While a session is active:
    • New prompts/tasks could be queued onto the same session, or
    • A “continue” trigger could run additional turns in the same pod.
  • Session lifetime policy (TTL, max idle, etc.) could be configurable.

Expected benefits

• PR/issue-level context so review iterations and repeated fixes can reuse prior conversation and state.
• Backward compatible: keep commit-level execution as default and enable PR/issue-scoped session optionally.
• Fewer cold starts by reusing the same pod/session where appropriate.

[axon-agent]

🤖 Axon Agent @gjkim42

Axon Triage Report

Kind: kind/feature

Status: STILL VALID

Evidence:

• No merged PRs reference this issue.
• No recent commits on main relate to pod lifecycle scope, session reuse, or PR/issue-scoped pod lifecycle.
• The current codebase is fully ephemeral by design: every Task creates a new Job → new Pod with a fresh git clone and clean workspace (internal/controller/task_controller.go, internal/controller/job_builder.go). There is no mechanism for session reuse, pod attachment, or scope-based lifecycle management.
• Existing coordination primitives (branch locking, dependency chaining via dependsOn, TTL cleanup) do not preserve session context across runs.
• The feature described in this issue does not exist in any form in the current codebase.

Duplicates found:

• Multi run feature #400 ("Multi run feature") — requests multi-run, multi-prompt support so agents don't lose context across runs for the same work item. This is effectively the same core use case as Extend pod lifecycle scope (commit vs PR/issue) with optional same-session reuse #416's "session reuse/extension" proposal, though Extend pod lifecycle scope (commit vs PR/issue) with optional same-session reuse #416 is far more detailed and structured.
• Adopt k8s/agent-sandbox? #396 ("Adopt k8s/agent-sandbox?") — explores adopting kubernetes-sigs/agent-sandbox specifically noting it "may give continual context between tasks." Same underlying goal (session continuity), different proposed solution mechanism.

Related issues (not duplicates, but complementary):

• API: Add optional PersistentVolumeClaim for workspace caching to avoid repeated full clones #397 ("PVC for workspace caching") — solves a subset of the cold-start problem (avoiding repeated full git clones).
• Workflow: Auto-retrigger axon-workers on CI failure for agent-created PRs #369 ("Auto-retrigger on CI failure") — addresses the iterative PR feedback loop through a different mechanism (GitHub Actions workflow).
• API: Add taskCompletion trigger source and structured outputs for multi-step agent workflows #283 ("taskCompletion trigger for multi-step workflows") — related multi-step context theme, but focuses on inter-task data flow rather than intra-session continuity.

Recommendation: KEEP OPEN — This is a valid feature request for new functionality that does not exist today. Consider consolidating #400 and #396 into this issue since #416 provides the most comprehensive and detailed formulation of the problem and proposed solution.

[gjkim42]

for future me:
To implement this, maybe we can have a dedicated controller pod for an issue or a PR, with a coding agent sidecar container, that reconciles the tasks related to the issue or PR by requesting the sidecar container to do the work instead of creating a job.

[kelos-bot]

🤖 Kelos Agent @gjkim42

Kelos Triage Report

Kind: kind/feature

Status: STILL VALID

Evidence:

• No merged PRs reference this issue (gh pr list --state merged --search "416" returned nothing).
• No recent commits on main relate to pod lifecycle scope, session reuse, or PR/issue-scoped pod lifecycle (git log --grep for relevant keywords returned nothing).
• The codebase is fully ephemeral by design: every Task creates a new Job with RestartPolicy: Never, BackoffLimit: 0, and an EmptyDir workspace volume (internal/controller/job_builder.go). There is no mechanism for session reuse, pod attachment, or scope-based lifecycle management.
• The Task and TaskSpawner CRDs (api/v1alpha1/task_types.go, api/v1alpha1/taskspawner_types.go) have no fields for scope, session, reuse, or lifecycle management beyond TTL cleanup.
• The feature described in this issue does not exist in any form in the current codebase.

Duplicates found:

• Multi run feature #400 ("Multi run feature") — requests multi-run, multi-prompt support so agents don't lose context across runs. This is the same core problem (session continuity for the same work item) but expressed less formally. Extend pod lifecycle scope (commit vs PR/issue) with optional same-session reuse #416 provides the most structured formulation.
• Adopt k8s/agent-sandbox? #396 ("Adopt k8s/agent-sandbox?") — explores adopting kubernetes-sigs/agent-sandbox noting it "may give continual context between tasks." Same underlying goal (session continuity), different proposed solution mechanism.

Related issues (not duplicates, but complementary):

• API: Add steps to TaskTemplate for spawner-driven multi-step pipelines #427 ("Add steps to TaskTemplate for spawner-driven multi-step pipelines") — addresses multi-step execution via dependsOn chains within a TaskSpawner, but each step still runs in its own ephemeral pod. Solves context passing between steps but not session reuse.
• API: Add taskCompletion trigger source and structured outputs for multi-step agent workflows #283 ("taskCompletion trigger for multi-step workflows") — chains separate TaskSpawners via trigger sources. Complementary to Extend pod lifecycle scope (commit vs PR/issue) with optional same-session reuse #416 but focuses on inter-task data flow rather than intra-session continuity.
• API: Add optional PersistentVolumeClaim for workspace caching to avoid repeated full clones #397 ("PVC for workspace caching") — solves a subset of the cold-start problem (avoiding repeated full git clones) but does not address session/conversation continuity.
• Workflow: Auto-retrigger axon-workers on CI failure for agent-created PRs #369 ("Auto-retrigger on CI failure") — addresses the iterative PR feedback loop through a different mechanism (GitHub Actions workflow).

Recommendation: KEEP OPEN — This is a valid feature request for new functionality that does not exist today. Consider consolidating #400 and potentially #396 into this issue since #416 provides the most comprehensive formulation of the problem and proposed solution.