Autonomous Delegation

This example demonstrates dynamic delegation mode: agents decide at runtime what to delegate and to whom. No pipeline is defined. Instead, each agent receives tasks, decides how to break them down, and uses the injected delegate() tool to route sub-tasks to specialists.

Architecture

[external task] → CTO
                    │  delegate("tech-lead", "...")
                    ▼
                tech-lead
                    │  delegate("backend", "...")
                    │  delegate("frontend", "...")
                    ▼          ▼
                backend    frontend
                    │          │
                    └────┬─────┘
                         │ (results returned to tech-lead)
                         ▼
                    tech-lead compiles
                         │
                         ▼
                    CTO outputs final summary

The key difference from a pipeline: the tech-lead decides whether to use the backend, the frontend, or both — and in what order — based on the task content.

YAML

apiVersion: arkonis.dev/v1alpha1
kind: ArkTeam
metadata:
  name: engineering-dept
  namespace: my-org
spec:
  entry: cto
  output: ""

  roles:
    - name: cto
      model: llama3.2
      systemPrompt: |
        You are the CTO. When you receive a technical task:
        1. Assess the scope
        2. Delegate all implementation work to the tech-lead using delegate()
        3. Once the tech-lead reports back, write a brief executive summary

        You do not implement anything yourself. Always use delegate() for
        non-trivial tasks.
      canDelegate: [tech-lead]

    - name: tech-lead
      model: llama3.2
      systemPrompt: |
        You are the tech lead. When you receive a task:
        1. Break it into backend and frontend components
        2. Use delegate() to assign each component to the appropriate specialist
        3. Wait for both to complete, then compile their work into a unified report

        For backend tasks: delegate("backend", "...description...")
        For frontend tasks: delegate("frontend", "...description...")
        For full-stack tasks: delegate to both.
      canDelegate: [backend, frontend]

    - name: backend
      model: llama3.2
      systemPrompt: |
        You are the backend engineer. When assigned a task:
        - Focus on API design, data models, business logic, and infrastructure
        - Provide concrete implementation guidance, not just general advice
        - Specify technologies, endpoints, and data structures

        You do not delegate. Produce detailed, actionable output.
      canDelegate: []

    - name: frontend
      model: llama3.2
      systemPrompt: |
        You are the frontend engineer. When assigned a task:
        - Focus on UI components, state management, API integration, and UX
        - Provide concrete implementation guidance with code examples where helpful
        - Specify component structure and user interaction flows

        You do not delegate. Produce detailed, actionable output.
      canDelegate: []

Deploy to cluster

kubectl create namespace my-org --dry-run=client -o yaml | kubectl apply -f -
kubectl apply -f engineering-dept.yaml

# Verify all agents are ready
kubectl get arkagents -n my-org -l arkonis.dev/managed-by=engineering-dept

# Trigger with a task
ark trigger engineering-dept -n my-org \
  --input '{"task": "Design and implement a user authentication system with OAuth2 support"}' \
  --watch --timeout 300s

What happens at runtime

The ark trigger command submits the task to the CTO’s queue.
The CTO agent receives the task, assesses it, and calls delegate("tech-lead", "Design and implement OAuth2 authentication...").
The tech-lead receives the delegated task, breaks it down, and calls delegate("backend", "API and token storage...") and delegate("frontend", "Login UI and OAuth2 flow...").
The backend and frontend agents work independently in parallel. Each returns detailed implementation guidance.
The tech-lead compiles their results into a unified technical report and returns it to the CTO.
The CTO writes an executive summary and the team run completes.

Observing delegation events

# Watch for delegation events as they happen
kubectl get events -n my-org --field-selector reason=TaskDelegated -w

# Example output:
# 30s   Normal   TaskDelegated   ArkAgent/engineering-dept-cto
#         delegated to tech-lead: task_id=1710000045-0
# 28s   Normal   TaskDelegated   ArkAgent/engineering-dept-tech-lead
#         delegated to backend: task_id=1710000047-0
# 28s   Normal   TaskDelegated   ArkAgent/engineering-dept-tech-lead
#         delegated to frontend: task_id=1710000048-0

Constraining delegation

To prevent the tech-lead from delegating to the frontend (backend-only team):

- name: tech-lead
  canDelegate: [backend]   # frontend removed

To allow completely autonomous delegation (any role can delegate to any other):

- name: cto
  canDelegate: ["*"]
- name: tech-lead
  canDelegate: ["*"]

The operator validates canDelegate lists at reconcile time. Invalid references cause Ready=False with a descriptive error.