The Agent Catalog

FlowForge doesn’t treat AI as a single genie. It runs a bench of specialists — each one a deeply-prompted expert in one discipline, each dispatched by ACE for exactly the work it’s best at. This chapter is the roster: 53 specialist agents, split by discipline, one entry each.

The same catalog is published on the web at flowforgesoft.com/agents — this chapter mirrors that structure so the manual and the site read as one product.

Routing, in one sentence: reach for the specialist when it multiplies you — parallel work, deep domain expertise, or an independent review — and say why when you don’t. Some disciplines are hierarchical: a strategy-level architect decides the approach and hands a brief to a leaf agent that implements it. Those pairs are noted below.

Project Ingest & Discovery

fft-code-explorer — The phase-0 project-ingest specialist. Reads the source tree, the database schema (inferred from migrations — no live credentials needed), configs, and lockfiles to detect what a project is: frameworks and exact versions, languages, dependencies, architecture, entry points. It never guesses — it verifies at source — and then scopes the downstream specialist wave. This is where landing a legacy codebase begins.

Architecture & Planning

fft-requirements-analyst — The anti-fabrication interrogator. Grills scope before any architecture is drawn, captures the customer’s intent verbatim, and produces the structured requirements packet everyone downstream builds from. Read-only: it asks and reports; it does not write the code.

fft-architecture — The system architect. Owns structural decisions, design patterns, and technical leadership — the SOLID, do-it-right-and-do-once decisions that are expensive to undo.

fft-project-manager — Breaks features into tasks, builds the milestone and ticket structure, and keeps the plan organized.

fft-product-owner — Prioritizes for value, aligns stakeholders, and guards the line between what’s in scope and what isn’t.

API & Backend

fft-api-designer — REST, GraphQL, gRPC, and WebSocket API design: contracts, OpenAPI specs, versioning, and developer-friendly surfaces.

fft-backend — Server-side implementation across Node.js, Python, Ruby, Java, and Go — auth, services, and scalable architectures.

Database

Database is hierarchical, and it is the one org whose split is a split of rights: the architect designs the data on files and never opens a connection — it has no shell at all — while the DBA is the only agent allowed to touch a live database, and only through the flowforge db door. Reads of production run under a read-only role; any change to production needs a grant you issue, recorded and expiring. Nobody in the crew ever holds the owner key.

fft-database-architect — The data-model head (formerly fft-database). Decides which store fits — asking first whether PostgreSQL already absorbs the need — then the ERD, the physical design (keys, indexes, partitions), who may read and write each table and how to read that back, and the migration plan step by step with its lock cost and its way back. Hands all of it down as a SCHEMA BRIEF, and judges the DBA’s report against it.

fft-dba — The operating leaf, for Supabase-PostgreSQL and SQLite today. Rehearses every migration on a disposable copy first, reads production read-only, applies a change only with the brief, the rehearsal evidence and your unexpired grant, then reads the result back and returns an OPERATION REPORT — including “prepared, not applied” when the grant is missing. It never changes the design, never runs anything destructive, never puts a password on a command line, and never signs off on its own work.

Frontend & Design

Design work is hierarchical: the design authority decides which guidelines govern this surface and hands a brief to the right leaf implementer.

fft-design-architect — The master design authority — the design analog of the system architect. Holds the guideline corpus (Apple HIG, Material 3, WCAG, the FlowForge design canon and brand manual) and emits the per-surface design brief that the leaf designers implement against and the reviewer judges GOLDEN against. Design strategy starts here.

fft-frontend — React, Vue, Angular, and modern UI — the web implementation leaf: component architecture, animation, and responsive, accessible interfaces.

fft-web-designer — The web visual-craft leaf: the look of the marketing site, the admin dashboard, and the desktop app’s web chrome — composition, visual hierarchy, responsive visual layout, motion, and light/dark theming. It applies the brand tokens against the design brief and hands fft-frontend an implementation-ready visual spec. Owns the look; defers research, information architecture and print to fft-designer, and the code to fft-frontend.

