Teaching Daisy Goal-Based Loops — Without Burning Tokens
By DigiEntropy Engineering · 2026-07-12 · 8 min read
We read Claude's agent-loops playbook, gave Daisy a deterministic goal check on its selection engines, and measured it: dead-end empty results became engine-backed answers, for zero extra tokens on healthy turns.
About this post — Authored by an AI assistant using DigiEntropy's polynomial corpus, the universal compressor predictor, and the project's chart-generation tooling. Charts are produced by Python scripts that read the same database the live site queries; tables and formulas are pulled from the same engineering modules. Findings reflect the project's current dataset and methodology — send corrections or deeper questions to admin@digientropy.com. Ask an engineering tool for something impossible and the worst answer is silence: an empty table, no explanation, no path forward. Until this week, that is what Daisy — the AI co-pilot inside DigiEntropy — could produce when a selection came back with zero candidates. Claude's engineering team recently published Getting started with loops, a playbook for agents that repeat cycles of work until a stop condition is met. We read it the way we read every good agent-engineering post — harvesting ideas, not copying them — and asked one question: which of its loop types does Daisy actually lack? Then we built the missing one, and because we never tune Daisy by feel, we measured it with our 49-scenario eval before and after, on both models we run. The short version: the missing type was the goal-based loop. One deterministic goal check on Daisy's selection engines — code, not a second LLM — took the two impossible-request test scenarios from fabricated ceilings and dead-ends to honest, engine-backed engineering answers. On the weak default model they went from 0.60 and 0.40 (with a fabrication flag) to a perfect 1.00 on both after the full fix; the strong model went from an honest-but-incomplete 0.80 pair to 1.00 on both. The loop fired on exactly 4 of 98 eval turns and cost nothing anywhere else. Four loop types, one gap The post's core idea is worth restating plainly: an agent is a loop that repeats work until a stop condition is met — and the stop condition, not the model's optimism, should decide when to quit. It names four loop shapes. Daisy already runs a solid turn-based loop: one user message starts a tool-calling loop (capped at five rounds) in which the model either calls a real engine — cold-room loads, compressor selection, refrigerant ranking, envelope checks — or returns its final answer cards. Time-based and proactive loops are development-workflow tools (watch a PR, triage a queue on a schedule); an in-app co-pilot answering a waiting human has nothing to poll. That leaves goal-based loops: iterate until a defined success criterion holds, or a hard cap is hit. The post's strongest claim is about exactly…