AutoGPT vs agents de production (comparatif) + code

Le problème (côté prod)

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”.

Décision rapide (qui choisit quoi)

• 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.

Pourquoi on choisit mal en prod

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.

Tableau comparatif

| 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 |

Où ça casse en prod

The usual path:

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

Exemple d’implémentation (code réel)

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

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

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"}

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)
}
}

Incident réel (avec chiffres)

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:

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

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

Chemin de migration (A → B)

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

Guide de décision

• 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.

Compromis

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

Quand NE PAS l’utiliser

• 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.

Checklist (copier-coller)

• [ ] 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)

Config par défaut sûre (JSON/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)

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.

Pages liées (3–6 liens)

• Foundations: What makes an agent production-ready · Workflow vs agent
• Failure: Tool spam loops · Token overuse incidents
• Governance: Budget controls · Kill switch design
• Production stack: Production agent stack