Most of our “agent” problems turned out to be workflow/state problems

A workflow we built called a bank API. The bank accepted the wire. The orchestrator crashed before completion was recorded. The retry ran the next steps again. The bank’s idempotency key did its job. The customer still got two notifications. That example crystallized something for us: a lot of “agent” pain is really workflow/state pain. The questions stopped being “which model should do this?” and became: * what actually ran * what got cancelled * what can safely be retried * where the state lives once the run outlives one request * how you inspect what happened after the fact That also changed how we think about agents vs workflows. A lot of what gets called an agent is still better expressed as a workflow. The path is mostly known, the steps are debuggable, approvals are explicit, and failure handling is clearer. The agentic part really starts earning its keep when the system has to adapt mid-run, recover from tool failures, or decide what to try next. But even then, the thing that bites us most often is not “intelligence.” It is state. If retries, tool calls, approvals, and side effects are all happening, local state gets sketchy fast. You need something you can inspect later without guessing which step actually committed and which one only looked like it did. The bigger lesson: model quality matters, but the production pain is usually in workflow control. Curious if others here have hit the same thing. Did your “agent” problems stay agent problems, or did they mostly turn into workflow/state/observability problems once you tried to run them for real?