Loop Engineering is Brightstack’s name for how its agents work. You set the goal; the agents iterate until the goal is met. Instead of prompting every step, you describe what done looks like, and the loop does the steering. The one thing to understand is that the loop terminates on the conditions you state, so what you write in the issue decides where it stops. The right rail after a run: the goal marked Achieved, every todo checked off, and the team that ran it

​
The loop

  1. Define the goal. What done looks like, in terms that can be checked.
  2. Gather the context needed to execute: the repository, linked issues, documents, connected sources, and past work.
  3. Take action. Write the code, draft the document, create the records.
  4. Verify the result against the goal and its constraints.
  5. Repeat until every condition is met.
The right rail reports the goal and task progress while the loop runs. Approvals pause it when a step needs you.

​
Why this changes how you write issues

An issue with no definition of done gives the loop nothing to verify against, so it stops when the agent judges itself done. An issue that defines done lets the loop run itself to that bar. Write the definition of done into the issue:
  • The outcome.
  • The constraints.
  • How to check it.
Issues covers the properties; Meet the agents shows who executes inside the loop.

​
Good to know

  • The right rail reports the goal and task progress while the loop runs.
  • Approvals pause the loop when a step needs you.
  • Without a stated definition of done, the loop stops when the agent judges itself done.
  • The loop walkthrough takes the loop step by step: ask, plan, agent. One-shot runs the whole loop from a single prompt.

​
Next step

See the loop run behind five named gates, with an independent review at the end of Build, in Forge.