Use this loop when the work is worth checkpoints: you want to read the research before anything is planned, and read the plan before anything is created. Each mode widens what Bright may change, and you decide when to widen it. The example is a real engineering task, adding error tracking to a small Node.js API, and it runs through all three modes in one session. Open Bright →

​
Ask: research without changing anything

Ask mode is for research and answers only. Bright won’t create issues, documents, or plans while you’re here. You run a small API in production, and you hear about failures from users before you see them in logs. Before writing any code, you want an engineering answer: does a dedicated error-tracking service earn its keep, and which one fits a small project? Start a new session, switch to Ask, and paste:
Error-tracking research prompt typed into the Ask-mode chat input Expand the thought and work section. Bright clarifies objectives, then typically:
  1. Assigns an Explorer to inspect your repo and stack (framework, error handling today)
  2. Assigns a Researcher to compare error-tracking services on setup effort and free tiers
  3. Runs those tracks in parallel
Thought and work feed with the research track running For this example, Bright lands on a simple call:
  • A dedicated service beats logs alone for production failures: grouped errors with stack traces and source context, release tagging, and alerts when a new error class appears
  • Sentry fits a small project: free tier plus paid tiers (see sentry.io/pricing) and a maintained Node.js SDK
  • Skip self-hosting for now. It is operationally heavier than the problem justifies at this size
Ask-mode answer with the free-tier comparison table and recommendation
Bright also flags tradeoffs: what you give up by not self-hosting, and when plain structured logging is still the right answer.
The recommendation comes with a wiring path you can follow by hand or hand to the plan:
1

Create the Sentry project

Create your org and project in the Sentry dashboard, and note the DSN.
2

Add env vars

Store SENTRY_DSN server-side only.
3

Install the SDK

Add the Sentry Node SDK and wire the error handler middleware.
4

Verify with a test error

Trigger one handled test error and confirm it shows up with a stack trace.
Keep the DSN server-side. Scrub secrets from anything you attach to an error event, and alert on new error classes, not every occurrence.

​
Plan: turn research into a plan

Once the direction is clear, switch to Plan. Bright can organize work, set goals, and map steps, but it still won’t mutate your workspace until you move to Agent. Confirm the decisions and request a plan:
Plan-mode Sentry rollout plan with the out-of-scope list A good plan includes three things:
  • A clear issue breakdown
  • Key decisions, so the team shares the same context
  • An out of scope list, so work doesn’t quietly expand
For this example the breakdown is:
  1. Create the Sentry org and project, note the DSN
  2. Add SENTRY_DSN to your deployment environment
  3. Install the Sentry SDK and wire error-handling middleware
  4. Tag releases so errors map to the code that shipped them
  5. Trigger a test error and verify the stack trace end-to-end
In software teams, alignment on what not to build is as important as the work itself. Capture those boundaries in the plan before anyone starts executing.

​
Agent: create the project and ship the work

Agent mode gives Bright full access: create issues, docs, and projects, run sandbox commands, change the workspace, and generate code. Switch to Agent and send:
Bright creates the project and issues. Open the project link; research from Ask mode usually shows up under Documents. Error-tracking project with its issues in the Plan view

​
Watch the work move

Open the project and switch its issues to Board view. Each column is a status (Triage, Backlog, Planned, In Progress, Review, Done, Cancelled) and each card is an issue. Change an issue’s status and its card moves to the matching column, so the board shows what’s active, what’s waiting, and what’s done without opening a single issue. The error-tracking project's issues grouped into status columns in Board view The toggle beside it switches back to List view, the same issues with status, priority, and assignee inline. The workspace-wide Issues view carries the same pair, so you can watch one project’s board or every project at once. For the longer view, Timeline in the Plan section draws each project as a bar with its status, start and target dates, and progress. A project with no dates set shows as not scheduled; the project’s Start date and Target date fields drive the bar. Bright’s timeline tracks projects, not individual issues; there’s no per-issue Gantt today. The Issues and Projects pages cover statuses, filters, and views in depth.

​
Who does what

Bright will often split ownership: Bright's message splitting error-tracking work between the operator and engineering

​
Hand off engineering work

Expand the work section to watch the loop: set a goal, list actions, read and inspect, request repo access if needed, implement, verify. Engineer agent starting on the SDK integration work Bright connects to GitHub, clones the repo, works on a branch, pushes changes, and opens a pull request. Your job is review, approve, merge. Bright explaining that it will not touch the repository without an explicit yes
If you see a repository access or GitHub 404-style message, connect GitHub (or grant repo access) and retry. Bright can’t implement or push until the repo is reachable.

​
Review the result

The loop ends where it started: with evidence. Open the pull request, read the diff, and check the verification Bright ran. Then trigger one real error and confirm it lands in the Sentry dashboard with a stack trace. If the dashboard is quiet while your API is failing, the wiring isn’t done; send Bright back to the issue with what you saw.

​
Good to know

  • Plan mode never writes. The plan you review exists only in the session until you switch to Agent and approve it.
  • Bright’s timeline tracks projects, not issues. Give a project Start and Target dates or it shows as not scheduled.
  • The account and config steps (creating the Sentry project, adding the DSN) stay with you. Bright will tell you which ones and wait.

​
Next step

Want the same outcome with fewer mode switches? Send everything in one prompt with the one-shot workflow.