groktopus/loop-designer/loop-designer

From Prompter to Loop Designer

A loop designer builds a system that prompts itself -- runs on a timer, checks its own work against a goal, spawns helpers when needed, and writes down what it learned so the next run starts smarter. This skill distills Alex (@de1lymoon)'s 10-step roadmap into concrete Hermes Agent invocations.

This is NOT about better prompting. It does NOT cover model selection, fine-tuning, or prompt engineering. The model stays the same throughout -- what improves is the Hermes infrastructure wrapped around it.

When to Use

• You are building an agent that should run unattended on a schedule
• You have a working manual workflow and want to automate it
• You want the system to remember past runs and improve over time
• You need to build a fail-safe autonomous loop
• You are debugging why your automated agent stops improving after initial gains

When Not to Use

• The task takes under 5 minutes and runs less than weekly. The setup cost of a dedicated profile, goal_judge wiring, state log, and cron job exceeds the manual effort for months or years. A simple cron job or calendar reminder is a better fit.
• The task requires irreversible production writes without a human gate. Deployments, database migrations, and user-facing content changes must have a human approval step. The loop can prepare and verify, but should not execute alone.
• The task's environment changes faster than the loop's value compounds. If the target (dashboard, API, website) changes layout or contract weekly, the loop spends more time debugging failures than the manual task would take. The compounding benefit of memory and skills only helps when the environment is stable enough for lessons to accumulate.
• You can't define a clear "done" condition. Without a goal_judge verdict or measurable acceptance criteria, the loop has no way to know when to stop. Loops without a stop condition drift into token-wasting oscillation.
• You're building it to learn loop design, not to solve a problem. That's valid — build a throwaway loop on a synthetic task first. The Verification section spells out what graduating looks like.

Prerequisites

• Hermes Agent with /goal and /subgoal commands
• goal_judge auxiliary model configured in ~/.hermes/config.yaml -- this IS the independent grader the article calls for
• Kanban dispatcher (runs on 60s tick) for durable task promotion, dependency handling, worker launch, and crash recovery
• cronjob tool for scheduling recurring loops
• skill_manage tool for distilling learned patterns into skills
• memory tool for cross-session persistence
• A dedicated Hermes profile for running the loop (see Step 2)

How to Run

Work through the tiers sequentially. Each step in the Procedure translates one of the article's 10 moves into a concrete Hermes configuration or tool invocation. The canonical output is a profile-bound cron job with goal_judge as the grader and a skill-update lifecycle.

Syntax key: This skill uses three notations for Hermes operations. Know which is which — trying to run one as the other will fail.

Quick Reference

Procedure

Tier 1 -- See the loop

1. See the agent as a loop.

Hermes already has loop infrastructure. /goal sets an objective. goal_judge evaluates completion after every turn. Together they form the core loop: work until the judge says done.

A /goal runs as a persistent loop with automatic pass/fail checks. This IS the article's "while not goal_met" -- no extra infrastructure needed.

/goal All tests pass and lint is clean.

Add subgoals for multi-condition loops with /subgoal.

2. Lock down the harness first -- as a profile.

The harness is the environment the agent boots into. In Hermes, that is a profile: a dedicated directory at ~/.hermes/profiles/<name>/ with:

Build one before the loop touches any real work. Create it with:

hermes profile create <name>

Replace <name> with a short identifier for the loop's purpose (e.g., nightly-build, scraper-loop, code-review). This creates the profile directory at ~/.hermes/profiles/<name>/. Profile metadata such as the description may live in profile.yaml; runtime configuration lives in the profile's config.yaml.

Then populate it with the loop's specific configuration:

profile.yaml          # profile metadata/description for routing
config.yaml           # model, toolsets, terminal cwd, memory, and auxiliary config
.env                  # credentials scoped to this loop's tasks
skills/               # only the skills the loop needs
SOUL.md               # identity/persona for the loop's run context

Harden the harness by disabling tools the loop should never use. In the profile's config.yaml:

disabled_toolsets:
  - homeassistant
  - spotify
  - image_gen

