Turn what you know, what you have, and what "good" looks like into a tested, portable agent package — through a pipeline with a human at every consequential gate.
Method Factory is a prompt+code system for building agent packages: personas, skills, templates, and the evidence trail that connects them. You describe the outcome, share your source material, answer a few clarifying questions, and agree on an objective. Then — and only then — Method Factory generates, reviews, and trials the package, with your sign-off required at the points that matter.
It is the more rigorous successor to Process Engine: the same conversational, human-gated pipeline, with deterministic code owning the state, the gates, and the evidence instead of leaving them to the model's good intentions.
Process Engine remains the Turnstone-native, prompts-only reference implementation — active, not abandoned. Method Factory is the prompt+code evolution of the same idea. (More on the relationship below.)
A note on where RC1 stands. The deterministic pipeline foundation described below is real and tested, but
v2.0.0-rc.1is an engineering release candidate: its packaged public interface currently exposesmigrate-storeandexport. The full conversational authoring lifecycle is not yet a polished public entry point. See What RC1 provides today.
Tell it what you want to build, share what you already have, and Method Factory walks a proven pipeline with you — not around you:
flowchart TD
A[Intent] --> B[Collect]
B --> C[Clarify]
C --> D[Objective]
D --> E[Summary Gate]
E --> F[Pattern Author]
F --> G[Review]
G --> H[Trial]
H --> I[Ship]
I --> J[Triage]
In human terms, the journey looks like this:
- You say what you want. "I need an agent package that helps a small team manage its Etsy store."
- Method Factory collects what you already have. Links, docs, past runs, examples — nothing is rejected by type.
- It clarifies ambiguity instead of guessing. One question at a time, until the intent is concrete.
- You define what good looks like. The objective and the outcomes you will accept.
- It summarizes the working basis and waits for your confirmation. Nothing is authored before this gate.
- Only then does authoring begin. The package is drafted against the agreed basis.
- Output goes through review and trial before shipping. Evidence is checked, not assumed.
- Real feedback returns through triage. What shipped informs what ships next.
The operator is the only authority at the consequential gates. The model proposes; code validates, authorizes, persists, and verifies.
Prompt-only systems are a great way to discover a workflow — run enough real conversations and you learn what actually works. But asking one LLM to both do the work and enforce its own rules makes the guarantees fuzzy. If the only thing stopping an invalid transition is a paragraph of instructions inside the same prompt that is doing the work, "guaranteed" is doing a lot of work.
Method Factory separates those jobs:
- the model talks, clarifies, reasons, and creates — conversation and content generation;
- code remembers state, checks gates, persists evidence, and rejects invalid transitions — the deterministic mechanics;
- the human remains the authority at consequential gates — confirmation, review, and ship.
That separation is the whole point. (The technical name for the proposal mechanism is the JSON Action Envelope — you do not need to know it to use the product.)
- Intent before generation. It does not immediately start writing. It collects, clarifies, and asks what "good" looks like before producing anything.
- Human gates. Consequential transitions require explicit authority. The pipeline cannot talk itself into shipping.
- Code enforces, models create. Deterministic mechanics are not delegated to prose. The model's job is to be creative and precise — not to police itself.
- Evidence survives the conversation. State and history live in a real transactional store, so the trail outlives the chat session.
- Portable by design. Core mechanics are not tied to one agent harness. The same logical pipeline can run on different clients.
- Migration without rewriting history. Existing public stores can be migrated while preserving evidence and source integrity.
Good fit:
- You build reusable agent personas, skills, and packages and want them to be more than a pile of prompts.
- You care about repeatability, evidence, and knowing why a package exists in its current state.
- You want human approval gates in the workflow, not model self-discipline.
- You want enforcement to live outside the LLM prompt — in code the model cannot talk its way around.
- You need portability across agent environments.
- You are comfortable with an engineering-oriented release candidate rather than a polished end-user product.
Not a fit right now:
- You want a one-click UI or a mature end-user application.
- You need a complete lifecycle command set today (see What RC1 provides below — the public CLI is intentionally minimal).
- You need the final stable
2.0.0rather than a release candidate.
None of these are bad wants. They are just not what this RC is.
Say you need: "an agent package for managing a small Etsy store — listing SEO, policy review, and weekly shop targets."
With Method Factory, the interaction would go something like:
- You state the intent. "I want an Etsy store-manager package."
- It asks for material. "What do you already have? Past listings, shop data, pricing rules, review checklists?"
- It clarifies. "You said 'policy review' — does that mean a pre-publication compliance check, or an audit of existing listings?"
- It confirms the objective. "Here is what I understand good looks like. Working from: 3 links + 2 text blocks + 1 example run. Is this the right basis?"
- Only after you confirm does it draft the persona, skills, templates, and evaluation cases.
- Review and trial happen against the evidence you approved — and nothing ships without your sign-off.
That is the shape of the product: a patient, explicit partner that would rather ask than guess, and that treats your approval as a real gate rather than a formality.
Note: in RC1 the deterministic foundation, persistence, migration, and export surfaces are real and tested; the full end-to-end authoring conversation is not yet exposed through a polished public lifecycle command. See the next section for exactly what is usable today.
There are two different things, and it is worth keeping them straight:
- Method Factory as the product architecture — the deterministic pipeline, state machine, gates, persistence, and evidence model described above.
- What the
v2.0.0-rc.1packaged public surface exposes today — a deliberately small, verified foundation:
The public CLI has exactly two commands:
mf migrate-store # migrate a public v0.1.2 JSONL store to the SQLite store
mf export # export events deterministicallyWhat RC1 actually provides:
- a SQLite canonical store with an append-only event model and deterministic replay validation;
- immutable content-addressed artifact storage;
- migration from public v0.1.2 JSONL stores, with a durable receipt and no-overwrite publication;
- two deterministic exports:
method-factory-events-v1(current evidence) andlegacy-v012-jsonl(v0.1.2-shaped evidence that revalidates against the frozen legacy reader); - Python 3.11 and 3.12 support.
What RC1 does not provide:
- generic import;
- backup/restore;
- garbage collection;
- lifecycle commands (
create,apply,status,summary,review,trial,ship,triageare not exposed); - the final
2.0.0release.
So the honest answer to "how can I use Method Factory today?" is: as a deterministic persistence and migration/export foundation, and as the architecture the full pipeline will run on. If you are looking for a one-command end-to-end authoring experience, that is not RC1 — and we are not pretending otherwise.
Install the RC1 wheel
v2.0.0-rc.1 is not on PyPI. Download the wheel methodfactory-2.0.0rc1-py3-none-any.whl from the GitHub Release, then install that local wheel:
pip install ./methodfactory-2.0.0rc1-py3-none-any.whl
mf --version # methodfactory 2.0.0rc1For development/contributor work, an editable install (
pip install -e ".[test]") is the right path — it is a developer workflow, not an equivalent public release installation.
Migrate an old v0.1.2 store:
mf migrate-store --source <legacy-root> [--dest <sqlite-path>]The destination defaults to <source>/methodfactory.sqlite3; migration refuses to overwrite an existing destination and never mutates the legacy source.
Export evidence:
mf export --store <root> --output events.jsonl --format method-factory-events-v1
mf export --store <root> --output legacy.jsonl --format legacy-v012-jsonlBoth exports are deterministic and read-only.
| Process Engine | Method Factory | |
|---|---|---|
| Enforcement | Prompts + Turnstone governance | Deterministic code |
| Platform | Turnstone-native | Platform-agnostic |
| Prompts | Include enforcement rules | Conversation + content only |
| State machine | Prompts describe it | Code enforces it |
| Manifest | LLM reads/writes TOML | Validated schema + code I/O |
| Persistence | JSONL experiments | SQLite canonical store |
| Trials | Prompt-described | Code-driven harness |
| Status | Active reference | RC1 release candidate |
Process Engine discovered and proved the conversational pipeline through hundreds of prompt-only experiments and a real end-to-end case study. Method Factory takes that lineage and moves the deterministic state, gates, and evidence into code. This feels like lineage, not dependency: Method Factory stands on Process Engine's shoulders, then changes the enforcement model.
Code owns: state machine, gate enforcement, manifest I/O, persistence, exports
Prompts own: conversation, clarifying questions, content generation, tone
Design principle: the model should not be responsible for enforcing its own constraints. Code enforces the rules; prompts guide the work.
For engineering detail, see:
- Architecture reset status — current state + full gate history;
- Public surface & error contract — the authoritative API boundary;
- ADR-0012 — persistence architecture — the SQLite canonical store decision;
- Action Envelope and Manifest contract v0.1 — protocol and schema.
One honest non-claim, so it is never a surprise later: the event hash chain provides internal consistency evidence, not cryptographic authenticity. An attacker who replaces and rehashes the whole database would not be detected by the chain alone.
This RC was not accepted because the happy path worked once.
- 420 tests green on Python 3.11 and 3.12.
- Fault injection across atomic publication — crash states fail closed, no partial success reported.
- Migration and export verification — canonical v0.1.2 fixtures migrate and revalidate; exports are byte-deterministic.
- Isolated wheel install — the packaged artifact installs and runs from site-packages, not the checkout.
- Exact-commit CI — the release-gate checks out and tests the precise commit identity, not a synthetic merge.
The full development gate history lives in architecture-reset-status.md; this README just tells you the outcome.
Method Factory is built from the domain knowledge captured in Process Engine — the pipeline design (Intent → Collect → Clarify → Objective → Summary Gate → Pattern → Review → Trial → Ship → Triage) that emerged from hundreds of prompt-only experiments and was validated in a real end-to-end run.
The prompt-only phase was not a shortcut — it was the discovery method. We did not guess the architecture. We ran real interactions until the lifecycle proved itself. Now the guarantees are hardened into code.
- Architecture reset status — current state + gate history
- Public surface and stable error contract
- ADR-0012 — persistence architecture
- Action Envelope — prompt/code protocol
- Manifest contract v0.1
- Migration from Process Engine (historical)
MIT — see LICENSE.