One-shot trades checkpoints for speed. You stay in Agent mode and ask Bright to research, plan, create a project, and execute in a single prompt, then review what came back instead of approving each stage. It is the right call when one person owns the whole loop and can iterate on the fly. If you want to read the research before anything is planned, use the methodical loop instead. If the result needs an independent verdict before it ships, use Forge. Open Bright →

​
Who this is for

The example is the same as the methodical loop: a small Node.js API in production that needs error tracking end to end.

​
1. Switch to Agent mode

At the bottom left of the chat input, open the mode dropdown and select Agent. Agent is the default in a new session, so you only need to switch if the selector shows Plan or Ask. Agent mode selected in the bottom-left mode dropdown Bright home screen with Agent mode ready

​
2. Send the one-shot prompt

Use the same research question, but explicitly ask Bright to research, plan, create a project, and execute:
Error-tracking one-shot prompt entered in Agent mode

​
3. Watch research start in parallel

Bright begins the way the methodical loop does:
  1. Explorer reviews your repo and stack (framework, error handling today)
  2. Researcher compares error-tracking services on setup effort and free tiers
  3. Both tracks run in parallel, then Bright recommends a fit
Thought and work feed with research activity running on the one-shot prompt Agent activity rows showing tool calls during the one-shot run
Unlike Ask-only research, Bright doesn’t stop after the recommendation. In Agent mode it continues into project creation, issues, and documents.

​
4. Review the project, issues, and documents

Bright summarizes what it created: an error-tracking project with issues for the Sentry setup, SDK wiring, release tagging, and the research that already completed. Error-tracking project Overview tab with its summary, context, and status in the Plan view To open it in the UI:
  1. Click Plan in the top navigation
  2. Under Projects in the left panel, select All projects
  3. Open the error-tracking project from the list
The Overview tab shows the description; the Issues tab lists the issues across stages. Switch to Board view to see the same issues grouped by status column; the board and the Timeline are covered in the methodical loop.
Bright often suggests an implementation order (account and config first, then SDK wiring, then verification). Follow that order so the DSN exists before code tries to initialize the SDK.
The chat scrolls away; the work doesn’t. What Bright created during the session (the project, its issues, and its saved documents) stays in the workspace, so the reasoning is still there the next time anyone picks this up. Open Docs in the top navigation. In this demo run, Bright saved one artifact: an apply-it-yourself guide for the Sentry setup, with the verified API names for the current SDK, which Node versions need which install line, and the wiring steps for Express, Fastify, or a plain HTTP server. Weeks later, whoever picks up the SDK issue starts from that guide instead of re-running the research. Docs home listing the saved error-tracking guide The saved error-tracking guide document open Keep the guide even after the work ships. It records how the setup was done and what was ruled out, the fastest way to retrace a step or bring the next person up to speed.

​
5. Implement and open a PR

Return to Work (the chat). Bright may ask whether you want to navigate to the project or start implementing. If you’ve already reviewed the issues, tell Bright to implement what it can:
Bright typically owns the engineering issues and waits on account and config work only you can do. Bright handing off the operator setup steps and starting engineering work Goal and task panel tracking the error-tracking setup Example env var (the name comes from the plan):
With repository access granted, Bright connects to GitHub, creates a branch, updates the codebase, and opens a pull request. Your job is review, approve, merge. The captured run stayed prepare-only: Engineer built and verified the guide in the sandbox and left the repository untouched, which is why the screenshots above show no branch or PR.
If Bright can’t reach the repo (access or 404), connect GitHub or grant repository access, then retry.

​
One-shot, the methodical loop, and Forge

​
Good to know

  • One-shot creates the project, issues, and documents before you have reviewed them. Read the project before you tell Bright to implement.
  • Account and config steps stay with you. Bright reports which ones and continues with the engineering issues it can do.
  • The saved guide is a document like any other: it stays in Docs after the session is archived.

​
Next step

Brief the specialists so their work stands up to scrutiny in Use specialists.