Select how the graph should run before generating it. In multi-agent mode, the planning agent proposes reusable agents with names, roles and instructions, then assigns graph stages to them.

The generated preview shows the agents that will be created and the agent selected for every node. You can review and change those assignments in the graph designer before saving or running the workflow.

Manage empty workspace folders from the browser, with safer path handling and clearer acknowledgements. Graph and task timeouts are also better suited to longer agent runs.

New to Agent Graphs: describe what you want in plain language — "Every weekday at 09:00, inspect local changes in parallel, then combine them into a concise engineering brief" — and get a draft graph back for review before it's created. Attach a Markdown file or browse the workspace for extra context, and pick which agent does the planning. It's read-only: nothing runs, no task is created, until you review the draft and confirm it.

Approve a one-time pairing request in your browser and the Bridge saves its connection locally. It also works when the Bridge is running on another machine.

Use the models you choose through OpenRouter. The Bridge can read, write and search files in the task workspace, and records the task cost in its activity log.

Run local models with Ollama. No API key is needed, and your agent can work with the files already on your machine.

Every follow-up has its own activity log instead of being appended to the previous run. The Bridge carries earlier context forward, and safely starts a fresh Claude session if the original one is no longer available.

Follow-up intents dispatched to Claude Agent SDK agents now resume the original conversation session instead of starting a new one. The session ID is saved to disk when a task completes, so it survives Bridge restarts — on follow-up, Bridge reads it back and passes it to the SDK for full conversation history resumption. A fresh dispatch (e.g. RERUN) always clears the cached session, so it never accidentally resumes a stale one.

Every follow-up now writes a numbered input file to the task's input folder before dispatching, with the agent prompt automatically augmented to point at the expected output file. For providers without native session history — Codex, Hermes CLI/ACP, Gemini, Copilot — the prior run's agent log is prepended as context, so the agent knows what was already done. Providers with native sessions (Claude Code, Claude Agent SDK) skip this since the history is already available.

Tasks can now be cancelled from the CTRL NODE UI while they're still running, instead of having to wait them out. Bridge signals the active provider to stop immediately — a clean SIGTERM (escalating to SIGKILL after 3 seconds if needed) for CLI-based providers, and an AbortController or cancel-flag for SDK-based ones. Works the same way across every supported provider.

When an agent hits a permission prompt it can't auto-approve, the task no longer just stalls or cancels silently — it notifies the UI that it's waiting for input, and you can respond directly from the task view. Claude Code supports this natively today; ACP-based providers (Copilot, Gemini, Hermes ACP) log the prompt for visibility now, with full interactive response support planned for a future release.

Two additional Claude models are now selectable when configuring an agent: claude-fable-5 and claude-sonnet-5, alongside the existing lineup. Pick them from the model combobox on any Claude-type agent the same way you would any other supported model.

The Bridge now supports Hermes as a native provider via the ACP protocol (hermes acp). Hermes is fundamentally different from every other supported provider: it maintains a persistent conversation thread with SQLite-backed memory across tasks. Skills the agent auto-generates accumulate over time. When you dispatch a follow-up task, Hermes already knows what happened in the previous one — no re-prompting required. Each agent maps to its own isolated Hermes profile directory (~/.hermes/profiles/{agentId}/) with its own config.yaml (model selection), SOUL.md (identity), and credential symlinks — agents with different models or roles never share state.

Tasks and routines now support a Work Directory mode alongside the existing output-only mode. Instead of generating files into an isolated output folder, the agent operates directly inside a folder you choose — a full repository, a project directory, or any subtree on your Bridge machine. You can narrow its focus to specific files or subfolders using the built-in path picker, or leave it open to let the agent explore the entire working directory. The agent reads existing code, edits files in place, and reports back what changed — no manual file staging required.

The Bridge binary is now ctrlnode[.exe] (previously ctrlnode-bridge). Run ctrlnode --setup to configure it interactively: the wizard asks for your workspace root and your pairing token (from Settings → Bridge in the app), saves them to <workspace>/.ctrlnode/.env, and persists BASE_PATH as a user environment variable — no manual file editing required. On subsequent runs the Bridge prints which .env it loaded and reminds you of --setup if the token is missing. Available for Windows x64, Linux x64 (AVX2 and baseline), and macOS Apple Silicon.

The CTRL NODE scheduler runs in the cloud and triggers your Bridge at the exact time you configured — whether you're at your desk, away from your computer, or the lid is closed. Supported presets: Hourly Daily Weekdays Weekly plus full custom cron expressions. Timezone-aware with UTC offset configuration.

When a routine fires, the Bridge dispatches the instructions to your configured agent — Claude, Copilot, Gemini, or any other connected provider. The agent runs in your local workspace, reads your project files, and writes its outputs directly to disk. Reports, summaries, generated code, logs — anything your agent produces stays on your machine, git-trackable and immediately usable.

Every run is logged permanently: status (Running, Done, Cancelled), trigger source (scheduler or manual), start time, duration, and the complete terminal output stream. You can open any historical run and read everything the agent printed. File artifacts produced during the run are listed and linked. The history panel is accessible from the routine detail page and from the run detail view.

