The Dolt Workbench is our newest product here at DoltHub. A workbench is a graphical user interface that allows you to connect to and run queries on a database. Popular workbenches are Datagrip, DBeaver, and TablePlus. Datagrip is a paid product while DBeaver and TablePlus are free, though DBeaver has a paid Pro option.

The Dolt Workbench is Dolt’s entry into this category. The Dolt Workbench is free and open source. It is a desktop application available in the Mac and Windows app stores, but you can also download it directly from GitHub. The Dolt Workbench works with Postgres and MySQL compatible databases but it really shines when used with Dolt. Dolt’s version control functionality is cleanly exposed in the Dolt Workbench’s graphical user interface. Switch branches. View the commit log. See diffs between branches before merging. The best way to show off Dolt’s version control features is through a demo with the Dolt Workbench.

Many people reading this will be familiar with Integrated Development Environments (IDEs) like Visual Studio Code, XCode, or Eclipse. IDES are to code what Workbenches are to databases. One of the major innovations in IDEs in the past year has been the integration of generative large language models (LLM). This began as “chat to code” and has evolved into “agent mode”, where the IDE produces code to solve a natural language prompt. The most popular IDE with integrated LLM support is Cursor.

Is there a workbench with agent mode? Not yet. Why not? When will there be one? This article attempts to answer those questions through an illustrative example using the Dolt Workbench.

What is Agent Mode?#

If you haven’t tried Cursor yet, I highly recommend it, even if it is just to see what all the fuss is about. Cursor looks like a normal IDE with a chat window bolted onto the right side. The chat window is connected to an LLM of your choice. Below you can see I opened the Dolt repository and asked the LLM to explain the code to me.

Explaining things is cool, but where Cursor really shines in when you ask the LLM to make changes to your code. I reviewed how well Cursor performed at various coding tasks in an earlier blog. Long story short, LLMs can write code and work especially well in agent mode. When the LLM modifies code, the Cursor IDE helps you manage the edits. The IDE shows you what changed and offers the option to accept or rollback changes, along with other helpful features.

As I mentioned, the integrated LLM functionality has evolved from chat to code to agent mode over the past year. When Cursor first rose to popularity, the chat to code mode of operation was what I would describe as single prompt. Tell Cursor to do something. Cursor makes changes. You inspect the result. Rinse. Repeat. Cursor would not operate for more than a few seconds before requiring more of your input. The big change in the past few months is agent mode. In agent mode, Cursor adds looping on multiple LLM calls until a goal is achieved. This looping allows Cursor to operate for minutes without human interruption and often produce working code on the first try for moderately scoped prompts. Agent mode is now the default.

Of course, operating independently for minutes often obviates the need for an IDE in the first place, giving rise to popular command line coding agents like Claude Code and Codex. Cursor even has its own command line agent now.

Coding agents are awesome. They work. They work so well that using them has its own slang: “vibe coding”.

Agent Mode in a Workbench#

It seems obvious to me that workbenches would be the next interface to get agent mode. Take a workbench, bolt an LLM-connected chat window on the right, and have the agent perform read and operations on your database based on the prompt. As far as I can tell, this hasn’t happened yet. I think the main reason this hasn’t happened is that agents make mistakes. In general, databases are not resilient to mistakes. If the agent decides to drop a table, your only option is to restore from a backup. Adding this functionality to a workbench intended to be used with normal databases would be considered folly.

This is where Dolt comes in. Dolt’s version control functionality makes it perfect for agents. Any change can be instantly undone. Moreover, you can have the agent work on a branch or clone isolating the edits, just like you do with code in Git. The agent or a human can inspect the diff to see what it changed. Dolt even has built-in test functionality to allow the agent to verify its changes and work for longer without interruption.

The Dolt Workbench is a perfect place to add agent mode. Stay tuned agent mode in the Dolt Workbench is on its way.

Examples#

Unfortunately, this is not an announcement blog. But we can approximate what agent mode in the Dolt Workbench will look like with Claude Code in a terminal.

This example will work with the post-no-preference stocks database. This database contains US stock market data. It’s big enough, approximately 2GB, to not be a toy example. I will first show how agent mode would work in a MariaDB database with no version control and then show how the experience is much better using Dolt, the world’s only version-controlled database.

MariaDB#

To prepare for this demo, I dumped the contents of the stocks Dolt database using dolt dump and imported the results into my MariaDB database using mysql -h 127.0.0.1 -P 3300 -u root < doltdump.sql. Here is the result in the Dolt Workbench.

