Fixing Long-Running AI Agent Reliability with Goal Buddy
AI LABSgo watch the original →
the gist
Goal Buddy replaces subjective, chat-based agent completion with a state-driven, multi-agent architecture that uses verifiable 'oracles' to ensure tasks are actually finished.
The Problem with Native Goal Commands
Native agent goal commands, such as those found in Claude Code, often fail on complex, long-running tasks because they rely exclusively on chat context as the source of truth. This leads to context bloat, memory compaction issues, and a lack of structured task breakdown. Because these agents lack a persistent local state, they often lose track of progress or fail to recognize when a task is truly complete, relying instead on subjective model evaluations that are prone to hallucination.
The Goal Buddy Architecture
Goal Buddy introduces a three-agent system coordinated by a project manager (PM) thread to enforce state-driven execution. The system forces the agent to read and update a local state.yaml file rather than relying on chat history. The architecture consists of three distinct roles:
- The Judge: A read-only agent with high reasoning effort that skeptically analyzes risky scope and contradictory information. It returns a JSON structure containing approved or rejected decisions.
- The Scout: A read-only agent with low reasoning effort that maps active tasks and creates compact evidence receipts.
- The Worker: The only agent with edit access, responsible for executing one task at a time.
Verifiable Completion via Oracles
Goal Buddy requires the definition of an 'oracle'—an observable, verifiable signal that determines if a task is complete. This oracle can be a test suite, a browser walkthrough, or a specific artifact. The workflow begins with a goal prep command, which forces the agent to resolve ambiguities by asking the user clarifying questions before generating a goal.md file and a state.yaml tracking file. The agent breaks the work into 'slices'—individually verifiable, safe units of work—and tracks progress via a live dashboard. This approach allows the agent to handle non-programmatic tasks, such as UI design, by defining completion criteria like 'dev server is running and browser walkthrough confirms all sections work.'