Engineering Fleet · Design partner beta
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.
Taking 10 startups as design partners. Free for 3 months.
We built it for ourselves. It runs on Lua’s own platform today.
Illustration of the fleet at work: tickets move through five stages (found, ranked, building, on staging, merged) while a feed reports each hand-off between agents, including the Engineering Manager proposing a fix to an agent and a person approving it. 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.
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.
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.
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.
Design partner beta
We’re taking 10 startups as design partners.
You use the fleet free for three months, set up on your stack with us. We get your honest view of what it should do next.
- 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 we ask for: a repository it can work in, and a short check-in every couple of weeks.
Questions
Before you apply
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 apply?
Yes. The beta is how we decide which stacks come next, and your answers are what we build the templates from.
What does being a design partner involve?
We set the fleet up on your stack with you, and you use it on real work. In return we ask for a short check-in every couple of weeks: what it got right, what it got wrong, and what you want next.
What does it cost, and what happens after three months?
Design partners use the fleet free for three months. We have not set pricing yet. We will share it with you before the three months end, and you decide then whether to carry on.