Three loops of LoopEngine

Why LoopEngine is about the loop? Because it is the core concept about how the agent run. The loop idea has three layers:

1. ReAct Loop:

This is the loop at the center of everything: the model reasons about what to do next, decides to call a tool, the tool runs, and the result goes back into the model's context for the next round — reason, act, observe, repeat, until the model has a real answer instead of a guess. LoopEngine doesn't treat this as one hardcoded flow either. A tool is just a tool, whether it's a hand-written function, an HTTP call generated from the Admin UI, an external SaaS action routed through a gateway like Composio, a subagent, or a vector search over your own documents (RAG) — the ReAct loop doesn't know or care which. It calls a tool, gets a result, and keeps going. Underneath, ToolLane schedules a batch of calls so the safe ones run in parallel instead of one at a time, and a budget tracker watches the conversation's size so a long-running loop compacts its own older context instead of silently blowing past the model's window. The agent just keeps reasoning and acting — the plumbing that keeps that sustainable is invisible to it.

2. human-in-the-loop:

Not every action a tool-calling loop wants to take should just happen. LoopEngine's permission layer (ActAuth) lets you declare, per tool and per scope, whether a call is allowed automatically, needs a human's yes first, or is denied outright — refunding an order in staging might be auto-allowed, the same call in production might need a person to click approve. That human step isn't one-size-fits-all either: a live approver (a terminal, a chat widget, a Slack message) works when someone's watching right now and the answer comes back in seconds; a durable approver (a webhook, a database row, a queue entry) is for when the real answer takes minutes or days, without holding a process open the whole time waiting. The agent itself can also pause and ask directly — a `system_ask_user` call — when the request is genuinely ambiguous rather than something it should just guess at. Every one of these decisions, automatic or human, lands in an append-only audit log, so "why did the agent do that" always has a real answer.

3. Self improvement loop:

The third loop isn't the model retraining itself — it's how quickly the system around it closes a gap once one shows up. Every "ask" decision, every question the agent had to stop and ask a human, every task it couldn't complete because it was missing a tool, is a signal pointing at exactly what the agent needs next. LoopEngine is built so that closing that gap doesn't mean a redeploy: add a skill (a `SKILL.md` the agent can discover and use immediately), generate a new HTTP tool from the Admin UI, adjust a permission rule, or pull in a vetted skill from the skillgarden catalog — all of it applies to the already-running agent, live, with no restart. The loop that matters here is short: the agent hits a wall, an operator sees exactly where and why (because loop two already surfaced it), and the fix ships in minutes instead of a release cycle. Over time, that's what makes the agent actually improve — not the weights changing, but the gap between "what it can do" and "what it's asked to do" closing faster than it reopens.

With these three loops built in — reasoning and acting, a human in the loop when it matters, and a system that closes its own gaps fast — LoopEngine can back an agent that handles most of the real-world headaches a business workflow throws at it, not just the ones that fit a demo.