fft-designer — The UX-discipline and design-system leaf — user research, information architecture, usability and accessibility method, and design-system architecture — plus all print/papelaria surfaces (reports, PDFs). It also carries mobile and native-app design for now, until a dedicated platform-design leaf is minted. Implemented against the brief.

fft-brand-architect — Brand identity, color theory, typography systems, and design tokens — the brand leaf.

Mobile

fft-ios — Native iOS: Swift, SwiftUI, UIKit, structured concurrency, and the App Store lifecycle.

fft-android — Native Android: Kotlin, Jetpack Compose, Material Design 3, and Play Store compliance.

fft-flutter — Cross-platform Dart 3+ with Riverpod and GoRouter, adaptive UI across iOS/Android/Web/Desktop.

Terminal UI

Terminal-UI work is hierarchical: an architect decides composition, a designer crafts each screen’s visual, and a leaf writes the view code — architect → designer → tui.

fft-tui-architect — Strategic terminal-UI composition: full-screen layout, focus across panes, responsive breakpoints, Charm-ecosystem-adoption discipline, and the visual QA gate. Decides composition; delegates per-screen visual design to fft-tui-designer and line-code to fft-tui.

fft-tui-designer — The terminal visual-design leaf: per-screen mockups, visual hierarchy, color/glyph/label co-render, spacing-token application, and state tables — the “gorgeous” bar. Holds the founder’s taste as canon (the TUI Design Manual, the Spacing Canon, the header/frame blueprint) and hands fft-tui an implementation-ready screen spec.

fft-tui — Deep Charm.sh craft: BubbleTea, lipgloss, bubbles, glamour, and the Elm Model-View-Update pattern, with accessibility, responsive design, and a 60fps budget. The cockpit you use is its work.

Quality & Security

fft-qa — Quality assurance and test strategy: TDD, coverage, and testing across unit, integration, E2E, and performance.

fft-code-reviewer — The code-quality guardian and the sole arbiter of the GOLDEN verdict. It verifies a worker’s claims against the primary sources, not against the worker’s own word.

fft-security — Threat modeling, OWASP compliance, and defense-in-depth security review.

fft-web-quality — Empirical web-PR validation: multi-viewport screenshots, Core Web Vitals, axe-core WCAG scans, broken-link detection — evidence, not opinion.

Operations

fft-devops-agent — The platform operator: deploys, DNS, certificates, Terraform plan and apply, CI workflows, secrets plumbing and cost reads — for the stack your project actually runs, through the flowforge platform door and your recorded approval. It never touches a database or runs a release.

fft-github — Git and GitHub workflows: branches, PRs, issue mechanics, and repository management.

fft-release-engineer — The release operator. Runs a release from “the lane is ready” to “customers have it” through FlowForge’s own release verbs: the pre-flight, the release notes and letter pack, the cut up to its consent request, the tag, staging, verifying every artifact by name, the candidate rehearsal, the check a customer would make after the promote, and the install-parity update. It carries the documented release traps. It never answers the cut’s consent and never promotes — those two approvals stay yours.

Documentation

fft-documentation — Technical writing, API docs, and knowledge management — comprehensive, maintainable documentation.

fft-documenter-br — Brazilian-Portuguese documentation, with rigorous PT-BR grammar and diacritics. It rejects European Portuguese; all PT-BR content routes through it.

fft-documenter-es — Spanish documentation, with RAE orthography, tildes and inverted punctuation, and a Latin-American register. The Spanish counterpart to fft-documenter-br.

Marketing & Content

Marketing is hierarchical: one head holds the story every lane tells, and the lanes tell it. The head decides; it writes no copy, posts nothing and spends nothing. Paid media keeps its own head (below) and brings only cross-lane questions up.

