🤖 Shipping Three Products Solo on Agent Workflows

If you have been following along, you know that since February 2026 I have been building my own products. Guestavo is live in beta, AfterGather is in early access, and a third one is pre-launch. Each of them is a real monorepo with an API, a worker, a database, billing and a deploy pipeline. One person cannot type that much code in seven months.

I did not type most of it. I directed AI coding agents through tooling I built for the purpose, and this post is about that tooling - what it is, what it changed, and the three rules I had to learn the hard way.

The Problem

A coding agent with a blank prompt is a very fast junior with no memory. It does not know how this repository deploys, which decisions were already made, or that the outreach it is about to send has not been approved by anyone. Every session starts from zero, and every session drifts a little from the last one.

That is fine for a one-off script. It is not fine for running three products, the Corco Labs website and the infrastructure under all of it. So the question I ended up answering was not “which model” but “where does the knowledge live, and what is the agent allowed to do with it”.

The Tooling

Everything lives in one monorepo, and the agent-facing parts are ordinary files that the runtime validates.

Skills. Thirty-two domain folders - engineering, design, SEO, sales, delivery, security and so on - each with a short entry file and a reference/ directory holding the actual knowledge: conventions, checklists, playbooks, the decisions that are already settled. An agent working on a deploy reads the infrastructure skill, not a paragraph I paste into the prompt.

Workflows. A catalogue of 180 workflow definitions in YAML. Each one has an id, a summary, a list of the situations it is for, a list of sibling workflows it explicitly does not cover, and a chain of what comes next. The body is a sequence of phases, and every phase declares a goal, its inputs and outputs, the skills it uses, a model tier, and a gate that has to pass before the next phase starts. A workflow for building an API chains into hardening security and then into a staging deploy. A workflow for prospecting stages drafts with sent: false and stops.

A runtime and a console. A CLI parses a workflow into a graph and spawns one agent per node, with the cheaper model tier for the deterministic phases and the expensive one only where judgement is needed. A small web console sits on top so I can watch runs and read their event logs.

MCP servers. The studio’s own services - analytics, uptime, deploys, search console - sit behind one API with an MCP endpoint, so an agent can ask “how did traffic on that site change since the deploy” as a tool call instead of a screenshot. My project manager exposes the same thing for work: agents are first-class actors there, they claim tasks, post progress, and propose decisions over MCP with exactly the permissions a human with the same token would have.

None of this is exotic. It is files, schemas and a parser. The value is in what the files refuse to accept.

The First Rule: Agents Propose, Humans Accept

Anything a third party can see with my name on it goes through me. Outreach is drafted and staged, never sent. Decisions are recorded as proposals until a person accepts them. A pull request to someone else’s repository, a directory listing, a social post - the agent prepares it to the last step and hands me the button.

I learned this one by having an agent open a pull request against a public repository on my behalf, after I had said something that sounded like approval and was not. It was withdrawn, and the rule has been absolute since. The interesting part is how cheap the rule is to enforce once the tooling exists: every workflow that touches outreach or publishing ends at a staged draft by design, and the project manager’s MCP surface simply has no “accept” tool for agents.

The Second Rule: No Completion Claim Without the Check

Every agent session in the repository runs under a verification gate that reads roughly like this: re-derive the requirements from the request, inspect the actual diff against every one of them, run the smallest relevant test or build, and report INCOMPLETE or BLOCKED by name when anything is unchecked. Screenshots for anything visual, because a green build has shipped a page that crashed on load more than once.

This matters more with agents than with people, because an agent will happily describe a fix it did not verify in the same confident tone as one it did. The gate turns that from a character flaw into a process failure that the next phase catches. In practice it means the boring part of my day is reading test output and screenshots rather than reading code, which is a trade I will take every time.

The Third Rule: Measure With the Consumer, Not the Regex

The most expensive bug in the whole system was silent. The runtime’s parser used a whitespace pattern that ate one level of indentation, so a list nested under a phase’s actions collapsed into a single action. Roughly four in ten phases across the catalogue quietly became one task node each, which defeated the decomposition the whole design depends on. Nothing failed. Runs just did less, and did it worse.

The fix was small. The lesson was not: when you validate a file, validate it with the code that actually reads it. The catalogue now has a parity test that parses every workflow the way the runtime does, a show command that renders a workflow’s phases and gates exactly as the runtime sees them, and front matter that refuses an id which resolves to nothing. A dangling next_workflow used to be a typo. Now it is a failed load.

The Current Status

What changed is throughput. Three products in seven months, plus the Corco Labs site, the internal tools, and the infrastructure they run on, all with tests and deploys, from one desk. Guestavo’s operator app, public property pages, API and worker were scoped, built and shipped to beta in under five months.

What did not change is where the judgement sits. The agents did not decide that guest photo uploads should be QR-based, or that a hospitality product should be multi-domain with one locale per domain, or that billing should be wired before the waitlist opens. They did not choose Fastify over Nest, or notice that a migration would lock a table under load. That is still the job, and it is the part of the job I have always liked most.

The End

If “AI-native engineer” means anything, I think it means this: someone who can hold the architecture in their head, break it into work with gates that a fast and forgetful collaborator cannot slip past, and keep their hand on the button that matters.

The products this produced are on the projects page, and if you want to talk about what it would look like on your team, here is what I am looking for.

I hope you enjoyed this blog post and I will see you in the next one!