Human-in-the-Loop, Not Human-as-the-Loop
Using Planrock with /goal to stop manually driving the agent loop.
In AI Plan Mode Is Good. Saved Plans Make It Better, I introduced Planrock as a small saved-plan layer for coding agents.
The basic idea is simple:
Plan mode gives structure.
Planrock gives memory.
But once the plan exists as a file, the next question is obvious:
Can the agent execute it without me typing "continue" again and again?
That is where /goal fits.
My manual loop before /goal
In my normal workflow, the agent often already knows the next step.
I even have this rule in AGENTS.md:
When working from a plan, after finishing any item, always state the next
concrete step. Continue doing this until the plan is genuinely complete so
the user does not need to ask "what's next?".
This helps a lot.
After finishing one item, the agent states what it will do next. If it stops, I type:
go
For me, go is just a short alias for:
continue
And the agent continues.
This works, but it also reveals the weakness of the workflow.
If the agent already knows the next step, and my only contribution is typing go, I am not really supervising. I am just keeping the loop alive.
That is not human-in-the-loop.
That is human-as-the-loop.
What /goal changes
/goal is useful because it keeps the agent focused on the objective.
Instead of stopping after each local task, the agent can re-check the objective and continue until the work is genuinely done or blocked.
In my test, /goal reduced a lot of dumb pauses.
The session still stopped, but the stops made sense:
1. Missing auth blocked progress.
2. I manually interrupted it because it was going in the wrong direction.
3. My AGENTS.md policy required manual approval before deployment.
Those are reasonable pauses.
That is the kind of behavior I want.
I do not expect the agent to ignore real blockers. I just do not want it to stop when the next step is already obvious.
Why saved plans pair well with /goal
A short /goal prompt can work for simple tasks.
The human gives up some control over detailed planning in exchange for a more autonomous experience focused on achieving objectives.
For larger tasks, I still want to provide richer context:
goal
constraints
tasks
approval boundaries
test expectations
deployment rules
current state
A saved plan already contains that context.
That is why the combination feels natural:
Planrock stores the plan.
/goal keeps execution moving.
The saved plan gives the agent durable memory.
/goal gives the agent momentum.
Workflow A: /goal first, saved plan during execution
This works when the task is already clear.
/goal Implement X. Create and maintain a saved plan while working.
The agent can create the plan, save it, execute it, update the checklist, run tests, and close the plan when the work is done.
This is best for clear implementation tasks where the agent can mostly plan and execute alone.
For example:
/goal Add GitHub login to this app. Create and maintain a saved plan while working. Run tests, update docs if needed, and mark the plan closed only after the implementation is verified.
This gives the agent both the objective and the instruction to keep a durable plan.
Workflow B: saved plan first, /goal second
This is the workflow I prefer when the task needs discussion first.
The flow is:
1. Use plan mode or normal chat to design the approach.
2. Save the result as a saved plan.
3. Turn the saved plan into a /goal command.
4. Let the agent execute while referencing the plan.
This fits my natural workflow better because I do not always start with a clean objective.
Sometimes I start with messy exploration:
Maybe the bug is here.
Can you inspect this module?
What if we split the deployment step?
Actually, make a plan from what we discussed.
Once that discussion becomes clear enough, I save it as a saved plan.
Then I can use the saved plan as the execution source.
Planrock can help generate the /goal command with the goal command. There is nothing magical about it. It simply scans the plan, pulls the ## Goal section, and constructs a /goal command for you.
planrock goal plans/improve-release-workflow.md
The generated command can look like this:
/goal Follow plans/improve-release-workflow.md and complete the implementation. Keep the plan updated, run lint and tests, open a PR, address review comments, deploy only after approval, verify the shipped result, and mark the plan closed when complete.
This is the bridge I wanted.
The saved plan keeps the context durable. /goal keeps the execution loop running.
The human role changes
I still want human involvement sometimes.
I want to review architectural decisions, approve risky changes, and decide final shipping control when it matters.
But I do not want to be the person typing go forever.
That is the distinction:
Without /goal:
The human keeps the loop alive.
With Planrock plus /goal:
The human defines or reviews the plan.
The agent runs the loop.
The human steps in for judgment.
This is the workflow I prefer:
Plan mode gives structure.
Planrock gives memory.
/goal gives momentum.
Plan mode helps the agent think before coding.
Planrock saves that thinking as repo-local memory.
/goal uses that memory to keep execution moving.
For me, this is a practical bridge from micromanaging agents toward more autonomous goal-driven workflows, without giving up review, control, or shipping boundaries.
I still want human-in-the-loop when it really matters.
I just do not want human-as-the-loop forever.