Dolt is a version-controlled database that makes it safe for AI agents to read and write production data. Agents can make changes on isolated branches or full database clones, inspect the resulting diff, and merge those changes upstream once they have been validated.

Dolt is about 8 years old, and we initially designed and built it as a version-controlled database for human engineers. Now, though, more companies are putting Dolt into production as part of an agentic AI stack, and thousands of agents are using and configuring it in ways we did not anticipate.

Sometimes unexpected agentic interactions with Dolt find real bugs in our database implementation, which is great. It gives us the opportunity to fix them and harden Dolt for production agentic workloads.

Other times the bug is in the agent’s use, configuration, or understanding of Dolt. But calling these “bugs” feels inaccurate. We find that they are usually locally reasonable decisions made by an agent that violate some larger constraint the agent does not understand or has forgotten about.

In fact, I’ve come across this situation so often in 2026 that this distinction has me wondering whether we should aim to build products differently when the primary user is an AI agent. And if so, what do we build? How does this change our product surface?

A locally reasonable, globally terrible idea#

Deleting a lock#

To anchor this thought experiment in a concrete example, consider one case I encountered. An agent received a busy signal while trying to access a Dolt database concurrently, blocking its progress.

In fairness to the agent, it had encountered a legitimate Dolt bug and recognized that it needed a workaround until Dolt was patched.

However, in an attempt to do so, it read the Dolt source code, located an internal lock file managed by the Dolt process, and added code to its application to periodically delete the file as a workaround. The agent believed this was the proper solution because the action appeared to solve its local problem. But it caused massive problems in the application overall, resulting in lost data.

A human engineer familiar with databases would almost certainly hesitate before deleting an internal lock file in application code. The name alone suggests that it exists to protect a database invariant. But the agent believed it fully understood Dolt’s implementation and concluded that removing the file was the correct solution. It was not.

We suspect that agents feel more cavalier with Dolt’s internal files in particular because they’re persisted in CWD in a .dolt directory, local to where the agent is working.

We made the decision to store Dolt files here at a time when we were making product decisions for human engineers, so that their Dolt experience matched the feel of Git.

Now that agents are using Dolt, though, this may not be the best place to store them since they might be more likely to change files at this location than ones stored at say /var/lib/dolt.

Aggressive timeouts#

In another case, I investigated a customer’s deployed Dolt server that was canceling connections while its clients were still waiting for query results. When I dug into why the server was prematurely killing queries, the cause turned out to be a fixed read timeout configured by an agent. This setting meant any query that exceeded the timeout was automatically killed by the server.

An agent had added the timeout to solve an entirely different problem in the customer’s application. Once again, its change worked for the immediate problem at hand, but it also created a new failure mode somewhere else.

This is the pattern I’ve seen many times over the course of the year. Agents are remarkably good at finding a change that addresses the symptom in front of them, but they are less reliable at recognizing the implicit contracts around that change that a human engineer would keep in mind. But I don’t think it matters much that a human is better than an agent in this case, since agents are effectively eating the software world. I believe we should make an effort to find ways to help agents use our products more easily, more correctly, and more wisely.

Documentation alone feels limited#

My first thought when brainstorming how Dolt might make it easier for agents to use it more correctly was to publish two server configuration surfaces: a complete one for human engineers and a smaller, safer one for agents.

The problem with that, though, is it would not really work. Agents read documentation and source code constantly, so they’d immediately discover the human configuration and use it instead of the smaller surface if the latter proved too limited. There would also be no way to distinguish a “human” configuration user from an “agent” configuration user and guard fields accordingly.

Another idea to build better agentic UX into Dolt would be to write exhaustive documentation, heavily comment every configuration option, and instruct agents to read it before acting.

The problem here is that I’ve tried similar approaches with agents in the past, and long prompts and frequent reminders to adhere to them are not consistently followed. Agents do things differently, seemingly every session, even when given identical information.

I’ve even found that, when using the built-in memory features of modern harnesses like Claude Code, the agent forgets things I’ve told it to never forget or to always do, even when those instructions are persisted in its internally managed memory files.

The other issue with large bodies of instruction or documentation is that they consume significant context and tokens, which increases cost. This is a factor that needs to be considered in a solution as well. Ideally, a product can encourage correct usage without increasing customer token spend.

