Most feedback tools let you "configure rules": fill in conditions, pick actions, click save. It works, but there's a ceiling — rules are static, the business keeps changing, and a process you configured soon falls behind. One of Loopback's differentiating pivots is upgrading "configuration" into "evolution": that's the Coding Loop (also called Builder Mode).

From "configuring rules" to "describing a goal"

When you create a workflow, you don't have to click through a pile of condition dropdowns. You describe the goal in plain language — say, "refund-related negative → assign to the payments team and draft an apology" — and click "Generate draft"; the draft appears in the AI chat on the right. From there you refine it in the conversation:

  • Click "Edit" to change it in natural language, for example "count ratings below 3 stars too."
  • Click "Next" to enter the pre-launch review.
  • Once it passes, click "Go live" to activate it.

You and the AI are writing a piece of handling logic together, not filling out a form. That's where the name "Coding Loop" comes from — iterating on a process the way you'd iterate on code, only in natural language.

Two gates before going live

A process runs actions automatically, so there's a review before it goes live:

  1. Dependency check: is a channel the process needs to notify (Feishu, say) not connected yet? It prompts you to connect it first, drop that step, or switch to an already-connected channel.
  2. Impact replay: the actions that will run automatically (assign / escalate / close / change priority) require your explicit authorization, and you get a replay over the last 30 days of history — if this process had already existed, how many items it would have matched and how many actions it would have triggered. So you can judge whether the scope is reasonable before going live.

Hard safety boundaries

"Evolving" doesn't mean "automation left unchecked." The system has a few constraints that can never be crossed:

  • No fully automated outbound replies — a drafted reply must be confirmed by a human before sending.
  • No automatically closing a P0.
  • Keep each process to 1–4 focused rules; cramming all your logic into one process is discouraged.

A live process can be paused / resumed at any time; continuing to edit creates a new version, the old version is archived automatically, and only one version of a given process is ever active at a time.

Why traditional architectures can't fill this gap

Before coding agents existed, making a process iterate on itself meant either an engineering team writing scripts (not reusable, and you have to staff for it) or it simply couldn't be done at all. Traditional ticketing SaaS is architected around "humans configuring rules," and it can't add the layer where "AI writes it for you and keeps learning." The Coding Loop productizes "the flexibility of building your own scripts": flexible, yet without staffing an engineering team to maintain it.

Tiers differ in Builder loop concurrency (Pro allows 1 concurrent run, Max is unlimited). The fastest way to experience it is to start a free trial for a 7-day Max trial — the trial gives you the full Builder loop. You can also start by reading Workflow Templates to learn the path from a template.