---
title: When not to use agents
description: Prefer deterministic Jobs and scripts when model judgment is not justified.
sidebarTitle: When not to use agents
---

# When not to use an agent

Use an agent when the task genuinely needs model judgment over variable input
and the extra latency, cost, nondeterminism, and operational dependencies are
acceptable. Kubernetes makes those dependencies visible; it does not remove
them.

A deterministic Job, controller, or script is usually better when:

- the input and desired transformation have a complete, testable rule;
- exact repeatability or byte-for-byte output is required;
- a command/API call already performs the task directly;
- retries could duplicate a destructive side effect;
- the task is on a latency-critical path;
- provider network access, quota, or credential handling is unjustified;
- success cannot be checked more reliably than asking another model;
- the workload needs durable workflow state that the runtime does not provide.

Start with a deterministic baseline. Measure correctness, wall time, resource
use, and failure recovery on the same inputs. Add a model only where it
improves a named metric enough to justify provider usage and new failure modes.
Run deterministic graders before any optional model judge.

For mixed workflows, keep parsing, validation, authorization, and irreversible
actions deterministic. Give the agent a bounded proposal step, validate its
structured output, and let ordinary code apply approved changes. A tool being
available is not evidence that it ran; require tool events or downstream
state as proof.

Kontext is also not a workflow engine, retrieval platform, or durable memory
store. Mounted ConfigMap knowledge is static context, not RAG. If the product
needs fresh authorization-aware retrieval, checkpoints, compensation, or
multi-step durable orchestration, use systems designed for those concerns and
run only the model-dependent step as an `AgentRun`.