We did make an earlier attempt to publish a comprehensive AGENTS.md file in Dolt with guidance about Dolt’s basic functionality. The idea was that customers could supply this directly to their agents before the agents started using Dolt to get them up to speed.

But this serves mostly as a getting-started guide. It’s not exhaustive and doesn’t explain everything the agent should not do, especially for specific Dolt use cases.

I think in general, our goal in improving how agents work with Dolt would be to help them make sound decisions (or at least not obviously harmful ones) when they inevitably find themselves in situations that documentation can’t possibly cover.

Are skills the answer?#

The fashionable answer in 2026 is for Dolt to publish an agent skill. The major AI companies now support “skills” and provide tooling to create, test, maintain, and share them.

We have discussed publishing a Dolt skill internally, but have not yet pulled the trigger. One reason for this is that, for the most part, agents already know how to use Dolt. Git and MySQL are well-represented in their training data, and Dolt deliberately combines those familiar interfaces, so agents understand it quite well. Dolt’s large body of blog content is also likely represented in modern models’ training data at this point, so it’s unclear that publishing and maintaining a skill is worthwhile. Essentially, teaching an agent how to run dolt branch or write a SQL query is not the hard part.

The hard part is teaching it when not to reach below those interfaces into database internals, when a workaround should trigger suspicion, and when solving one problem has changed the behavior of the whole system.

Ironically, although I say writing a SQL query is not the hard part for an agent, this isn’t exactly true in Dolt’s case. Another trend we’ve seen among agents working with our database in 2026 is their propensity to write recursive CTE queries that our analyzer struggles with. These queries are complex and aren’t traditionally written by human engineers, who opt for simpler, more readable queries. But agents definitely prefer them.

For Dolt, though, these kinds of queries are slow, and greatly improving our SQL analyzer is a major point of emphasis in the coming quarters, largely because more and more of the queries we see in the wild are written by agents, not humans.

But in the meantime it would be helpful to direct an agent away from these types of queries and toward ones that perform better in our analyzer.

Would a Dolt query skill help here?

Maybe. I suppose it could be worth trying, but I think our hesitance is also from experiencing how quickly agent improvement fads go out of fashion.

Before agentic skills took over the internet, it was Model Context Protocol (MCP). So, to make sure agents could use Dolt correctly, we built the Dolt MCP server.

And, before MCP, retrieval-augmented generation (RAG) was supposed to give models missing context and help them do the right things. But RAG didn’t make it out of 2025.

I’m personally skeptical that skills will retain our attention for very long.

Should the product change at all?#

I’m curious whether the durable answer has to live partly within the product itself and whether anyone else has found success augmenting their product to better serve agents.

I don’t have a compelling idea for what this would look like for Dolt, but I’m hoping to be inspired by others’ experiences.

It is also possible that the product is not the right place to solve this particular class of problems.

A general-purpose product cannot know the intent of every application built on top of it. Perhaps the application layer, or even the agentic harness layer, is the best place to guard against erroneous usage.

Dolt can explain what a read timeout does, for example, but it cannot know whether canceling a long-running query is acceptable for a particular customer workflow. Something above the Dolt layer may need to own and enforce these parameters.

It’s possible that bespoke agent harnesses built for individual use cases might help a lot here. Instead of a generic coding harness like Claude Code, I’m imagining a specialized harness used specifically for building in and around the database layer — something like a “database engineering” harness.

A harness could give an agent the subset of tools appropriate for the job, encode the application’s invariants, validate its work, and decide when a change needs human approval. The product would still need to expose safe primitives, clear errors, and machine-readable consequences, but the harness would supply the context necessary to decide what is wise in this particular application.

For now, this is just science fiction.

But if that is the direction things go, then building a product for agents may look less like building a special agent interface and more like making the product a good component from which these opinionated harnesses can be assembled. I am not yet sure where that boundary belongs or how much custom work companies will have to do for themselves. We’ll have to wait and see.

Conclusion#

So once again, if you build a product used primarily by AI agents, what has actually helped them use it correctly?

Do you rely on constrained interfaces, skills, better errors, policy checks, validation, or something else?

Do you build things differently for AI agents than you do for your human users, and if so, how do those products differ?

How do you teach an agent not only what it can do but what it shouldn’t do and why?

If you have found an approach that works, come tell us in our Discord. We would like to try it.