loop engineering

better). The agent cannot touch it. Three sharp design moves beyond "immutable": (1) TIME_BUDGET = 300 seconds is hardcoded — every experiment is the same wall-clock regardless of what the agent changes (bigger model → fewer steps, same compute cost). That's how architecture changes stay comparable without normalization; (2) the validation shard is pinned (VAL_SHARD = MAX_SHARD = 6542) — the eval set doesn't just stay frozen in code, it stays frozen in data; (3) evaluate_bpb() is vocab-size-independent (bits per byte, not bits per token), so changing the tokenizer doesn't shift the metric.

3. "NEVER STOP" autonomy contract in the spec. program.md says explicitly: "do NOT pause to ask the human if you should continue. The loop runs until the human interrupts you, period." Most agent prompts hedge this with safety language. The autoresearch pattern is that the harness keeps the agent from asking, not the agent's own judgment. Translation for TARS: when designing a recurring agent loop, the no-pause rule belongs in program.md-equivalent (CLAUDE.md / AGENTS.md / cron prompt) — not as runtime safety rails but as the agent's explicit mandate.

1. Verifier — a test, metric, schema check, or LLM-as-judge that grades each attempt. Without one, the agent just agrees with itself on repeat and the loop produces confident garbage. 2. State — a log of what was tried, what failed, what remains. Lets the next run resume instead of restart; this is what stops the loop from re-discovering the same dead ends every session. 3. Stop condition — a budget cap (token spend, attempt count, wall-clock) that prevents runaway cost. Loops that lack one will always spend more than they save.