Files written by the agent during a routine run are detected, catalogued, and attached to the run record. Each artifact shows its filename, size, and write time. This gives you a clear audit trail of what each scheduled execution produced — especially useful for recurring reports, generated documentation, or code changes committed by the agent.

Don't wait for the scheduled time. Hit RUN NOW from the routine detail page to trigger an immediate execution. The run is logged in history exactly like a scheduled run, with trigger source set to "manual". Useful for testing new instructions, backfilling a missed run, or on-demand reporting.

Pause a routine to stop it from firing without deleting it — useful during vacations, incident response, or while you're iterating on the instructions. Resume it at any time and the scheduler picks up the next scheduled slot. Archive a routine to remove it from the active list while preserving the full run history for audit purposes.

v2.0 added native Bridge support for GitHub Copilot via the ACP protocol, Google Gemini CLI via browser-login or API key, OpenAI Codex CLI with per-agent sandbox isolation, Cursor's headless background agent API via gRPC, and OpenClaw via gateway token. Every provider is a first-class citizen: dedicated env var documentation, provider-specific model lists, and individual setup guides at /start/{provider}.

A new Team page shows every configured agent as a card with live status: ONLINE (idle, ready), RUNNING (executing a task with progress bar), OFFLINE, or FAILED. Status updates arrive in real time over SignalR. The card shows the provider badge, model name, last heartbeat, and a link to the agent's current task if one is running.

The Dashboard gives you an instant overview of your org's activity: active pipeline runs with step progress, recent task completions by agent, a live event stream showing Bridge notifications, and aggregate stats (total runs, tasks done, agents online). All widgets update in real time without refreshing the page. Designed as the first screen you open to understand the state of your automation environment.

When the Bridge connects it queries each provider for its available models and sends the map to CTRL NODE via a new WebSocket message. The agent creation and edit forms show a searchable MODEL dropdown populated from the live list. Start typing to filter, press Enter or click to confirm. If no model is entered the provider uses its default. The list is scoped to the selected provider when one is detected.

Every agent now has a dedicated workspace on the Bridge machine. An AGENTS.md file — seeded from templates stored in the database and customisable per agent — is injected into every task so the agent knows its role, constraints, and available tools. Re-run the Migrations console app after editing templates to propagate changes to all agents in your org.

The Bridge runtime is fully open source under the MIT license and distributed as pre-built binaries for Windows x64, Linux x64 (AVX2 and baseline), and macOS Apple Silicon via GitHub Releases. No build step required — download the binary, set your environment variables, and run. The CTRL NODE control plane (API + web app) remains hosted, but the execution layer is yours to audit, fork, and extend.

The Bridge is a single binary (no dependencies) that runs on any machine you control — laptop, home server, cloud VM, or corporate workstation. On startup it establishes a persistent WebSocket connection outbound to CTRL NODE, authenticated by a pairing token you generate in the web app. No inbound ports, no firewall rules, no VPN, no proxy configuration. Behind NAT or inside a restrictive corporate network? It just works. The Bridge reconnects automatically on disconnect and queues commands during offline windows.

Design complex automations on an infinite canvas: drop agent nodes onto the stage, connect their inputs and outputs to form a directed acyclic graph, and assign a different agent to each node. When you hit Deploy, the Bridge activates the workflow and begins orchestrating tasks in dependency order — a node doesn't start until every predecessor has completed and its output file is available as the successor's input. Every step streams its output back to the browser in real time.

The Kanban board is the lightweight alternative to workflows: create a task, write the instructions, assign it to any online agent, and hit Run. Tasks progress through four columns — BACKLOG, INBOX (queued to the Bridge), ACTIVE (agent is executing), DONE — with real-time status updates pushed over SignalR. Each task gets its own dedicated workspace and output panel so you can read the agent's terminal output without leaving the board.

Every byte the agent writes to stdout is forwarded over the Bridge WebSocket and displayed in the browser in real time — no polling, no buffering delays. The output panel renders ANSI colour codes, handles long lines gracefully, and auto-scrolls as new output arrives. You can watch a multi-hour research pipeline run step by step from any device on any network, with no connection to your local machine other than the Bridge's single outbound socket.

Each agent on your Bridge gets its own directory in the local filesystem. Files created during a task persist between runs, allowing agents to build up context, maintain state, and reference prior outputs. Workflow nodes that feed into each other share files via a structured input/output manifest: predecessor output files are automatically staged as successor inputs before the next node starts. The workspace is a normal directory on disk — you can open it in your editor, commit it to git, or share it with other tools.

CTRL NODE is built multi-tenant from the ground up: every database query is scoped to the caller's organisation via PostgreSQL row-level security, enforced by the OrganizationMiddleware on every API request. Authentication uses Clerk JWTs in production and a dev-bypass mode for local development. No data from one organisation can ever be read by another — isolation is enforced at the database layer, not just the application layer.