I then opened a new Claude Code session and asked it to explain what was in the database.

> can you connect to the mysql compatible database on port 3300, 
specifically the stocks database and tell me what is in it? 

⏺ I'll connect to the MySQL-compatible database on port 3300 and explore the
   stocks database for you.

⏺ Bash(mysql -h 127.0.0.1 -P 3300 -u root -D stocks -e "SHOW TABLES;")
  ⎿  Tables_in_stocks             
     dividend
     ohlcv
     … +4 lines (ctrl+o to expand)

⏺ Bash(mysql -h 127.0.0.1 -P 3300 -u root -D stocks -e "DESCRIBE dividend;
      DESCRIBE ohlcv; DESCRIBE split; DESCRIBE symbol;")
  ⎿  Field	Type	Null	Key	Default	Ex
     act_symbol	varchar(64)	NO	PRI	NULL
     ex_date	date	NO	PRI	NULL
     … +29 lines (ctrl+o to expand)

⏺ Bash(mysql -h 127.0.0.1 -P 3300 -u root -D stocks -e "SELECT 'symbol' as
      table_name, COUNT(*) as row_count FROM symbol UNION ALL SELECT 'ohlcv',
      COUNT(*) FROM ohlcv…)
  ⎿  table_name	row_count         
     symbol	21836
     ohlcv	25968113
     … +4 lines (ctrl+o to expand)

⏺ Bash(mysql -h 127.0.0.1 -P 3300 -u root -D stocks -e "SELECT * FROM symbol

⏺ Bash(mysql -h 127.0.0.1 -P 3300 -u root -D stocks -e "SELECT * FROM symbol
      LIMIT 3; SELECT * FROM ohlcv LIMIT 3; SELECT * FROM dividend LIMIT 3;
      SELECT * FROM split…)
  ⎿  act_symbol	security_name	listing_exchange	market_category	is_etf	rd_
     lot_size	is_test_issue	financial_status	cqs_symbol	nasdaq_symbol	is_nex
     t_shares	last_seen
     … +20 lines (ctrl+o to expand)

⏺ The stocks database contains comprehensive historical stock market data
  with 4 tables:

  Tables Overview

  1. symbol (21,836 rows)

  Stock symbol metadata and company information:
  - Primary Key: act_symbol
  - Fields: security_name, listing_exchange, market_category, is_etf,
  round_lot_size, is_test_issue, financial_status, cqs_symbol,
  nasdaq_symbol, is_next_shares, last_seen
  - Example: Agilent Technologies (A), Alcoa (AA), various ETFs

  2. ohlcv (25,968,113 rows)

  Daily price and volume data (Open, High, Low, Close, Volume):
  - Primary Key: date + act_symbol
  - Fields: date, act_symbol, open, high, low, close, volume
  - Date Range: Starting from 2011-01-03
  - Purpose: Historical trading data for technical analysis

  3. dividend (458,845 rows)

  Dividend payment records:
  - Primary Key: act_symbol + ex_date
  - Fields: act_symbol, ex_date, amount
  - Purpose: Tracks dividend distributions over time

  4. split (3,181 rows)

  Stock split information:
  - Primary Key: act_symbol + ex_date
  - Fields: act_symbol, ex_date, to_factor, for_factor
  - Example: AA had a 1-for-3 reverse split (to_factor: 1, for_factor: 3)
  - Purpose: Tracks stock splits and reverse splits for price adjustment

  This is a comprehensive financial database containing over 26 million
  records of historical stock data, covering thousands of symbols with their
   associated corporate actions (dividends and splits).

So far, so good. Claude can connect to and read from a MariaDB database to explain its contents to you. This is a cool use of AI but does not fully capture the power of agents. Coding agents can write code. Can they also write data? Let’s see.

We’re going to ask Claude to imagine DoltHub IPO’ed under symbol DOLT three weeks ago and insert the relevant data into the database. It’s my blog article. Allow a man to dream.

> connect to the mysql compatible database on port 3300 as user root now 
password, specifically the stocks database. please imagine DoltHub, symbol 
DOLT, IPOed three weeks ago. Insert the relevant data into the database. 

⏺ I'll connect to the MySQL-compatible database on port 3300 and insert data
   for DoltHub's IPO. Let me first explore the schema to understand the
  table structure.

⏺ Bash(mysql -h 127.0.0.1 -P 3300 -u root stocks -e "SHOW TABLES;")
  ⎿  Tables_in_stocks             
     dividend
     ohlcv
     … +4 lines (ctrl+o to expand)

⏺ Bash(mysql -h 127.0.0.1 -P 3300 -u root stocks -e "DESCRIBE symbol; DESCRIBE
      ohlcv; DESCRIBE dividend; DESCRIBE split;")
  ⎿  Field	Type	Null	Key	Default	Ex
     act_symbol	varchar(64)	NO	PRI	NULL
     security_name	text	YES		NULL
     … +29 lines (ctrl+o to expand)

⏺ Now I'll insert data for DoltHub's IPO. The IPO was three weeks ago
  (October 22, 2025). I'll insert the symbol information and daily trading
  data from the IPO date through today.

⏺ Bash(mysql -h 127.0.0.1 -P 3300 -u root stocks << 'EOF'
      -- Insert DoltHub symbol information…)
  ⎿ status                                                                 
    Data inserted successfully!
    WARNING: option --ssl-verify-server-cert is disabled, because of an ins
    ecure passwordless login.


⏺ Perfect! Let me verify the data was inserted correctly:

⏺ Bash(mysql -h 127.0.0.1 -P 3300 -u root stocks -e "SELECT * FROM symbol WHERE

⏺ Bash(mysql -h 127.0.0.1 -P 3300 -u root stocks -e "SELECT * FROM symbol WHERE
      act_symbol = 'DOLT'; SELECT COUNT(*) as trading_days, MIN(date) as
      ipo_date, MAX(date)…)
  ⎿  act_symbol	security_name	listing_exchange	market_category	is_etf	rd_
     lot_size	is_test_issue	financial_status	cqs_symbol	nasdaq_symbol	is_nex
     t_shares	last_seen
     … +5 lines (ctrl+o to expand)

⏺ Successfully inserted DoltHub IPO data into the stocks database!

  Summary:
  - Symbol: DOLT
  - Company: DoltHub Inc.
  - Exchange: NASDAQ
  - IPO Date: October 22, 2025 (3 weeks ago)
  - IPO Price: $25.00
  - First Day Close: $30.25 (21% pop)
  - Current Price: $31.00 (as of today, Nov 12)
  - Trading Range: $28.00 - $32.50
  - Trading Days: 16 days of data inserted

  The data includes realistic IPO characteristics:
  - Strong first-day opening with high volume (15.5M shares)
  - Initial volatility settling down over subsequent weeks
  - Volume decreasing as the stock stabilizes
  - Currently trading above IPO price with positive momentum

Claude seems to have been able to complete the task. However, the state looks unchanged in the workbench upon first glance.

This is where you should be starting to see the power of version control and IDEs for auditing the changes an agent makes. The Cursor IDE makes it obvious what code the agent modified. Of course, I can start making SQL queries to inspect the new state of my MariaDB database. Let’s find the DOLT row in the symbol table.

And then let’s check the ohlcv table to see the daily statistics.

It looks like the data is inserted correctly, but is this all the agent changed? How do I roll back if I don’t like this change? Should this have been inserted into the main copy of the database in the first place? Letting an agent make writes to your MariaDB database directly is probably not a good idea. Agents need version control.

Dolt#

Now, let’s do the same thing with Dolt. You can immediately spot the improved experience in the Dolt Workbench. Like changed files in your IDE, the left navigation tells you what tables the agent changed. I left the Claude terminal in the screenshot so you could get an idea of how agent-mode in the Dolt Workbench will look.

If you want to see what exactly changed, you can click on the “Uncommitted Changes.” link.

I can see that Claude inserted 16 rows into the ohlcv table and one row into the symbol table. Clicking on each table gives me a diff of exactly what the agent changed. Unlike MariaDB, I don’t need to guess what the agent did. Dolt tells me exactly what the agent changed. Moreover, Dolt produces these changes instantly even on the 26 million row ohlcv table. Dolt is built from the storage engine up to provide version control functionality at scale.

Moreover, if I don’t like what the agent did, I can quickly and easily roll back to the previous committed change. A simple call dolt_reset('--hard') puts the database back in an unmodified state.

Of course, I could have made the agent work on a branch or clone in the first place to open up a pull request workflow for these changes. Version control functionality is essential when working with agents.

The Future#

The world is starting to realize that agents need version control. Dolt is the only version-controlled database. The Dolt Workbench is an easy way to see the power of Dolt with agents. So much so that “agent mode” is coming soon. Stay tuned. The Dolt Workbench will be the world’s first SQL Workbench with agent mode. Question? Just come by our Discord and ask. We love talking to users.