loops, Matt Palmer’s Engineering Outer-Loop Bot
Matt Palmer built loops to sit above coding agents, keep one engineering goal moving, and stop only when the result has testable proof.
The pain point loops solves
Coding agents are good at writing changes and poor at owning the full engineering cycle. Someone still has to gather context, define a testable goal, launch the work, review the proof, and decide whether to merge. When that outer loop stays with the human, agents create speed without creating completion.
Matt Palmer’s loops bot is designed for that missing layer. It sits above coding agents as a generalized engineering outer loop. You name the repository. It gathers context, writes goal-style prompts with testable proof, launches the work, reviews the result, and keeps the gather → prompt → launch → review → merge cycle moving.
About Matt Palmer
Matt Palmer is an engineer working with Grok Bots at SpaceXAI. He has been public about how he uses bots for real engineering work, including a high-engagement rundown of templates worth copying and a direct share of the loops profile he uses day to day.
That context matters because loops is not a generic “write some code” prompt. It is an operating pattern for keeping agents pointed at one objective until the proof is strong enough for review.
How loops works
The public profile describes a generalized engineering outer loop that uses pstack as a reference for how, why, and unslop. It writes /goal-style prompts with testable proof, then runs the cycle: gather, prompt, launch, review, and merge.
The hard boundary is explicit: you name the repo; it never guesses. That keeps the bot from wandering into the wrong codebase or inventing project context. The useful output is progress against a named objective plus evidence the change did what it claimed.
- Name the repository up front so the bot never guesses the workspace.
- Gather the surrounding context before writing the goal prompt.
- Write a /goal-style prompt with testable proof requirements.
- Launch coding agents against that goal instead of an open-ended chat.
- Review the proof, then merge only when the evidence holds.
What is worth copying
The transferable idea is the outer loop itself. A coding agent without a proof contract produces diffs. A bot with gather, goal, launch, review, and merge produces finished engineering work that a human can audit.
Start with one repository and one class of task that already has a clear definition of done. Keep merge authority with the human until the review package is consistently complete. Expand only after the bot reliably returns proof instead of vibes.