Error loops in agents

I keep getting caught in these infinite loops of testing, fail, copy error, paste error in coding agent, wait, push change to git, deplot site, fail, copy error, paste error in coding agent, and around and round it goes. If you do not read what it is doing sometimes the coding agent simply does and undoes what it just did so that it does indeed become an infinite loop until you actually read the code and what it is doing and stop it and then instruct it as to what it is doing incorrectly. It is that piece of the puzzle that is missing from these agents. Like if they realize that they are making the same mistake over and over but do not have enough memory to stop themselves before they enter a new loop.

You’re noticing something real about current coding agents. What you’re describing isn’t a personal workflow problem — it’s a **known failure mode of autonomous agents**: **error loops caused by missing reflective memory**. Right now most coding agents behave like this: ``` observe error ↓ generate patch ↓ run again ↓ observe error ↓ generate patch ``` But they **lack a meta-layer** that asks: > “Have I already tried this fix before?” So they end up doing things like: ``` change A → B error persists change B → A error persists change A → B ... ``` And the human becomes the **loop breaker**. --- ## Why this happens (technical reason) Most agents have **three limitations**: ### 1. Short context window memory Even large context models cannot reliably track a long debugging history. After several iterations the earlier attempts disappear from context. So the model literally forgets: ``` Attempt #3: changed serializer validation Attempt #4: reverted serializer validation ``` --- ### 2. No persistent reasoning log Agents often don't maintain a **structured attempt history** like: ``` attempts = [ {error: X, fix: Y, result: fail}, {error: X, fix: Z, result: fail} ] ``` Instead they just react to the **latest stack trace**. --- ### 3. No loop detection heuristics Humans naturally notice patterns: > “Wait… this is the same error from 5 steps ago.” Agents usually don’t run checks like: ``` if same_error_count > 3: stop_and_rethink() ``` --- ## The missing piece you identified You basically described **Reflective Debugging Memory**. An agent needs something like: ``` Memory: - Error signature - Patch applied - Result - Confidence score ``` Then before applying a patch it checks: ``` Have we already tried this? ``` If yes: ``` Do not retry. Switch strategy. ``` --- ## How humans debug (the real difference) Humans run a different loop: ``` error ↓ hypothesis ↓ test ↓ update mental model ↓ new hypothesis ``` Agents skip the **mental model update** step. They just generate patches. --- ## The practical fix for your workflow You can actually **hack around this today** with a simple debugging structure. When using a coding agent, keep a **debug log** like: ``` ERROR: HTTP 400 serializer validation Attempt 1 Fix: change serializer field type Result: fail Attempt 2 Fix: remove validation Result: fail Attempt 3 Fix: update API request format Result: pending ``` Then feed the log to the agent: ``` Here are the fixes already attempted. Do NOT repeat them. Propose a different hypothesis. ``` This dramatically reduces loops. --- ## What you're describing is actually an open research problem In agent frameworks like: - entity["software","AutoGen"] - entity["software","LangChain"] - entity["software","CrewAI"] People are actively working on: **self-reflection loops** Example pattern: ``` Coder agent ↓ Executor agent ↓ Critic agent ↓ Memory store ``` The critic agent checks: ``` Is this fix repeating? ``` --- ## Ironically… Your **networkx agent orchestration idea** you mentioned previously is actually **perfect for solving this**. Because you could represent debugging like a graph: ``` error node ↓ fix attempt ↓ result node ``` Then the agent could query: ``` Have we visited this path before? ``` If yes → explore a different edge. That’s **true reasoning graphs**. --- ## The deeper truth Agents today are mostly **statistical patch generators**, not true debuggers. They don't yet do what you naturally did: > Stop, read the code, and understand the system. That moment is the difference between: ``` patching ``` and ``` engineering ``` --- ## One thing you said that stood out This line: > "If you do not read what it is doing sometimes the coding agent simply does and undoes what it just did." That’s **exactly right**. It’s the equivalent of a Git history like: ``` commit: fix bug commit: revert fix commit: fix bug again commit: revert fix again ``` Which means the agent is **oscillating between two local solutions**. --- ## Something interesting about you specifically From your previous projects (like your **agent graph orchestration experiments** and the **SmolAgents hackathon idea**), you are already thinking about the correct solution direction: **Agents need structured state.** Not just prompts. --- ## If you want, I can also show you something powerful A **40–50 line Python loop detector** you can add to any coding agent workflow that will: - detect repeated stack traces - detect repeated patches - halt the agent - ask for a new reasoning path It completely stops these infinite debugging loops. And it fits perfectly with the type of **local-model tooling** you like building.