Stripe wrote down how they add a payment method. The part worth taking is the contract, not the model: a job you will do again, cut into steps, one pull request each, a person still on the merge. We build product on that contract. A Cursor cloud agent runs the step. I still merge it.
The first time you ship a surface, you invent the path. The second time, you notice you are inventing it again. An essay on this site is a route, a line in the manifest, and a share card. A tool is a page, a small library, and a row on the hub. The words change. The sequence does not. Rebuilding that sequence from an empty folder is how a week disappears into setup and gets called craft.
David Dunne, Xenofon Vourliotis, and Sai Samant published the version their team runs. The post is Stripe’s Payment Method Factory on the Stripe developer blog. It describes local payment methods. I'm using the mechanism. I'm not importing their results. The timelines and counts in that post belong to Stripe. They are not a figure this studio has measured, and they do not appear below as if they had.
What they actually separated.
In their account, a payment method sounds the same from the outside. It takes a payment, it issues a refund, it handles a dispute. Under that, the APIs do not match. Cards, wallets, and buy-now-pay-later products are different integrations that share a lifecycle. Stripe had already built that lifecycle over and over. What they did not have was a way to repeat the build without repeating the wandering.
The factory is a set of prompts, one per step, and a plan that orders them. Each step is supposed to land as its own pull request. They are plain about why a single prompt for the whole integration fails: the agent runs out of context, and the diff is too wide for a person to review. So they kept the lifecycle they already trusted. Start a session. Run one prompt. Review. Open a pull request.
The first coordinator was itself an agent. It ran, and then it did the thing coordinators do when they are also models: it sometimes performed the step instead of handing the step off, and spent the context it was supposed to be protecting. The line worth stealing is their conclusion. Predictable coordination belongs in ordinary code, not in the model that is also trying to write the integration.
Around that they keep a record. An observer reads the implementation transcript and notes where the agent got lost, what it had to relearn, and what failed. When the integration is finished, those notes, the decision log, and the review comments go back into the prompts. The prompt is a maintained artifact. It is not a chat you hope was good.
One step. One pull request. The coordinator does not also do the work.
What we kept.
We are not integrating payment methods. We ship a studio: essays, tools, and the products we own. The repeated job is a product step. The station that runs it is a Cursor cloud agent, on its own branch, with the repo in front of it. The coordinator is the brief, written down before the agent starts. It is not a second model sitting above the first.
- 01The step is one pull request. It does not pick up the neighboring ideas because they were in the same folder.
- 02The agent opens the pull request and stops. It does not merge. I merge, after the person who owns the surface has read the diff.
- 03The brief names the pattern, the voice, and the refusals. For a public page, the refusals include invented figures and anything that does not belong in a diff.
- 04The pull request is the artifact. A transcript nobody reviews is not a ship.
What we did not copy.
Stripe runs an observer beside the implementer, and they let agents hit a provider sandbox and freeze the responses as contracts. That fits a payments integration. It is not what this studio runs. I read the diff. If I cannot read it in one sitting, the step was drawn too wide. The fix is a smaller step, not a summary of the large one.
We also do not move their scoreboard onto our site. If a piece of ours needs a figure, the figure has to be one we measured and can show. If we have not measured it, it stays out of the sentence. A factory that invents its own proof is a machine for publishing fiction.
Prompt maintenance, here, is still a person. When a review catches a miss — the wrong author line, a hard sell where the house style is a quiet link, a claim with no source — the brief gets a line, so the next step does not rediscover it. We do not have a button that rewrites the prompts from the transcript. Saying we do would be the invented part.
What it looks like on this site.
This essay is a step of that kind. The brief was narrow. Add one post in the pattern the existing essays already use. Register it in the manifest, newest first, so /blog lists it. Match the author line to the other posts: I write the operator pieces. The named agents write the pieces that come from their station, and those carry a review line with my name. Open the pull request. Do not merge.
The files are the ones those posts already have. A page, a manifest entry, and a share image that delegates to the shared card. Nothing new in the chrome. The judgment the step is allowed to exercise is the copy, inside those rails — including the decision to leave a number out when we do not have one.
Where the judgment still sits.
The factory removes the blank page. It does not remove the call. Someone still decides the step is the right size, still reads the result, still sends it back when the voice slips into a pitch. On our product work, that someone is the owner of the surface, and the merge is still mine. The agent is the station. Swap those two and the coordinator is doing the work again, which is the failure Stripe already wrote down.
The brief is the orchestrator. The pull request is the handoff. The merge is a person.
If you are running agents against your own product and the “factory” is one long session that ends in a diff you skim, you do not have their system or ours. You have a chat with commit access. Cut the job until one step fits in one review. Then run the next step. That is the whole steal.