Softory

Coding agents are strong inside one session and weak across sessions. Nothing keeps the product's intent or the reasons behind a decision once a thread ends, a long thread degrades as it grows, practices only hold while you keep prompting for them, and switching tools or models loses the context. Softory is my attempt at a software factory that fixes that around the agents rather than inside them: it owns what an agent knows when it starts, what it must respect while it works, what gets checked afterwards, and what is kept.

Highlights

• Onboards an existing repository through a conversation: purpose, non-goals and the level of rigor are discussed while an agent inspects the code in the background, read-only, from a snapshot.
• Keeps a reviewed project memory of what code can't show (purpose, direction, decisions, constraints, open questions, vocabulary and a journal), each entry with its source and whether it was stated or inferred. Nothing becomes project knowledge without the developer's approval.
• Turns a discussion into a task with one action: the agent implements in its own Git worktree while its reply streams, and can be steered or interrupted mid-turn.
• Verifies the result itself rather than trusting the agent's report: confirmed project checks run on the changed files, and the receipt is shown before the developer approves the files and the commit message.
• Treats every piece of background work, agent or deterministic command, as observable: its purpose, steps, live output and retained outcome.
• Twenty-nine recorded design decisions so far, each one superseding or refining the last in the open.

Overview

The first user is one rigorous developer: me. The bar for the first usable version is that a normal working day happens without opening a coding agent directly. Open a project and the agent already knows its purpose and decisions; discuss what's wanted; say "do it"; watch the work; see the diff; let Softory run the checks; commit. Decisions get captured along the way, and the next session starts briefed.

It's a local application: a FastAPI modular monolith with SQLite, serving a React interface on localhost. Agents run through the Codex app-server today, with scoped MCP tools for reading the project's context, evidence and recorded work. Softory owns no agent loop of its own; it rents execution from mature harnesses and owns what surrounds each session.

Memory that holds what code cannot

The project memory deliberately doesn't describe the code. What the code shows is evidence, regenerated on demand. What it can't show (why the product exists, which direction it's going, what was decided and why, what must not change) is curated, cited and revisioned. Inspection proposes; only the developer's approval establishes it. Once a project is onboarded, every session starts from a briefing generated from that memory, and finished tasks append to the journal.

Proportionate rigor

The same tool has to serve a throwaway experiment and a serious product without making the experiment pay for ceremony. Each project has a rigor profile (Experiment, Prototype, Product, Production) that decides which gates apply: how much scope a task needs, which checks run, who approves. The current version ships the Prototype path end to end: intent, implementation in a worktree, independent verification, and an approved commit.

Earning autonomy

Softory starts supervised on purpose. Every gate records what the developer was shown and what they decided, so a gate can later be removed per rigor profile once the record shows automatic approval would have been right. Each run also records its harness, model, effort, tokens, time and rework, so comparing configurations on quality, time and cost is part of the tool rather than an afterthought.

Where it stands

The onboarding flow, the Codex session layer, the task workspace and the memory loop are implemented. Next is the acceptance test the whole design aims at: a week of building Softory with Softory, noting every moment of temptation to go back to the agent directly. A second harness (Claude Code), parallel work and triggered work come after that.

Softory has a lineage. An earlier attempt, devloop, explored the same loop around a separate repository of Markdown context that agents read and wrote, and was abandoned. SazUI, a design system I built as an experiment, was where Softory's visual direction was worked out before it moved into the application.