AutoGPT vs Production Agents (was du wirklich brauchst) + Code

Problem (aus der Praxis)

AutoGPT-style agents are fun because they demonstrate: “the model can take actions”.

Production agents are boring because they demonstrate: “the model can take actions without breaking things”.

If you’ve ever watched an autonomous loop:

call search 40 times
paste HTML into the prompt
and then confidently choose a write tool…

…you already know the gap.

This page isn’t “AutoGPT bad”. It’s “production is different”.

Schnelle Entscheidung (wer sollte was wählen)

Use AutoGPT-style autonomy in sandboxes, internal experiments, and low-stakes exploration.
Use production agent architecture when you have budgets, tool policies, monitoring, and safe-mode behavior.
If you can’t operate it, don’t ship it. Autonomy doesn’t excuse outages.

Warum man in Prod die falsche Wahl trifft

1) They ship the prototype

The demo works once. Production needs to work 100k times under:

partial outages
bad inputs
drift
rate limits

2) They optimize for “agent completes the task”

In production you optimize for:

bounded cost
bounded time
bounded blast radius
auditable actions

Completion rate is not the only metric. Sometimes it’s the wrong metric.

3) They skip stop reasons

When the agent stops, you need to know why. Otherwise users retry, and your system becomes a retry amplifier.

Vergleichstabelle

| Criterion | AutoGPT-style prototype | Production agent | What matters in prod | |---|---|---|---| | Goal | Autonomy demo | Operable system | Reliability | | Budgets | Often missing | Mandatory | Cost control | | Tool governance | Usually loose | Default-deny | Safety | | Observability | Minimal | Trace + replay | Debuggability | | Failure handling | “Try again” | Degrade/stop | Outage containment |

Wo das in Production bricht

The usual path:

tool gets flaky
agent retries
retries multiply
prompts bloat
truncation drops policy
agent makes worse decisions

Implementierungsbeispiel (echter Code)

The production “upgrade” isn’t a better prompt. It’s guardrails:

budgets (steps/time/tool calls/USD)
tool allowlist (default-deny)
validation
stop reasons

PythonJS

PYTHON

from dataclasses import dataclass
from typing import Any
import time


@dataclass(frozen=True)
class Budgets:
  max_steps: int = 30
  max_seconds: int = 90
  max_tool_calls: int = 15


class Stop(RuntimeError):
  def __init__(self, reason: str):
      super().__init__(reason)
      self.reason = reason


class ToolGateway:
  def __init__(self, *, allow: set[str]):
      self.allow = allow
      self.calls = 0

  def call(self, tool: str, args: dict[str, Any], *, budgets: Budgets) -> Any:
      self.calls += 1
      if self.calls > budgets.max_tool_calls:
          raise Stop("max_tool_calls")
      if tool not in self.allow:
          raise Stop(f"tool_denied:{tool}")
      out = tool_impl(tool, args=args)  # (pseudo)
      return validate_tool_output(tool, out)  # (pseudo)


def run(task: str, *, budgets: Budgets) -> dict[str, Any]:
  tools = ToolGateway(allow={"search.read", "kb.read", "http.get"})
  started = time.time()

  for _ in range(budgets.max_steps):
      if time.time() - started > budgets.max_seconds:
          return {"status": "stopped", "stop_reason": "max_seconds"}

      action = llm_decide(task)  # (pseudo)
      if action.kind == "final":
          return {"status": "ok", "answer": action.final_answer, "stop_reason": "ok"}

      try:
          obs = tools.call(action.name, action.args, budgets=budgets)
      except Stop as e:
          return {"status": "stopped", "stop_reason": e.reason, "partial": "Stopped safely."}

      task = update(task, action, obs)  # (pseudo)

  return {"status": "stopped", "stop_reason": "max_steps"}

JAVASCRIPT

export class Stop extends Error {
constructor(reason) {
  super(reason);
  this.reason = reason;
}
}

export class ToolGateway {
constructor({ allow = [] } = {}) {
  this.allow = new Set(allow);
  this.calls = 0;
}

call(tool, args, { budgets }) {
  this.calls += 1;
  if (this.calls > budgets.maxToolCalls) throw new Stop("max_tool_calls");
  if (!this.allow.has(tool)) throw new Stop("tool_denied:" + tool);
  const out = toolImpl(tool, { args }); // (pseudo)
  return validateToolOutput(tool, out); // (pseudo)
}
}

Echter Incident (mit Zahlen)

We saw an “autonomous agent” connected to a browser tool. No budgets. No tool allowlist. No stop reasons.

During a vendor incident, it started retrying and re-browsing.

Impact:

~1,800 browser calls in a day
spend: ~$1,300 (mostly tool cost)
on-call time: ~3 hours to identify that the agent was the load generator

Fix:

budgets + stop reasons
degrade mode (no browser when dependencies are unstable)
tool allowlist + approvals for writes

Autonomy wasn’t the root cause. Unbounded autonomy was.

Migrationspfad (A → B)

add monitoring first: tool calls, tokens, stop reasons
add budgets (time/tool calls) and fail closed
add tool policy (default-deny) + write approvals
add replay/golden tasks to detect drift
only then increase autonomy (bounded)

Entscheidungshilfe

If it can write → approvals + idempotency + audit logs.
If it can browse → budgets + dedupe + degrade mode.
If it’s multi-tenant → scoped creds or don’t ship.

Abwägungen

Guardrails reduce “wow factor”.
Guardrails increase reliability.
If you need “wow”, ship a demo. If you need prod, ship guardrails.

Wann du es NICHT nutzen solltest

Don’t put autonomous loops on the public internet with write tools.
Don’t use “agent completes task” as your only success metric.
Don’t ship without kill switches and monitoring.

Checkliste (Copy/Paste)

[ ] Tool gateway + default-deny allowlist
[ ] Budgets: steps, seconds, tool calls, USD
[ ] Strict validation of tool outputs
[ ] Stop reasons returned to UI
[ ] Monitoring for drift (tool calls, tokens, latency)
[ ] Kill switch (disable writes/exensive tools)

Sicheres Default-Config-Snippet (JSON/YAML)

YAML

tools:
  allow: ["search.read", "kb.read", "http.get"]
budgets:
  max_steps: 30
  max_seconds: 90
  max_tool_calls: 15
writes:
  require_approval: true
monitoring:
  track: ["tool_calls_per_run", "tokens_per_request", "stop_reason", "latency_p95"]
kill_switch:
  mode_when_enabled: "disable_writes"

FAQ (3–5)

Von Patterns genutzt

Erforderliche Governance

Is AutoGPT ‘wrong’ to use?

No. It’s useful for exploration. It’s just not a production architecture by default.

What’s the first production upgrade?

Budgets + tool allowlist + stop reasons. Without those, you can’t bound failure.

Do we need replay?

If you’re changing models/prompts/tools: yes. Drift will happen.

Can we keep autonomy?

Yes, but bound it inside budgets and a tool gateway. Autonomy without limits is just an incident generator.

Q: Is AutoGPT ‘wrong’ to use?
A: No. It’s useful for exploration. It’s just not a production architecture by default.

Q: What’s the first production upgrade?
A: Budgets + tool allowlist + stop reasons. Without those, you can’t bound failure.

Q: Do we need replay?
A: If you’re changing models/prompts/tools: yes. Drift will happen.

Q: Can we keep autonomy?
A: Yes, but bound it inside budgets and a tool gateway. Autonomy without limits is just an incident generator.