Skip to content
← Missions

ATLAS — AI-orchestrated delivery

A ticket in, a reviewed merge request out. Two human approvals in the middle, and a permission layer that will not let an agent merge its own work.

LutinRougeEarly-years childcare — SaaSAI Applications & Agents2025
HUMAN · 4 TOUCHPOINTSATLAS AGENTS · 4 STAGESWrites the ticketDescription, estimate, target versionReads the ticket & codebaseIncomplete input halts the run andsays exactly what is missingWrites the planScoped to the acceptance criteriaApproves the planDiscuss, push back, or approve.Nothing is written before thisBuilds & testsTest-first, then a real browser passbackendfrontend & i18nsecuritytestsreviewerVerifies the resultA written test plan — check it now,or hand off as a draftOpens the merge requestEvidence, findings, checklistReviews & mergesATLAS never merges, and cannotloop limits escalate
A human merges. Always. ATLAS never merges, never pushes to a protected branch, never force-pushes and never deletes a branch — hard denials in a permission layer, not instructions in a prompt, and no agent can rewrite its own permissions to finish a task.

The problem

LutinRouge is a multi-tenant platform in production across dozens of settings, built and maintained by a small team. The constraint is not ideas; it is throughput at a standard that can be defended: every change reaching families’ contracts, invoices and children’s records.

The obvious answer, an AI coding assistant in the editor, solves the wrong half. Generating code is not the hard part. Generating code you can trust enough to merge is.

What we did

ATLAS, an orchestrator rather than an assistant: specialised agents driven through a fixed pipeline with mandatory gates, running against our own repositories under our own conventions.

It refuses to start on an incomplete ticket: a missing description, estimate or target version halts the run and says what to fill in, because bad input is the cheapest defect to catch. It reads the codebase and writes a plan scoped to the acceptance criteria, then stops and asks before writing anything. Specialists then work in sequence: backend, frontend and internationalisation, security, tests, and a final reviewer, each handing forward a structured status rather than a wall of text. For web work it brings the stack up on the branch and exercises the change in a real browser before a person is asked to look.

A human merges. Always. ATLAS never merges, never pushes to a protected branch, never force-pushes, never deletes a branch, enforced as hard denials in a permission layer, not as instructions in a prompt. No agent can rewrite its own permissions to finish a task. Deployment stays with existing CI/CD; ATLAS delivers the reviewed change that triggers it.

The disciplines that make the output reviewable rather than merely plausible:
Evidence over assertion A completion claim carries its artefact: test output, the diff, a measured number. “Should work now” is not a state.
Test-first on real criteria A test that fails for the stated reason exists before the fix; the reviewer confirms red, then green.
Security as a gate A critical finding halts the pipeline; a high finding blocks the merge request pending an explicit decision.
No placeholders “TBD”, “handle edge cases”, “add appropriate validation” are rejected outputs, not acceptable drafts.
Scope control Work outside the ticket is surfaced and asked about, never silently absorbed.
Loop limits Repeated identical output and capped fix cycles escalate to a person instead of spinning.

Where it runs

On the engineer’s machine, against clones of the repositories. Reports, audits and analysis are written to disk and stay there. Nothing is uploaded to a third-party dashboard. Credentials are referenced by name from a local environment file, never embedded in prompts, commits or reports.

Each ticket gets an isolated working tree, so several can run against one repository at once. The system records what it learns about each repository: conventions, architectural decisions, API contracts, data models, design tokens, so the tenth ticket starts better informed than the first.

Why it matters beyond LutinRouge

This is the substance behind the AI-augmented delivery claim. It is not a pilot: it runs daily across 20 repositories, 5 language stacks and 10 tracker projects: PHP/Symfony, Python, Dart/Flutter, TypeScript/Node and server-rendered front ends, of which LutinRouge is one tenant among several.

Adding a language is a self-contained knowledge pack plus a detection rule: no change to any agent, no change to the pipeline. That is a deliberate architectural choice, so the cost of a new stack is bounded and known rather than discovered.

The same orchestration also runs OWASP Top 10 security audits with adversarial verification of every finding, codebase health audits, merge-request review as actionable checklists, and a two-phase release process producing release notes, tags and back-merge requests, while still never merging.

Honest limits

Stated here because they are load-bearing, not caveats.

It does not deploy. It delivers a reviewed merge request. It does not remove the reviewer: a human reads and merges every change, and the system’s job is to make that review fast and honest, not to eliminate it. It is strongest on well-scoped tickets and halts on vague ones by design rather than guessing. Exploratory debugging stays human-led: open-ended “why is production behaving strangely” is a person’s work, with the system assisting.

It is a force multiplier for an engineering team, not a replacement for one.