Put a team on the task.
Name the repos and the result. Lantern assigns teams, receives their reports, and keeps the work moving until each run reaches its stop point.
Lantern 0.16.0 and Elves 2.37.0
Start with the result
Paste one request into Lantern. Use your repo names. Add the goal, any limits, and the point where work should stop.
Fix useful issues across repos
Ship high ROI issue fixes in storefront, billing-api, and admin-console. Check relevant issues and existing PRs. Use helpers where useful.
Each repo gets a bounded batch. Agents check the evidence before choosing work.
Ship named tasks
Ship saved carts in storefront and invoice exports in billing-api. Run both repos in parallel. Open PRs early and merge when independent review and checks are clean.
Name the work when you already know what you want.
Ship includes merge. Add stop before merge or PRs only when you want to approve the PRs yourself. Brainstorm and investigate requests stop with findings.
Build your request
Choose the outcome and limits. Copy the result into Lantern. This page does not start agents.
Your request
Lantern reuses your saved model choices. You can name a model or a helper role in the copied text.
Use several models on one task
Get separate proposals first
Brainstorm ways to simplify onboarding in storefront. Have Claude and Grok propose solutions independently, then critique the alternatives. Have the lead recommend an approach and explain any unresolved disagreement.
Use this when the main question is which approach to take. It does not authorize code changes.
Give the driver focused helpers
Ship checkout performance improvements in storefront. Give the driver a database helper and a frontend helper. Measure the baseline, check relevant issues, and verify the result. Keep a separate final reviewer.
Helpers get specific questions or owned code areas. Writers use separate worktrees.
| Lantern | Assigns teams, tracks the run, receives reports, checks progress, and handles permissions within the approved scope. |
|---|---|
| Driver | Owns the repo plan, helper assignments, integration, PR, review fixes, and authorized merge. |
| Helpers | Investigate, propose, write assigned changes, or critique. They report progress and questions to the driver. |
| Final reviewer | Checks the full change from a separate session. It cannot be one of the contributors. |
Prefer a different model family for final review. A fresh agent from the same family can review when no other qualified family is available. A model choice alone does not count as a review.
When Agy reviews, it uses /boost in plan mode. The host checks that Boost ran, the relevant code and docs were read, and the final report covers the exact commit. /grill-me remains optional planning input.
Lantern keeps the work moving
Lantern tracks the assigned task and next step for each agent. Agents send persistent progress, question, blocker, PR, review, and completion reports. Lantern also checks Herdr state and verifies the evidence.
- The driver checks issues and stages the work. It opens a draft PR at the first useful push so configured bots can start reviewing.
- Helpers work within their assignments. They can ask permitted peers for input. The driver resolves dependencies and integrates writer changes.
- A separate reviewer checks the full PR. The driver fixes findings and gets a review of the fixes.
- For Ship, the driver updates docs and version files, merges when clean, checks the release and deployment, then reports the result.
Keep Lantern open. It uses a recurring job when available, or an active check loop. Reports wait until safe checkpoints; they do not interrupt working chats. Lantern checks the evidence before marking work done and stops monitoring when the selected work is complete.
Ask for progress
Show progress for storefront and billing-api. Include the current task, PR, next step, and any question that needs my decision.
Set a clear stop point
For this run, stop before merge. Keep the PRs ready for my review.
Routine permissions stay within the approved task. Questions that change scope, unavailable exact models, and unresolved failures can still require your decision. A report cannot grant new authority.
After a cutoff, ask Lantern to resume the exact sessions. It preserves the model and session identity. Ask to see tabs ready to close, then name the tabs you want closed. Lantern does not close its own tab.
Set choices once
Ask Lantern to use Elves onboarding to record your model choices for the lead, proposers, investigators, implementers, critics, and reviewers. It reuses those choices on later runs. A model named in your request takes priority.
Help me set my Elves team model preferences. Show the available routes once. I want a different model family for final review when one is available, and a fresh independent session in every case.
Update before using teams
Use Lantern 0.12.0 or later and Elves 2.37.0 or later. After updating, end the old Lantern chat and open a new one. Herdr does not need a restart.
A GitHub plugin install refreshes with herdr plugin install aigorahub/herdr-lantern. A linked checkout needs its own update. Preserve custom settings. Elves updates through its existing installer for the agent hosts you use.
Windows Elves team execution requires WSL2. Callback paths must resolve inside WSL2. Lantern itself supports native Windows.
Read the exact command contract
Normal requests do not require you to write callback JSON or manage credentials. The driver handles team setup and reporting.
For custom integrations, read the Elves team commands, writer lane rules, and Lantern report protocol. Registration records an actor; the existing agent launcher starts its process.