Docs

Where it came from

Last Light began as an experiment: could the patterns that let an agent system rebuild a codebase overnight be turned into something that keeps a team's GitHub repositories healthy, running on a server rather than on one developer's laptop? This page covers where those patterns came from and the principles that survived building it.

Where this came from

The starting point was the claw-code article by Sigrid Jin, which describes how the oh-my-codex (OmX) system rebuilt an entire codebase while its developer slept. The line that stuck:

“The code is a byproduct. The thing worth studying is the system that produced it.”

OmX combines oh-my-codex for workflow orchestration, clawhip for event routing, and oh-my-openagent for multi-agent coordination. Last Light kept three of its ideas — role-based agents, closed development loops and GitHub as the coordination layer — and rebuilt them as a TypeScript harness that runs as a server, reacts to webhooks, Slack and cron, and describes every behaviour as a YAML workflow.

The execution model came from Sandcastle by Matt Pocock, which showed that a coding-agent CLI can be driven headlessly inside an isolated sandbox, with the harness owning orchestration and the agent owning the work. In Last Light every agent phase is a fresh agentic-pi session in its own sandbox, with a GitHub token scoped to what that workflow is allowed to do.

The principles

1. Separate the roles, and separate the sessions

A build moves through distinct phases — guardrails, architect, executor, reviewer, PR — and each one is a new agent session with its own prompt. Nothing carries over in memory: phases hand off through files on the branch (the plan, the executor's summary, the reviewer's verdict), so what one phase knows is exactly what the previous one wrote down. The role boundaries themselves live in the prompts; what is enforced by the harness is the token each workflow gets (its permission profile) and, where a workflow declares one, a per-phase command policy.

2. No agent verifies its own work

The agent that writes the code never reviews it. The reviewer is a separate session that sees the diff, the plan and the executor's claims about the change — not the executor's reasoning — and returns APPROVED or REQUEST_CHANGES. Requested changes go to a fix session, then back to review, for at most two cycles. It is the same reason people do code review, made structural.

3. GitHub is the coordination layer

Work is tracked where the team already looks. A build always targets a GitHub issue, even when it was asked for from Slack; progress, approvals and results land on that issue and its pull request. State lives there too: the autonomous pipeline is a set of labels, and a pull request's state is re-derived from GitHub on every dispatch rather than kept in a table of its own.

4. Evidence over assertion

“Should work” is not a result. Plans and reviews cite file:line. The build's guardrails gate is decided by the test command's exit code, not by an agent saying the tests passed. The verify workflow reports CONFIRMED or REFUTED with captured output, and the weekly digest's numbers are computed, not written by a model.

5. Deterministic where it can be

A model is used where judgement is needed, and nowhere else. The router matches events and explicit commands in code, and only asks a classifier what free text means — a comment, a Slack message, whether a new issue is a question. Gates, budgets and dedup checks are code; cron sweeps only find work, and the same dispatch gate decides whether it runs. That is what makes the system predictable enough to leave running unattended — and measurable, with evals built from your own repositories.

Where to go next