Recorded from a live gateway session

The workbench, one feature at a time

AgentEvolver ships a browser workbench that talks to the Python Gateway over a WebSocket. Eleven short clips below, one per feature — the layout, each of the four workspaces in turn, the capability catalogue, the session panels, the machines, and the model registry.

01-overview.mp4
01

Three panes, one live connection

Projects and navigation on the left, the task surface in the middle, session state on the right. The header carries the gateway status — this workbench is a thin client over a running Python process, not a mock.

  • Projects — every session you have opened, grouped by age
  • Views — switch the middle pane between four workspaces
  • Capabilities — what this session is allowed to use
  • Connected — a live WebSocket to ws://…/ws
02-views.mp4
02

Four workspaces over one session

The same session, seen four ways. Switching a view does not start a new run — the workspace, the files, and the agent history stay put underneath.

  • Chat — describe a task and watch it get worked
  • Canvas — a node editor with a component palette: inputs, flow control, agents, data, processing
  • Code — an editor over the session workspace
  • Science — a Jupyter kernel on the same files, with a JupyterLab escape hatch
03-canvas.mp4
03

Wire a flow instead of describing one

The Canvas is a node editor for the times a picture beats a paragraph. Components are dragged in from a categorised palette and joined into a flow you can save and reuse — a human-facing library, separate from the agent-facing workflows.

  • Input & Output — where a flow takes in and hands back
  • Flow control — map, branch, loop, reduce, verify, checkpoint
  • Agents and Data — delegation and dataset steps as nodes
  • Processing — select, filter, sort, split, regex over records
04-code.mp4
04

A real editor, on the session's own files

Code opens an OpenVSCode server rooted at the session workspace — the same /workspace the agent writes into. The first launch boots the editor container, so it takes a moment; after that it is just VS Code in a tab.

  • Explorer — the session workspace, nothing else
  • Full editor — search, source control, extensions, terminal
  • Per-session container — destroyed with the session
05-science.mp4
05

A kernel you and the agent share

Science attaches a Jupyter kernel to the very files the agent is working on. You can poke at a result the moment it lands, and the agent can run a cell whenever it needs one — the first boot takes about ten seconds, then cells run in milliseconds.

  • Notebook — run cells, interrupt, restart, save as .ipynb
  • Compute — live GPU, CPU, memory and disk for the session host
  • JupyterLab — an escape hatch to the full interface
03-capabilities.mp4
06

A catalogue of everything the agent may use

Each registry in the framework surfaces here as a browsable, searchable list, and what you tick is what the session is handed. The counts beside each entry are live — they grow as the evolution loop registers new components.

  • Skills and Tools — specialist workflows and callable actions
  • Agents — specialists available for delegation
  • Connectors — external data sources and services
  • Environments, Workflows, Commands, and saved Canvas flows
04-composer.mp4
07

Start from a card, or just say it

Four starting points cover the usual asks — review, plan, explain, investigate — and the composer underneath takes anything else. Files can be attached to the session before the run begins.

  • Starter cards — review, plan a feature, explain the architecture, investigate
  • Free-form prompt — Enter to send, Shift+Enter for a newline
  • Attach files — staged into the session workspace
05-panels.mp4
08

Files, activity, and the raw event stream

The right pane answers "what is it actually doing". Each session gets its own initially empty workspace — only staged inputs and files produced during that session appear there, never a copy of your checkout.

  • Files — browse and open anything in the session workspace
  • Activity — the agent timeline, step by step
  • Inspector — the raw gateway events behind that timeline
06-machines.mp4
09

Give the agent a screen, or a second host

Some work needs a GUI rather than a shell. Local environments ship their own VNC-capable runtime and open as a live view in the browser; remote machines are reached over SSH instead.

  • Browser — headful Chrome, driven over noVNC
  • Computer — a full desktop for GUI automation, over noVNC
  • Remote machines — SSH hosts that open a shell
  • Deployments — services the session has published
07-models.mp4
10

One catalogue for every provider

Providers are registered centrally, and every model declares what it can do — so the orchestrator can pick a model that actually supports the call it is about to make.

  • Per-model flags — tool use, vision, streaming
  • Grouped by provider — Anthropic, Google, OpenRouter and friends
  • Add a model — register a new endpoint without a redeploy
08-theme.mp4
11

Dark or light, local or remote

The theme is remembered across sessions, and the endpoint is not baked in: point the workbench at a gateway on another host, or supply a token when the gateway requires one.

  • Theme — light and dark, remembered per browser
  • Connection — change the gateway endpoint at runtime
  • TokenAGENTEVOLVER_GATEWAY_TOKEN for protected gateways

Run this yourself

Both halves — the Python Gateway and the Vite dev server — start together inside the base sandbox. One container, two processes.

scripts/run-in-sandbox.sh -- scripts/serve-ui.sh

Then open http://127.0.0.1:5173. The sandbox runs with --network host, so the container loopback is the host loopback; the UI connects to ws://127.0.0.1:9876/ws by default.

See the rest of the framework

The workbench is one surface on a registry-driven core that grows its own tools, skills, and agents.