Start with an outcome, not a queue of instructions
Give Forge the outcome, the repository, the constraints, and the evidence that would make the result trustworthy. A lead agent can then turn that brief into bounded work instead of guessing at a sequence of disconnected edits.
The project board remains the coordination record. Scope, acceptance criteria, dependencies, safety boundaries, and required proof stay attached to the work, so a new agent can recover the intent without relying on a private chat transcript.
- Name the user-visible outcome and the source of truth.
- State what must not change, especially production, data, and authorization boundaries.
- Define proof as observable behavior: a command result, browser path, deployment readback, or human acceptance.
Let the project lead shape the work
The project lead is the orchestration layer. It maps the system, identifies decisions that need a human, splits independent work, and keeps the task tree coherent as discoveries change the plan. It should not manufacture certainty or silently expand authority.
Material product direction stays human-owned. For example, a lead can prepare several grounded interface directions, explain the tradeoffs, and record the selected direction. It should not choose a brand-defining design on the user's behalf and call that autonomy.
- 01
Brief
Capture the goal, boundaries, dependencies, and proof.
- 02
Plan
Map the system and place decision gates with their owners.
- 03
Dispatch
Give independent specialists bounded ownership and shared context.
- 04
Integrate
Reconcile changes, conflicts, and cross-cutting behavior.
- 05
Verify
Run automated gates, browser QA, and any required live checks.
- 06
Ship
Merge or deploy only when the authorized boundary and evidence permit it.
Parallelize only genuinely independent work
Multiple agents are useful when their responsibilities can proceed without competing for the same files, decisions, or runtime state. One specialist might research the current API contract while another prepares isolated tests. A final integrator then evaluates the combined result against the original acceptance criteria.
More agents do not automatically mean faster work. Overlapping agents create duplicated discovery, merge conflicts, and noisy review. Forge works best when the lead defines explicit ownership, keeps the active team small, and waits for deterministic checks before spending another model call on review.
Schedule recurring work without surrendering control
Forge can support scheduled and repeatable workflows through tracked automations. The useful pattern is a narrow trigger, a bounded task packet, and a clear escalation rule. For example, inspect a known health signal, prepare a patch when the evidence is conclusive, and stop for review before a high-risk release.
Scheduling should never invent permissions, credentials, fixtures, or production approval. An unattended run can collect evidence and advance reversible work within its packet; consequential actions still respect the declared ship boundary.
- Use recurrence for stable, repeatable work, not ambiguous product decisions.
- Keep attempt caps and latency budgets explicit.
- Require a durable result: evidence, a reviewable change, or a clearly reported blocker.
Treat completion as a ladder
Code written, tests passing, pull request merged, production deployed, and user acceptance are different states. Forge keeps those gates separate so the team cannot substitute an easy signal for the proof the work actually requires.
The practical result is a development loop you can audit. You can see who owned each step, which checks ran, what changed, where approval was required, and why the work is or is not ready to move forward.