Agents need control flow, not more prompts

LLM-based “agents” are proving too unreliable when asked to manage their own workflows purely through prompts, leading many engineers to reintroduce explicit control flow and deterministic code around them. Commenters argue that models should be treated as probabilistic components used for translation, planning, or heuristic decisions inside well-defined, testable pipelines, with tools, workflow engines, and quality gates enforcing real-world constraints. The emerging consensus is that reliability comes from harnesses, DSLs, and verification layers that own the process, while agents are just one fallible part of a larger system.

Determinism vs. Probabilistic Models

  • Many commenters argue you cannot get true determinism from LLMs; at best you get “high probability under expected conditions.”
  • Even with fixed seeds and temperature, floating‑point behavior and context sensitivity make outputs chaotic.
  • Others stress that engineering is precisely about wrapping unreliable components in deterministic systems, so “good enough” reliability can be acceptable for some domains but not for safety‑critical ones.

Control Flow vs. Prompting

  • Strong consensus: once you’re writing prompts that shout things like “MANDATORY” or “DO NOT SKIP,” you’ve hit the limit of prompting.
  • The recommended pattern is: deterministic control flow outside, LLM calls inside. Use traditional code, DAGs, or workflow engines to orchestrate steps and invoke LLMs only where ambiguity or judgment is needed.
  • Several people describe moving from “LLM drives the whole loop” to “LLM is just one step in a deterministic harness,” with big gains in reliability and cost.

LLMs as Code and Tool Generators

  • A recurring theme: use LLMs to write scripts, tests, and DSL programs, then run those deterministically and reuse them.
  • People describe success turning specs or documents into parsers, generators, and validators, then only invoking LLMs when deterministic checks fail.
  • This “compile prompts into code” pattern is seen as a way to turn non‑deterministic reasoning into repeatable automation.

Guardrails, Verification, and Human-in-the-Loop

  • Control flow only constrains what an agent may do; it doesn’t verify what it actually did. Several commenters note verification layers are underdeveloped.
  • Proposed mechanisms: hooks, policy engines, quality gates, unit tests, compilation checks, and separate “reviewer” agents.
  • Many insist that for anything high‑risk (money, healthcare, production changes), a human must remain in the loop, or at least behind API layers with strong validation.

Agents, Workflows, and Cost

  • Some see “pure agents” as overused: many tasks that people wrap in agents could be simpler scripts or workflows calling a single LLM.
  • There’s experimentation with multi‑agent setups (planner, worker, reviewer, supervisor), but token burn and complexity are major concerns.
  • Overall drift: away from magical, fully autonomous agents and toward explicitly designed workflows, where LLMs are powerful but tightly leashed components.