Overview

Looping Louie Architecture

Looping Louie coordinates iterative LLM-assisted software development. It combines durable workflow decisions with local repository execution.

The platform is independent from any programming language, framework, or LLM provider.

Platform model

Users define the work to perform and the context in which it runs. A Project connects that durable platform configuration to one or more runtime-owned local checkouts. Activities define individual units of work; Pipelines arrange those Activities into an executable workflow. Personas, Skills, models, and Linked Services provide reusable instructions and model access where a workflow needs them.

Starting a Pipeline creates a persisted run. The API resolves the configuration needed for that run and freezes it in immutable snapshots. This lets later edits to a Pipeline, Activity, or instruction resource affect future work without changing work already in progress. Executions are described in the platform introduction.

Components and responsibilities

The API is the durable control plane. It stores platform resources and run state, selects workflow actions, and records their outcomes. It owns scheduling, model and Harness selection, review decisions, and commit authorization.

The runtime is the local execution plane. It maps a Project to a configured Git checkout, claims API-assigned work that it can execute, runs the requested local action, and returns checkpoint outcomes. It owns machine-local executables, credentials, repository access, and Git policy.

The CLI and dashboard are user-facing API clients. They create and manage resources, start work, and present execution history. They do not own workflow state or execute repository changes themselves.

flowchart LR
U[User] --> D[Dashboard]
U --> C[CLI]
D --> A[API control plane]
C --> A
A --> R[Runtime worker]
R --> G[Configured Git checkout]
R -->|Outcomes and observations| A
A -->|State and history| D
A -->|State and history| C

The API never directly mutates a target repository. The runtime does not choose models, reviewers, or scheduling outcomes, and it never accepts a checkout path from an API response.

How components interact

Configure work

Users work through the dashboard or CLI to create Projects, reusable instructions, provider connections, Activities, and Pipelines. Both clients use the public API as the single source of truth. The API validates and persists these resources, making them available to later runs and to the interfaces that inspect them.

Start and execute work

A client starts a Pipeline run through the API. The API selects the next eligible Activity and waits for a healthy runtime Worker with a compatible Harness. A worker polls for compatible work, claims a run, and executes the API-directed checkpoint in its configured checkout. It reports the result to the API, which decides the next transition or makes the run terminal.

The runtime executes the selected Harness. Depending on the frozen Activity configuration, that Harness applies an API-approved operation plan or runs a local CLI turn. It reports repository evidence and local outcomes; the API retains authority over review, retry, scheduling, and whether a commit may proceed.

Record and inspect results

The API persists Activity and Pipeline transitions, execution observations, and authorized commit outcomes. The dashboard and CLI retrieve that durable history to show progress and results. This keeps operational visibility separate from the local checkout where the work happened.