Processes and Logs

Workbench brings service processes and logs into the same workspace as the guided coding session.

Run local services

Many real playgrounds need more than file edits. A project may have a web server, worker, database migration, sync command, or test process that has to run while you build.

Workbench is designed to show those processes as part of the session:

• What is currently running.
• Which command started it.
• Whether the process exited or failed.
• What needs to be restarted after a code change.

Watch runtime output

Logs are part of the learning signal.

Instead of scattering output across separate terminal tabs, Workbench keeps runtime information close to the current task. That makes it easier to connect an error, warning, or successful startup message with the step you are working on.

Recover from failures

When a process fails, use the log output as input for the next agent turn.

Ask the agent to explain the failure, patch the relevant code, or rerun the local flow after the fix. Workbench is meant to keep that loop visible so you can see why the next action is justified.

Keep the session grounded

The important rule is simple: process state and log state should stay attached to the same project context as the task and code state.

That is the difference between a guided build and a chat transcript that happens to edit files.

If you have questions, visit our Discord