guildly

Your team

How work ships

Guildly's core promise is that agents move fast but nothing reaches your real codebase without a human saying yes. Here's the pipeline that enforces it.

The sandbox

All agent work happens on a separate copy of your code called the sandbox branch. Your main branch, the one your live product runs from, is never touched directly. If an agent has a bad day, the damage is contained to a place you haven't approved yet.

The pipeline, step by step

  1. You ask. A chat message to the manager, or an idea from the inbox.
  2. It becomes a ticket. For bigger work, the PM writes a PRD first and you approve the plan before anything is built.
  3. An engineer builds it on the sandbox, on its own branch, and opens a pull request (a packaged, reviewable change).
  4. The reviewer checks it. A separate agent whose whole job is finding problems reads the change. The builder never reviews its own work, and only the reviewer can merge into the sandbox.
  5. You review it. The ticket lands in Human Review with plain test steps. You try the result and approve or request changes.
  6. It ships. After your approval, the manager promotes the accumulated approved work from sandbox to main, in controlled batches.

What each safeguard buys you

  • Separate reviewer: a second set of eyes on every change, so obvious mistakes die before reaching you.
  • Human review: agents literally cannot mark work as done. Only your approval moves a ticket to the finish line.
  • Batched promotion: main only ever receives work that made it through every gate, so it stays deployable.

The escape hatch

Sometimes you want speed over ceremony: a typo on the live site, an urgent fix. Give an agent a direct instruction and it can act immediately, then it asks you to confirm before pushing to main. The gate is still there, it's just one question instead of a pipeline.