Engineering Fleet · Waitlist
The engineering team that maintains itself.
Six agents that find what is breaking, file it, fix it and test it on staging, with a manager that improves the team itself. Your merge rules and approvals decide how far it goes.
Our design partner places are taken. The waitlist is open.
We built it for ourselves. It runs on Lua’s own platform today.
Illustration of the Engineering Manager's board: tickets move through intake, building, review and CI, staging and done, with live counts above each column. The data is made up.
The loop
From a log line to a merged fix
Not one assistant waiting for a prompt. A team with roles, a board, and a hand-off at every step.
01Scouts
Find the work
One agent reads your error logs and groups recurring failures. Another tracks dependency and code-scanning alerts. Both file tickets that name the file, the cause and what done looks like.
02Ticket Master
Run the board
Vets every ticket, closes duplicates, ranks by severity, and hands the most critical one to the builder next.
03Ticket Pilot
Write the change
Picks up the ticket, works in its own sandbox, opens a pull request, and follows it through CI and review.
04Staging Sentinel
Prove it on staging
Deploys the pull request to staging and tests it before and after the change. A regression goes back to the builder. A pass is recorded on the pull request.
05Your rules
Merge
Merges follow your branch protection: checks, reviews, signatures. How much happens without a person is a setting you turn up.
In work
Watch every ticket move, step by step
The Engineering Manager’s live view: each ticket an agent is moving, the step it is on, its pull request’s review, CI and staging state, and its last event.
Illustration of the Engineering Manager's In work view: each ticket an agent is moving advances step by step through build, review, CI and staging, and merged tickets appear under Just shipped. The data is made up.
Self-healing
When the fleet gets stuck, it fixes the fleet
Agents that only do tasks stop when something around them breaks. This team has a manager whose job is the team.
- NoticeThree runs stall on the same error.
- DiagnoseThe cause is in the builder agent, not the tickets.
- ProposeA code change to that agent, staged as a new version.
- ApproveYou release the new version.
It watches its own work
The Engineering Manager reads each agent’s status and the board: which tickets are stuck, and where the flow is backing up.
It fixes the agent, not just the ticket
When the cause is in an agent, it proposes a code change to that agent, stages a new version and opens a pull request. Nothing goes live until you approve the release.
Stalled work goes back on the board
A run that dies, or a ticket nobody started, is returned to the backlog with a note saying why.
Velocity
Know when the week’s work will land
Burn-up, cycle time and the age of every ticket in flight, counted from your board. Work that is likely to miss shows up before it does.
Illustration of the Engineering Manager's Velocity view: the week's burn-up climbing towards its scope, KPI tiles, and work in flight plotted by age against cycle-time bands. The data is made up.
The team
Six roles, one fleet
Each agent has one job and hands its work to the next, the way an engineering team does.
Reliability Engineer
Reads your logs for recurring failures, traces each to the code and recent commits, and files a ticket with a root-cause analysis.
Security Engineer
Turns dependency and code-scanning alerts into tickets, and runs read-only checks on your public endpoints.
Ticket Master
Triage, deduplication, ranking and dispatch, matched to how much the builder can take on.
Ticket Pilot
Writes the code in its own workstation, gets it reviewed, and shepherds the pull request to merge.
Staging Sentinel
Deploys pull requests to staging and exercises them before and after the change: happy paths, edge cases, and what should not have changed.
Engineering Manager
Supervises the fleet, holds its policies, reports to you, and proposes improvements to the agents themselves.
Fleet health
Reliability, security and efficiency, each measured
Every measure with its trend and its 24-hour and 7-day change, and where the Engineering Manager is already acting on it.
Illustration of the Engineering Manager's Fleet health view: the fleet and each area marked healthy or on track, with every reliability, security and efficiency measure shown with its trend and its 24-hour and 7-day change. The data is made up.
Control
You decide how far it goes
Autonomy is a setting, not a leap of faith. The rules live in code, not in a prompt.
Starts in dry run
New agents begin by reporting what they would do, without writing to your board or repositories.
Your merge rules hold
It merges only what your branch protection allows.
Evidence before merge
A staging pass is recorded against the exact commit it tested.
Approvals where you want them
Releases to the agents themselves wait for you.
Limits and stop switches
Caps on tickets per run and per day, and a stop switch on every agent.
Waitlist
Get early access to the fleet.
Join the waitlist and we will be in touch as we open the fleet to more teams, starting with the stacks it already fits.
- Runs on GitHub and Linear today. Tell us your stack: the answers decide which ones we build next.
- One-click install is where this is going. During the beta we connect it for you.
- What it needs: a repository it can work in, and access to your ticket board, logs and staging.
Questions
Before you join
Does it change production on its own?
Only as far as you allow. It starts by filing tickets and opening pull requests. Merging is off until you turn it on, and then only for changes that passed on staging and meet your branch rules.
What does it need access to?
Your code host and ticket board to do the work, and your logs and a staging environment to find problems and test fixes. Today that means GitHub, Linear and Better Stack logs. You authorize each connection yourself and choose which repositories it may work in.
Does our code go to an AI model?
Yes. The agents read code, tickets and logs to do their work, and that content is processed by the model provider the fleet is set to use. Every provider we use is on our subprocessors list.
We don’t use GitHub and Linear. Should we still join?
Yes. The waitlist is how we decide which stacks come next, and your answers are what we build the templates from.
What happens after I join the waitlist?
We read every entry ourselves. As we open the fleet to more teams, we get in touch, set it up on your stack with you, and you use it on real work.
What does it cost?
We have not set pricing yet. We will share it with you before you start, and you decide then whether to go ahead.