AutoPilot: an FDLC AI software factory that runs on the board you already use.
AutoPilot is an AI software factory that follows FDLC, the open Factory Development Lifecycle by fdlc.ai. It works the Trello board you already use — reads tickets, writes the code, opens reviewable PRs in your repo — with SOSA around every stage. If you wish, nothing ships without your approval: you choose how much AutoPilot does on its own.
The category problem
Teams already live in a board, a repo, and a CI pipeline.
The “AI software engineer” wave — Devin, GitHub Copilot Workspace, Cursor agents — sells a new surface you must adopt: a new IDE, a new task UI, a new place to babysit an agent one prompt at a time. But the work is already specified where you work. Adopting another surface is the cost, not the value.
FDLC · Nine stages
An AI software factory, with SOSA around every stage.
FDLC, the Factory Development Lifecycle, names nine stages that take intent to verified software. AutoPilot runs each one on your board, your repo and your CI, and a person still says yes before anything ships to production.
SOSA around every stage · Supervised · Orchestrated · Secured · Auditable
-
Stage 1: Intent
A card on your Trello board is the intent. AutoPilot reads cards from your To Do column; nothing moves to a new tool.
SOSA · Read-only, 1-hour Trello token in the setup wizard. Cards that touch money, a customer key or a real-account action are parked in Backlog with a 🔒 gated label.
-
Stage 2: Planning
AutoPilot picks the model for the run and, on Claude-backed cards, posts an architect brief to the card before the first commit.
SOSA · A per-day cost cap and metered cost on every run.
-
Stage 3: Execution
Each run starts in a fresh, isolated container and holds a board lease. One branch and one pull request per card, in your repo.
SOSA · No push to main. The build run stops at Code Review; production release approval is Stage 6.
-
Stage 4: Evidence
The PR link, branch, commit and green CI on that exact commit are logged on the card.
SOSA · Default-FAIL verify gate: no evidence seen this run, no advance.
-
Stage 5: Verification
A separate refinement session takes the card through Code Review, staging and a real QA gate. A failed card goes back to To Do with a brief.
SOSA · A card under a “request changes” verdict cannot be promoted again until the PR changes.
-
Stage 6: Approval
If you wish, nothing ships without your approval. Anything involving money or a customer key always waits for a person.
SOSA · You choose which releases wait for a person. Money and customer keys always do.
-
Stage 7: Release
Staging is automated after review. Your team promotes to production under your own branch protection.
SOSA · No unattended production. Production is always held for a human.
-
Stage 8: Outcomes
A card reaches Done only after QA evidence and a human promote. The run ledger records what ran and what it cost.
SOSA · Proven-outcome ledger: every action is attributable.
-
Stage 9: Learning
Bounce briefs, QA gap cards and the run log feed back to the board. People turn lessons into runbook and skill updates, as new cards.
SOSA · Full audit trail. Learning returns to Intent as new cards.
↻ Learning feeds back into Intent: the next card starts from what the last one taught.
Stage names from FDLC (fdlc.ai), an open framework for AI software factories. FDLC is not ours; the gates and SOSA controls shown are how OpsAgents AI AutoPilot runs each stage. See how a change ships · How SOSA works
Why us
It meets the work where the work already is.
Same job as the agent wave — done on your turf, and safe to leave running.
| Axis | Devin / Copilot Workspace / Cursor agents | OpsAgents Autopilot |
|---|---|---|
| Where it runs | a new agent UI you drive | your existing Trello board + GitHub repo (Jira and monday.com coming soon) |
| Attendance | interactive, one task at a time | unattended — fires on a cadence, picks the most-overdue board, ships, stops |
| Governance | trust the agent | SOSA: evidence-gated (PR + green CI on the head SHA before any “done”), $/day circuit-breaker, never-merges-to-prod, proven-outcome ledger, full audit trail |
| Model cost | per-seat / metered tokens | bring-your-own-model on Bedrock/Vertex — runs on credits you already have; idle ticks cost ~$0 |
| Isolation | n/a (single user) | per-tenant credential + state isolation |
Who it’s for
A real board, a real repo, more tickets than hands.
Dev agencies
Juggling several client boards? Autopilot keeps every board moving overnight — without a human babysitting each one.
SMB & seed-stage software teams
A backlog and no spare engineer for the long tail of well-specified tickets. Autopilot drains them to reviewable PRs.
Both share the shape: tolerance for “open a PR I’ll review,” but not for “merge to prod unattended” — which is exactly the SOSA contract.
Use case · Launch day
Launch day, run from one team chat.
A busy launch, a team chat full of asks, and nobody with time to update the board. Autopilot sits in the chat and keeps the work moving.
- Every ask became a card on the board, so nothing was lost in the scroll.
- Status answers came from the board, checked live, not from anyone’s memory.
- Decisions went to a person; code went to a PR that the CTO-agent reviewed.
Illustrative demo. The team, the brand and the messages are fictional.
Safe to leave running
Built around one invariant.
A tenant cannot touch another tenant’s credentials, repositories, or boards — nor our infrastructure or anyone’s production. Here’s how that holds by construction, not by good intentions.
Production waits for you, if you wish
The agent opens PRs and advances cards up to Code Review. If you wish, nothing ships without your approval (Stage 6).
- If you wish, nothing ships without your approval
- No direct push to main
- No production reach
Credentials isolated by construction
- Per-tenant gateway + own service account — reads only your secrets
- Trello token (the wizard asks for scope=read, expiring in 1 hour; a Trello token covers every board its member can see) + repo-scoped GitHub App, least privilege
- Secrets never in config — only the env-var name is committed
- One tenant per workflow — states can’t collide
Bounded & audited
- Per-tenant $/day circuit-breaker + wall-clock cap
- Destructive-op denylist at the gateway; config writes merge, never replace
- Default-FAIL verify gate — advances only on evidence seen that session
- Proven-outcome ledger — every action attributable
Straight answers
The questions every engineering leader asks first.
QWill it merge something broken?
No. It advances up to Code Review and opens a PR for CTO-agent review; if you wish, nothing ships without your approval (Stage 6). A card advances only on green CI on the exact head commit. The worst a malicious or prompt-injected ticket can do is open a PR in your own repo whose release your own engineer approves before anything reaches production.
QWhat does it cost to run?
Idle ticks are ~$0 — pure local + cheap gateway reads, no LLM. You pay only when a board is actually due and actionable, on your own model credits, under a per-tenant $/day cap.
QIs my code & board safe from other tenants?
Per-tenant credential + state isolation. Each tenant runs against its own dedicated gateway with its own service account — never project-wide, never another tenant’s.
FDLC questions
FDLC, AutoPilot and the lifecycles around them.
What is FDLC?
FDLC, the Factory Development Lifecycle, is an open framework published by fdlc.ai. It describes the operating model and technical foundation for AI software factories that turn intent into verified software, in nine stages: Intent, Planning, Execution, Evidence, Verification, Approval, Release, Outcomes and Learning, with Learning feeding back into the next intent. FDLC is not ours: OpsAgents AI did not create it, and AutoPilot is one implementation of it. The framework itself is at https://fdlc.ai.
How does AutoPilot implement FDLC?
AutoPilot reads a card from your Trello board (Intent), picks a model for it and, on Claude-backed cards, posts an architect brief before the first commit (Planning). It builds in an isolated run and opens one pull request per card in your repo (Execution), and records the PR, the commit and green CI on that commit on the card (Evidence). A separate refinement session takes the card through Code Review, staging and a real QA gate, and bounces it back with a brief if it fails (Verification). If you wish, nothing ships without your approval: you choose how much AutoPilot does on its own (Approval, Release). A card reaches Done only after release. The run ledger records cost per run, and bounce briefs and QA gap cards feed the next round (Outcomes, Learning). SOSA wraps every stage.
FDLC vs AI-DLC vs SDLC: what is the difference?
SDLC, the software development lifecycle, is the classic model for how people plan, build, test and release software. AI-DLC, the AI-Driven Development Lifecycle that AWS introduced in 2025, is a methodology in which AI drives work across its phases (Inception, Construction, Operations) while people validate the direction. FDLC, the Factory Development Lifecycle by fdlc.ai, describes the AI software factory itself: nine stages from intent to verified outcome, with evidence, verification and human approval as explicit stages and a learning loop back to intent. AutoPilot follows FDLC's stages and keeps the SDLC tools your team already uses: your board, your repo and your CI.
Onboarding
A gate, not a signup form.
A tenant is not enabled until all of these are true — and the first run is supervised by an operator before any unattended cadence is switched on:
From a pilot client
An initial estimate of 5–7 weeks to build the new feature set — down to just 3 weeks with Autopilot.
Get started
Point it at your board. Wake up to reviewable PRs.
One supervised pilot on a single module — within days you’ll see a full PR, a CTO-agent code review and QA, and a person approving every production release, with a complete run-ledger. Start below: five quick steps to a scoped estimate.
- 1Connect
- 2Scope
- 3Grill-me
- 4Email
- 5Estimate
Connect your board
Paste the board Autopilot should drain. It opens PRs that the CTO-agent reviews; release approval is covered in Stage 6.
That doesn’t look like a Trello board URL (trello.com/b/…) or an 8-character board ID.
Continue opens Trello, where you grant read-only access for one hour. Your Trello access stays in this browser: it never reaches our servers and is forgotten when you close the tab. When you send the request, the board name and the cards you picked are sent with it.
Pick the scope
Sample tickets, so you can feel the flow — your real board’s tickets appear here once connected. Filter by tag, untick anything out of scope.
0 tickets in scope
Pick at least one ticket to scope the pilot.
Grill-me: a few questions before any agent touches a ticket
Optional but sharpens the estimate. Your answers stay in this browser tab — nothing is sent yet.
Where should the estimate go?
You’ll see the preview on the next step either way — the full, operator-prepared estimate goes to your inbox.
Please enter a valid email address.
Your pilot, previewed
Illustrative preview — the emailed estimate is prepared and priced by an operator.
What you get
Payment milestones
Full estimate goes to . First run is operator-supervised; release approval is covered in Stage 6.
Prefer email? Point it at your board · Request the security one-pager
Or just ask
Meet Maya
The AI that sells on your website — Maya greets every visitor in their language, answers what they ask, recommends the right product or service, and captures the lead.