fft-marketing-architect — The marketing head. Decides what the company says, to whom, in what order and through which lanes: the positioning canon and its locked message spine (one primary claim, three proof points, one call to action, the exact claim wordings every lane copies), the launch tier a release earns — judged by what changed for the buyer, not by the version number — the calendar, each lane’s role, and how a budget splits between lanes. It writes the LAUNCH BRIEF the lanes plan against, built from what the product owner and the analytics head already own. Where a number does not exist it says UNKNOWN and names the work that would produce it; it never rules on a dispute it is part of, and it only drafts — it never publishes or spends.

fft-content-strategist — The copy leaf: the words for every lane. Landing pages, on-page SEO content, email copy, micro-copy, long-form prose, and ad-copy variants, written to a brief it did not author. It never invents positioning, an audience, or a success metric, and no number, quote, or claim ships without a cited, dated source — an unsourced line is a visible gap, never a guess. It drafts; it never publishes.

fft-social-media — The social leaf: brand broadcast and platform mechanics on six platforms — Instagram, LinkedIn, X, TikTok, YouTube packaging, and Facebook Pages and Groups. It keeps the dated platform constraint sheet every lane writes against, drafts every reply to inbound comments for a person to approve, never deletes a criticism, never runs Page ads, and judges a post only against the account’s own baseline — never an invented benchmark.

fft-devrel — The developer-relations leaf. It earns a product its place on the channels developers trust — Hacker News, Reddit, Product Hunt, Discord, developer newsletters and creators — by helping developers succeed in public. It decides which technical stories get told, where, and with what proof; researches creators one by one and drafts outreach for the founder to send; runs the Discord programme; and reports the questions the documentation does not answer. It never votes or asks for votes, never uses a second identity or hides who it works for, never touches a review, never posts as a real person, and never launches without the founder’s go and a real, consenting person to post. It only drafts — a person presses post.

fft-product-marketer — The product-marketing leaf: turns the head’s story into the material a sale runs on. It keeps the claims table — the list of what the company may say, each claim with the evidence behind it, re-checked on every release — and builds battlecards, the kit for a founder-led deal, case studies and the announcement for each release from it. It applies the story the marketing head holds; it never owns or changes it. It never decides a price, never names a competitor in anything a buyer reads, never asks a customer who has not yet got value for a case study, and never invents a quote. It only drafts.

fft-lifecycle-marketer — The lifecycle leaf: owns what a person receives by e-mail, from the day they subscribe or sign up until they are a paying, active customer. Its steady job is the newsletter: each issue, it asks every agent that owns a part for that part — what shipped, the story, the numbers, the words — and assembles one pack; on send day it runs a checklist, every line with its proof (the issue’s gate and preflight, the test send received, consent and unsubscribe proven, the pages built). Between issues it reads the list’s health with the data analyst — who joined, who left after each issue, what bounced — and designs the welcome, activation and win-back journeys. It never writes the words, never mails anyone who did not ask, never touches an account customer success looks after, and never counts an “open” as a person reading. It only drafts — the founder presses send.

Customer Success

Customer Success is hierarchical: the architect designs the retention machine and hands a play brief to the analyst, who runs it against real accounts.

fft-cs-architect — The CS strategy head. Designs the onboarding→adoption→retention→ expansion architecture, the health-score model (usage, engagement, sentiment, support, and billing signals — leading indicators, not vanity green), churn-risk modelling, QBR and success-plan structure, and the segmented playbooks. Knows the tool landscape — Gainsight, Totango, ChurnZero, Vitally-class — and the NRR/GRR math that makes retention the compounding engine.

fft-cs-analyst — The execution leaf. Runs the architect’s playbooks against named accounts: touchpoint cadence, per-account health reports, renewal-runway tracking, save plays on risk triggers, and structured outcome reports back to the head. It never re-authors strategy — when reality contradicts the brief, it escalates with evidence.

Paid Media

Paid media — tráfego pago — is hierarchical: the architect designs the campaign; the media buyer builds and operates it inside the actual ad consoles.