The test for a good harness: run one manual cycle under the profile and verify every tool call the loop will need works on the first try.

3. Understand what self-improving actually means.

The model's weights do not change between runs. In Hermes, what compounds is:

• Append-only state log: records run history, attempts, outcomes, and short lessons without clobbering concurrent runs.
• Memory provider / `memory` tool: persists stable cross-session facts that should be true beyond the current run.
• Skills: versioned via skill_manage, patched when a reusable procedure or repeated failure mode is discovered. Every run starts with the hardened version.

The honest framing: you are not waiting for the model to get smarter. You are building a Hermes environment that gets smarter, run over run, with the same model.

Tier 2 -- Build the loop

4. Set a goal with an independent grader.

The loop needs a stop condition the agent does not control. Hermes provides this natively with the goal_judge auxiliary model -- a separate model (configured in config.yaml under auxiliary.goal_judge) that:

• Runs in its own context window
• Sees the cumulative conversation and the original goal
• Evaluates whether the goal is met or not
• Has no stake in the work produced

Configure it:

auxiliary:
  goal_judge:
    provider: openrouter
    model: qwen/qwen3-8b

Then invoke:

/goal All tests pass and lint is clean.
Triage failures, draft fixes, repeat until the goal holds.

For production loops, prefer a completion contract so the judge has concrete evidence to check. You can draft one:

/goal draft Fix every failing auth test without changing the public login response shape

Or write the contract inline:

/goal Fix failing auth tests
verify: scripts/run_tests.sh tests/auth passes
constraints: do not change the public API response shape
boundaries: only services/auth and tests/auth
stop when: a database migration is required

The goal_judge fires after every turn. When it says done, the loop stops. This IS the article's "independent grader" -- no separate subagent needed for single-task loops.

Physical circuit breaker: repeat cap. goal_judge provides the logical stop. For unattended loops, add a physical one: the repeat parameter on the cronjob that seeds the loop. This limits how many times the loop fires regardless of goal_judge's verdict -- the hard stop that prevents a runaway loop when the grader itself is wrong, broken, or unreachable.

cronjob(repeat=10)  # hard stop after 10 iterations no matter what goal_judge says

The article's mistake is "no stop condition." goal_judge is one stop. repeat is the other. Both are needed because goal_judge is a model and can be wrong. The repeat cap is the physical guarantee.

Kanban as the durable work queue. A monolithic goal works for simple pass/fail loops. For complex goals that decompose into parallel work items, seed a kanban board with explicit cards and per-card acceptance criteria. A human, orchestrator profile, or cron prompt creates the scoped cards; the kanban dispatcher (60s tick) promotes ready work, reclaims crashed workers, respects dependencies, and launches worker profiles. The dispatcher handles fan-out by card dependency -- cards that are independent run in parallel, cards that depend on each other wait for their parent. This IS the article's "system that operates itself" at the task level, not just the loop level.

Choosing between patterns. The skill describes four composition mechanisms. Use this table to pick the right one:

Don't reach for kanban for a single-task loop — /goal handles it natively. Don't use delegate_task for fan-out that doesn't need verification — kanban is lighter and the dispatcher handles scheduling autonomously.

5. Split the maker from the checker.

For high-stakes loops where the goal_judge's binary pass/fail is too coarse, add a verifier subagent via delegate_task. Give it its own profile with limited tools:

delegate_task(
    goal="Verify the output against the goal. You did not produce this work. Run the tests yourself. Report pass or fail with concrete reasons.",
    context="Goal: {{goal}}. Artifact: {{path}}",
    toolsets=["file", "terminal"]
)

The key properties of a proper checker:

• Its own context window (delegate_task guarantees this)
• No stake in the maker's choices
• Sees only the artifact and the standard
• Reports pass or fail with concrete reasons

For simple loops, goal_judge is sufficient. For loops producing artifacts (code, documents, configs), add the verifier.

6. Put it on a timer.

A goal-driven run still waits for you to type /goal. The next move is cadence. Create the cron job from the dedicated profile context so the loop runs with that profile's config, credentials, and tool restrictions. From a shell, use the profile flag or the profile alias: