Skip to main content

Goals and Rubrics

How the agent plans, tracks, and verifies multi-step tasks

When you give k8s-autopilot a complex, multi-step task — like setting up monitoring for a cluster, deploying a Helm application with ingress, or migrating workloads — the agent doesn't just start blindly executing commands. It first proposes a goal with concrete, verifiable acceptance criteria, waits for your approval, and then works through the task while continuously evaluating its own progress against those criteria.

This is the goal and rubric system. Goals define what needs to be achieved. Rubrics define how success is measured. Together, they ensure the agent doesn't declare "done" until the work actually passes verification.

How It Works — The Full Picture​

Here is the typical flow when you ask the agent to execute a non-trivial infrastructure operation:

User Task ──► Propose Goal ──► You Review ──► Active Rubric ──► Tactical Checklist ──► Grader Verification

1. You Describe a Task​

You type something like:

Deploy a Redis cluster with persistence, configure ServiceMonitor for Prometheus, and add network policies

2. The Agent Proposes a Goal​

For multi-step or infrastructure-modifying tasks, the agent automatically drafts a goal. It analyzes your workspace — your repository, existing Kubernetes resources, and context — to create concrete, verifiable acceptance criteria.

The proposal looks like:

Objective: Deploy a Redis cluster with persistence, monitoring, and network isolation

Acceptance Criteria:

  • Redis StatefulSet deployed with 3 replicas and PVCs bound
  • Persistent storage configured with appropriate StorageClass
  • ServiceMonitor resource created and scraping Redis exporter metrics
  • NetworkPolicy restricts Redis access to permitted namespaces only

3. You Review and Approve​

The goal is presented to you for review in the UI. You have three options:

ActionWhat Happens
ConfirmAccept the criteria as-is. The goal becomes active.
EditModify the criteria — add, remove, or change items — then confirm.
RejectSend feedback, and the agent regenerates the criteria based on your input.

You can also dismiss the proposal entirely if you'd rather work interactively without a formal goal.

4. Accepted Criteria Become the Active Rubric​

Once you accept the criteria, they don't just sit as a passive checklist. They become the active rubric — a formal set of conditions that the system uses to evaluate the agent's work.

The criteria remain active for the entire duration of the task. Every action the agent takes is oriented toward satisfying these criteria.

5. The Agent Executes with a Tactical Checklist​

While the rubric defines what success looks like, the agent also maintains a tactical todo list for the step-by-step execution plan:

  • Items are marked pending, in_progress, or completed as the agent works.
  • The todo list can be revised if the plan adjusts during execution.
  • It keeps the agent anchored to the plan, especially during long operations with many tool calls.

6. Completion Is Verified, Not Self-Assessed​

When the agent believes all criteria are satisfied, it doesn't simply mark the goal as done. Instead:

  1. The agent stages a completion request with supporting evidence.
  2. A rubric grader independently evaluates the work against the accepted criteria.
  3. If the grader confirms all criteria pass → the goal is marked complete.
  4. If anything fails → the grader sends a specific deficiency report back to the agent.
  5. The agent remediates the gaps and resubmits.

This prevents the agent from giving itself a passing grade on something it missed.

Goal Lifecycle​

A goal moves through four primary statuses:

StatusWhat It MeansWho Controls It
ActiveThe agent is actively working toward this goalSet upon user acceptance
BlockedThe agent hit an obstacle and needs user inputAgent reports it
PausedYou paused the goal — preserved but not driving workYou control this
CompleteAll acceptance criteria have been verifiedRubric grader confirms

The agent can mark a goal blocked when it cannot proceed without your clarification, and it can request complete — but completion only takes effect after rubric verification. Only you can pause, resume, or clear a goal.

Rubric Grading​

The rubric grading system is what makes goals reliable.

The Grading Loop​

┌────────────────────────────────────────────────────────┐
│ Worker Agent executes steps toward accepted criteria   │
└──────────────────────────┬─────────────────────────────┘
                           │
                           ▼
┌────────────────────────────────────────────────────────┐
│ Worker stages completion request                       │
└──────────────────────────┬─────────────────────────────┘
                           │
                           ▼
┌────────────────────────────────────────────────────────┐
│ Rubric Grader evaluates state against active criteria  │
└─────────────┬────────────────────────────┬─────────────┘
              │ Deficiency Found           │ All Pass
              ▼                            ▼
┌───────────────────────────┐    ┌───────────────────────┐
│ Deficiency Report Issued  │    │ Goal Marked Complete  │
│ (Worker fixes & resubmits)│    │ Task Finished         │
└───────────────────────────┘    └───────────────────────┘
  1. The worker agent does its work based on the accepted criteria.
  2. When it believes the work is done, it stages a completion request.
  3. The rubric grader evaluates every criterion against the live state of the cluster.
  4. Failed criteria generate a deficiency report — a specific explanation of what's missing.
  5. The worker receives the report, fixes the gaps, and resubmits.
  6. This repeats until all criteria pass or the iteration limit is reached.

Cross-Model Grading​

For higher reliability, the grader can use a different model than the one doing the work. For example, if the worker uses Gemini, the grader might use GPT-4o, or vice versa. This eliminates self-evaluation bias — the worker cannot overlook its own mistakes.

Grader Safety​

The rubric grader is strictly restricted to evaluation only:

  • It can only read resources and files explicitly referenced in the worker's output.
  • It cannot modify files, run mutating commands, or make external state changes.
  • Its role is strictly verification: does the work meet the criteria, or not?

Amending Goals​

If you realize mid-task that the criteria need to change, you can amend the goal simply by telling the agent what to adjust:

Also add a criterion for TLS encryption on the Redis connections

The agent revises only the affected criteria while preserving everything else and any progress already made.

When Goals Are Not Needed​

Not every request needs a goal. For simple, single-step tasks — checking pod status, reading logs, querying Prometheus, or answering an architectural question — the agent acts directly without proposing a formal goal. The goal system activates automatically when the agent detects a task involving multiple steps, architectural changes, or infrastructure modifications.

Practical Example​

You say:

Set up Prometheus monitoring for the production cluster — deploy kube-prometheus-stack 
via Helm, configure ServiceMonitors for all existing deployments, set up alerting rules 
for pod restarts and high memory usage, and create a Grafana dashboard

What happens:

  1. The agent proposes a goal with criteria:

    • kube-prometheus-stack Helm release deployed and healthy.
    • ServiceMonitor resources created for each deployment.
    • PrometheusRule configured for pod restart and memory alerts.
    • Grafana dashboard ConfigMap created with relevant panels.

  2. You review and confirm (or edit) the criteria.

  3. The agent maintains a tactical checklist:

    • [in_progress] Deploy kube-prometheus-stack Helm chart
    • [pending] Create ServiceMonitor resources
    • [pending] Configure alerting rules
    • [pending] Create Grafana dashboard

  4. As it works, it checks off items and verifies each step.

  5. When all criteria appear satisfied, the rubric grader independently checks:

    • Are the pods actually running?
    • Do the ServiceMonitors match the right labels?
    • Are the PrometheusRule alert queries syntactically valid?
    • Does the dashboard ConfigMap contain valid JSON panels?

  6. If verification passes → Goal complete. If not → The agent remediates the deficiency report.

Next Steps​