Skip to main content
Agent Lab ships a catalog of workflow kits that operators can pick up, run, and adapt. Each kit is a self-contained package that covers one business workflow end to end: what it does, when to run it, what inputs it needs, and how it validates. Use this page to understand what a kit contains, how to read its status, and which series to open first for the problem you are trying to solve.
This catalog describes packaged workflow kits for operators and buyers. The Agent Lab runtime also seeds a separate suite of 10 live autonomous workflows into every workspace. See Autonomous runtime workflows for that set.

What a workflow kit contains

Every kit follows the same folder shape so operators know exactly where to look. A typical kit includes:
  • README.md: packaging status and registry metadata for the workflow.
  • kit.md: the operative manifest that governs the kit (see The kit/1.0 manifest).
  • automation/: blueprint files for Make.com, n8n, or other runtimes when the workflow is automated.
  • trackers/: Excel or CSV tracker templates the workflow relies on.
  • source/: reference documents extracted from the original workflow source.
Once a kit exists, kit.md is the file to open first. It carries the trigger, owner, cycle time, inputs, setup steps, validation checklist, and change log for the workflow.

The kit/1.0 manifest

Every kit is described by a YAML frontmatter block at the top of kit.md that conforms to the kit/1.0 schema. The manifest is what makes a kit reproducible and reviewable, not just a folder of files. A representative manifest looks like this:
The fields that matter most when picking up a kit:
  • workflowId and department: where the kit lives in the catalog.
  • trigger and cycleTime: when to run it and how often.
  • primaryOwner: who is accountable for outcomes.
  • automationLevel: rough share of the workflow the automation handles.
  • status and conformance: how mature the kit is (see below).
  • changeLog: dated entries for every meaningful change to the kit.

Kit status: Draft, Active, and Certified

Kits move through three status levels. Do not treat a lower-status kit as if it were higher. The differences are about how much evidence backs the kit, not just how polished it looks. README.md in each kit calls out the current packaging status. kit.md records the same status in frontmatter and expands on what still blocks certification.

Two package variants

Most kits eventually split into two variants:
  • URC/internal package: runs the internal operating system and may keep internal roles, tools, and targets.
  • Client-facing package: scrubbed of internal specifics and safe to hand to a buyer.
Keep the variants explicit during conversion so internal operating docs do not accidentally ship as client deliverables.

The seven series

Kits are grouped into seven series, one per department. Each series uses a stable XXX-NN slug so operators can reference a workflow without ambiguity. Each series follows the same numbering convention, so MKT-06 always means Content Creation & Dissemination, and SAL-01 always means Proposals & Contracts. Reference kits by that ID in commit messages, change control entries, and cross-workflow handoffs.

How to navigate the catalog

Start from the problem you are trying to solve, not from the folder listing.
  • If you are a buyer, read the department-level series that matches your pain. Open the specific kit whose trigger matches when you would actually run it. The automationLevel field tells you how much of the workflow is automated versus manual.
  • If you are an operator, open kit.md first and work through Setup and Quickstart. Only dive into source/, automation/, or trackers/ when the manifest points you there. Record every meaningful change through the change log in the manifest and the change control register.
  • If you are certifying a kit, walk the Validation checklist in kit.md. Confirm the manifest’s status and conformance reflect reality. Split the URC/internal and client-facing variants before promoting the kit to Active or Certified.

The flagship: Founder Signal System

The marketing-founder-signal-system kit is the flagship starter package. It is a thin vertical slice across six Marketing workflows (MKT-01, MKT-02, MKT-03, MKT-04, MKT-05, and MKT-06) aimed at solo founders and small service-based businesses. The flagship is a Draft kit today. It is the first sellable cut while the underlying Marketing kits are still being converted. It deliberately excludes paid advertising (MKT-07), social media management (MKT-08), and event marketing (MKT-09). Use it as a template for how to package future cross-series bundles.