fft-paid-media-architect — The paid-media strategy head. Market and audience research (awareness stages), positioning and offer design, sales-funnel architecture, channel mix across Meta and Google/YouTube, campaign and creative direction, budget and bidding strategy, and the measurement plan — named success metrics, kill/scale thresholds, and the discipline of platform-ROAS versus blended truth. It designs every tracking rung, from nothing leaving the building (R0) to a browser pixel (R4), and records the rung the customer chose for their product — at or below the customer’s tracking dial, never a default.

fft-media-buyer — The execution leaf, the industry’s media buyer (the Brazilian gestor de tráfego). Operates Meta Ads Manager / Business Manager and Google Ads / YouTube: account and conversion setup at the customer’s chosen tracking rung (checked against the dial with flowforge tracking check), audience build with exclusion hygiene, campaign→ad-set→ad construction, budget and bid entry exactly as briefed, a hard pre-launch QA gate, then the post-launch optimisation loop against the architect’s measurement plan. Committing money needs a recorded, time-limited spend grant; creating accounts, accepting terms, and uploading customer lists stay in a person’s hands.

ML / AI

ML/AI work is hierarchical: a strategist decides the approach, then delegates to the right implementation specialist.

fft-ml-architect — Strategic ML/AI guidance: model selection, RAG-vs-fine-tuning, and GPU allocation. Decides; delegates to the specialists below.

fft-llm-openweight — Local and on-premise open-weight models (Llama, Mistral, Qwen, DeepSeek), quantization, and serving with vLLM / Ollama / llama.cpp.

fft-rag-engineer — Retrieval architecture: chunking, pgvector, embeddings, reranking, and RAG evaluation.

fft-agent-frameworks — Agentic applications with CrewAI, LlamaIndex, LangChain, AutoGen, and custom multi-agent systems.

Data & Analytics

Data work is hierarchical, and it splits three ways: the architect decides how truth is measured, the analyst computes it against real rows, and the dataviz designer decides which chart carries it. A dashboard therefore crosses two orgs — this one decides the form, the design org decides the look.

fft-analytics-architect — The measurement head, the analog of fft-architecture for numbers. Designs metrics and indicators so that every one names its population, join, window and denominator instead of implying them; designs the study (baselines, control arms, manipulation checks); derives thresholds from the population a gate actually fires on; and back-tests before shipping. It emits the measurement brief the two leaves execute, and it never computes a production number itself.

fft-data-analyst — The execution leaf. Runs the brief against real data: pulls from named sources with pull timestamps, projects a rule over real rows before it ships, computes cohorts, trends and deltas exactly as briefed, reads the event that actually changed the artifact rather than a proxy timestamp, and reports unknown as unknown instead of interpolating. It returns an evidence report a stranger can re-derive — and escalates any gap between the brief and reality rather than quietly adjusting the method.

fft-dataviz-designer — The presentation leaf: which chart tells which truth. Maps indicator kind to chart form against the perception canon (Cleveland–McGill’s accuracy ranking, Few’s one-screen dashboard discipline, Tufte’s data-ink, Wilke’s proportional ink, the FT Visual Vocabulary), composes the dashboard, and holds the accessibility floor — a CVD-safe palette, colour never the sole channel, unknown rendered as unknown. It hands a chart spec (data → mark → encoding) to the design and build leaves; it decides form, never styling, and never defines a metric.

Legal

Legal is hierarchical, with one head and one leaf per jurisdiction: the architect decides the legal strategy of a deal and writes the legal brief; the Brazil leaf and the US leaf draft and analyse under their own law. None of the three is a lawyer — every deliverable carries a short notice that it is not legal advice and names who must review it before anything is signed or filed (an advogado inscrito na OAB in Brazil, an attorney admitted to the state bar in the US). All three cite statutes by number and article, never invent a case or a regulation, and say so when the law may have changed after their knowledge date.

