Deploy a persistent Service-mode Agent and watch the controller re-cast it after Pod deletion.

First Service workload

Service mode keeps an agent available the way a Deployment keeps a Pod available. The controller owns one live AgentRun for the Agent and mints a replacement when that run exits.

Note: The example uses the published v0.1.0-alpha.2 echo image. Pin a release tag or digest in your own manifests.

Apply a Service Agent

apiVersion: kontext.dev/v1alpha1
kind: Agent
metadata:
  name: echo-service
spec:
  mode: Service
  goal: Remain available and emit heartbeats for service-mode tasks.
  provider: echo
  model: echo-model
  runtime:
    image: ghcr.io/mfs-code/kontext-echo:v0.1.0-alpha.2
    command: ["/entrypoint.sh"]
  env:
    - name: KONTEXT_MODE
      value: service
  # Long-running Service: omit budget.wallclock so the controller does not
  # impose a task-style deadline.
  backoff:
    initialSeconds: 3
    maxSeconds: 15
kubectl apply -f echo-service.yaml
kubectl get agent echo-service -w

Find the live Pod and follow its logs:

kubectl get pods -l kontext.dev/agent=echo-service
kubectl logs -f -l kontext.dev/agent=echo-service

Prove re-cast

Delete the Pod and watch the controller mint a replacement run:

kubectl delete pod -l kontext.dev/agent=echo-service
kubectl get agentruns -w

Service re-cast starts a fresh run. It does not restore in-memory conversation or local process state from the previous Pod.

Clean up

kubectl delete agent echo-service --ignore-not-found=true

Related