For over a year now most people have used LLMs the same way. Write a prompt, send it, get a response. If it is not good enough tweak the prompt and try again. If it works copy the result and move on. This works fine for one-shot tasks like Q&A, writing help, or generating code snippets. It falls apart the moment a task requires multiple steps, mid-course corrections based on intermediate results, or a review-and-revise cycle. No matter how long or carefully crafted a prompt is, it is still a static instruction. The model cannot catch itself making a mistake mid-execution and backtrack. A human has to sit there watching, waiting for something to go wrong so they can manually interrupt and start over.
If you look at what actually ships in products today, Claude Code, OpenAI Codex, Cursor Agent, Manus, OpenHands, none of them run on single prompt calls. They all run loops. The model looks at the current state, takes an action, observes the result, decides what to do next, and keeps going until it is done or hits a stopping condition. A prompt is an RPC, fire and wait. An agent is an event loop, it keeps running, keeps responding, keeps adjusting based on feedback. This is not some speculative future architecture, it is already how the serious agent products work under the hood. Yet most teams building with LLMs are still manually driving the loop themselves, copy-pasting between chat windows, reading outputs, writing feedback, re-running prompts, acting as the glue code that should be handled by the system.
The limitations of pure prompt engineering show up fast in production. Take a documentation task: give a model source material and a prompt, the first draft usually has structural or tonal problems. A human points out what is wrong, the model revises, maybe still issues, another round. Three or four iterations is normal. If a human is doing all of this manually, reading full drafts and writing feedback each time, it is slow and the feedback quality is inconsistent. For multi-step tasks like GUI automation across multiple applications, one wrong click or a page load failure means the whole run is wasted. A single prompt call has no way to detect the error and recover.
A loop changes this. Execute, inspect result, feed back signal, continue or correct, repeat until the output passes acceptance criteria or hits an iteration cap. Sounds simple enough. Getting it to work well is another story. Execution history cannot grow forever, context windows are finite, so you need selective retention and rolling summaries, but summaries lose detail and getting that tradeoff right is a constant tuning problem. Feedback signals are harder than they look. "This is bad" carries zero information for a model. Feedback needs to be specific about what is wrong and what would make it right. For automated review you need a reliable evaluator, and using a second LLM as judge introduces its own biases and instabilities, while programmatic assertions cannot cover semantic quality. Termination conditions are another trap. Set them too loose and the model burns tokens looping in the wrong direction. Set them too tight and it gets cut off before converging. Then there is feedback retention. If every round of review comments just disappears into a thread you are wasting data. Distilling that feedback into reusable preference signals that get injected into future runs means the model starts each new task with accumulated knowledge instead of a blank slate. Doing this well is difficult because natural language feedback is noisy, some comments are subjective taste, some are factual corrections, some are formatting requirements, and mixing those together kills retrieval precision.
When we built Octo we made the loop the core primitive rather than bolting task management on top of a chat interface. The unit of work is called a Loop, created naturally from conversation with no forms to fill out. Mention an agent with a description of what needs doing and a Loop spins up. The agent starts executing, deliverables attach directly to the Loop, the requester reviews and either accepts or sends it back with comments. Rejection comments get recorded as Preference entries, and the agent automatically pulls those preferences as context on its next iteration for similar work. The whole execute-review-revise cycle is managed by the platform, no manual copy-pasting or new conversations required.
The Preference system is where this gets interesting. Rejection comments do not just sit in a comment thread. The system distills them into reusable experience entries attached to the relevant agent. On the next run the agent retrieves matching preferences during inference. A documentation agent that repeatedly gets flagged for opening paragraphs with summary sentences will start avoiding that pattern after a few rounds without anyone having to say it again. Team conventions survive personnel changes and model upgrades because the preference data is stored independently of which model is running.
For multi-agent work the loop model scales up. A single loop handles one agent on one task well enough, but real work often involves multiple agents with different specialties, some writing code, some reviewing, some running tests. Octo ships with six orchestration modes built on top of the loop primitive. Solo runs a single agent on a simple task. Roundtable puts multiple agents in a shared context for discussion and convergence. Critic splits execution and review into separate loops with identity isolation so reviewers do not know who produced the work. Pipeline chains loops sequentially with stage handoffs. Split breaks work into parallel loops that merge at the end. Swarm launches multiple parallel loops on the same problem and picks the strongest result. None of this works in a plain chat interface because chat assumes everyone sees everything, while real collaboration requires controlling information flow. A reviewer should not know who wrote the code. Parallel workers should not contaminate each other. On the infrastructure side, list and kanban views for managing loops are live, with subtask trees, full iteration history, review state transitions, and gantt-style dependency visualization. Project grouping clusters related loops with permanent members and agents. Automation pipelines support both scheduled and event-triggered flows for recurring work like daily data summaries. Cross-loop search is available. Agent management covering prompt configuration, skill mounting, runtime binding, and usage stats is in V1 development. Runtime registration and health checks are also coming this month, initially supporting self-hosted CLI daemons that the platform registers, monitors, and dispatches tasks to. Workspace team composition lets you pull people and agents from a directory into shared workspaces so loops inherit permanent resources. A skill marketplace and A2A routing are planned for after the core execution loop stabilizes.
Web and desktop provide the full workbench, mobile handles notifications and quick approvals, a browser extension brings Octo alongside any webpage with automatic context injection, the CLI is the native agent interface for sending and receiving work, and IM integration works the way teams already talk, mention an agent in chat and a loop starts.
A prompt is a function call. A loop is the unit an agent actually works in.