fft-legal-architect — The legal head for a software company. Asks before it drafts — parties, governing law, B2B or B2C, personal data, payment model, who owns the code — then decides which jurisdiction governs, which instruments the deal needs (SaaS or subscription agreement, MSA and SOW, development agreement, NDA, contractor and IP assignment, reseller, EULA, terms of use, privacy and cookie policy, DPA, open-source review, trademark and software registration), and builds the issue list graded high / medium / low with a fallback and a walk-away for each. When a contract crosses Brazil and the US, it issues one brief to both leaves and reconciles governing law, forum, data transfer and the IP ownership chain. It never writes the final jurisdiction-specific text.

fft-legal-br — The Brazil leaf. Drafts and redlines in Portuguese (English on request) under the Código Civil, the CPC and the Lei de Arbitragem; data protection under the LGPD (Lei 13.709/2018), ANPD regulations and the Marco Civil da Internet (Lei 12.965/2014); consumer terms under the CDC (Lei 8.078/1990); software and copyright under the Lei do Software (Lei 9.609/1998) and Lei 9.610/1998; and industrial property under Lei 9.279/1996 — including INPI trademark searches and filings, patents and software registration.

fft-legal-us — The United States leaf. Drafts and redlines in English under the chosen state’s contract law; privacy under CCPA/CPRA and the other state privacy laws, COPPA, CAN-SPAM and FTC Act §5, with GDPR interplay for EU users; trademarks under the Lanham Act at the USPTO; copyright ownership and registration at the Copyright Office; DMCA §512 safe harbor and DTSA trade secrets; and auto-renewal and cancellation law, with export control flagged.

Performance

fft-performance — Full-stack performance: profiling, load testing, caching, query optimization, and monitoring.

Medical

fft-medical — Brazilian healthcare: ANS, TISS, TUSS, and CBHPM, medical document processing, and LGPD/HIPAA compliance.

Meta

fft-agent-creator — The meta-agent: it creates and validates new FlowForge specialists, so the bench itself can grow to fit a project.

Optional packs

The roster above is the base bench: it ships with every install. On top of it, FlowForge carries optional packs — regional specialists that ride inside the binary but are installed only when you ask. A pack never enters the base count; it adds to it.

recebimento-medico — Brazilian medical revenue

Brazilian medical-revenue specialists: the faturista (glosa, recurso, prazos, pricing) and the TISS exchange-format specialist (XML/XSD, versions, portal integration).

• fft-faturista — The revenue-cycle owner for clinics, hospitals and cooperativas: from elegibilidade and autorização through the lote and the demonstrativo to glosa triage and the recurso de glosa. For every open item it names the clock that is running, the norm or contract clause behind it, and the days left. It always cites the source — the law, the ANS resolução or the contract — and where the law leaves a prazo or a price to the contract, it says the contract decides.
• fft-tiss-xml — The TISS exchange-format specialist: component versions, XSD validation, lote and guia structure, version migration, and integration with operadora portals and WebServices. It never asserts a TISS version from memory: it checks the ANS source at answer time and asks which version the operadora accepts before validating anything.

The pack’s home turf is Brazil, and its agents answer in Portuguese to a Portuguese user or document; the Portuguese edition of this manual carries the same entry.

How to install. Ask ACE — “install the medical-revenue pack” — or run it yourself:

flowforge agents install recebimento-medico

flowforge agents list shows the base roster and every pack, installed or available, on this machine; flowforge agents remove recebimento-medico undoes the install.

Where fft-medical stops. fft-medical stays in the base bench with the breadth of Brazilian supplementary healthcare: clinical terminology, ANS as an agency, the operadora modalities, medical document processing and LGPD compliance. The revenue cycle is pack territory. Without the pack installed, fft-medical says so and names the install command instead of improvising the faturista’s answer. Legal LGPD analysis of patient data goes to fft-legal-br.

Why it matters

Specialists are how FlowForge scales without losing depth. You describe intent; ACE routes the work to the expert bench, dispatches an independent reviewer to check it, and keeps the whole thing pointed at what you actually asked for. The bench is not fixed — fft-agent-creator mints new specialists as a project needs them — which is why the roster on flowforgesoft.com/agents and the one installed on your machine are living lists, not a frozen brochure.