Choosing a mode

Every thread runs in a mode, and the mode sets how far Gentlybot goes on its own — from answer-only to a full pull request. Autonomy is opt-in at every step; nothing merges without your review.

Answer only. Touches nothing. Changes code: No
Reach for it when
  • Understanding how a flow, service, or feature works.
  • Checking whether a customer request is already possible.
  • Getting a cited answer before you decide what to do next.
What you get

A plain-language answer grounded in real sources, with citations to the files, PRs, tickets, or messages it drew from.

What it won’t do

Change any code, open a branch, or touch your repositories. It only reads.

Drafts an approach you approve. Changes code: No — until you approve
Reach for it when
  • Anything non-trivial, risky, or spanning several services.
  • Turning a fuzzy request into something engineering can weigh in on.
  • Deciding whether a change is worth doing before it’s built.
What you get

A reviewable plan: scope, the app surfaces it would touch, risks, and test ideas. You approve, edit, or push back before anything is built.

What it won’t do

Write code until you approve the plan. Approving promotes the thread to Implement.

Builds, verifies, opens a PR. Changes code: Yes — in a sandbox
Reach for it when
  • A change that’s well understood and scoped.
  • Bug fixes with a clear reproduction.
  • Work you want to see running before engineering reviews it.
What you get

A sandboxed change against your real stack — with a live preview URL, verification evidence when it’s warranted, passing checks, and a pull request for your team to review.

What it won’t do

Merge anything. The PR waits for your engineers to review and merge, exactly like any other.

Routes to the right mode for you. Changes code: Depends on the request
Reach for it when
  • When you’d rather describe the outcome and let Gentlybot decide how far to go.
  • Powering automations and triggers, where no person picks a mode per run.
What you get

Gentlybot reads the request and routes it — a question gets answered, a build request gets planned or implemented.

What it won’t do

Skip review. Whatever it routes to still ends in reviewable output, never an automatic merge.

You don’t choose a mode once and live with it. A single thread can move up the ladder as you get more confident — and the safest way to adopt Gentlybot is to start low and climb.

  1. 1

    Start in Ask

    When you’re exploring or unsure, ask first. It’s free of side effects and often the answer is all you needed. If it turns out you do want a change, you already understand the surface area.

  2. 2

    Promote to Plan

    For anything beyond a small, obvious change, have Gentlybot draft a plan. Reading a plan costs a minute and saves you from a PR that solved the wrong problem. Edit or reject it before it builds.

  3. 3

    Approve into Implement

    Approving a plan promotes the same thread to Implement — no re-explaining. Gentlybot builds against your real stack, verifies, and opens the PR. Your engineers still gate the merge.

A good rule of thumb

If you’re not sure, use Plan. It’s the cheapest way to find out whether Gentlybot understood you — you read the scope and risks before any code exists, and approving turns the same thread into the build. When you already know exactly what you want and it’s small, go straight to Implement.

Reviewing and iterating on a run