--- title: "The database layer that keeps AI agents on a leash." date: "2026-07-06" author: "Maykel Farha" excerpt: "AI agents are fast at schema work, but your database still needs a human signature. Learn how nuzur uses MCP-powered change requests so agents can propose safely while you stay in control of approvals, migrations, and generated code." slug: "database-layer-for-agents" image: "/blog-images/nuzur-claude.jpg" --- # The database layer that keeps AI agents on a leash. AI assistants and agents are now part of the workflow for most of us. They speed up development, automate the repetitive stuff, and let us focus on the parts of building a system that actually need a human. But there's one layer where I think we need to slow down: the database. A core part of any system's design is its data model, and it's still a sensitive one. You can ask an agent to model a schema for your application and it'll usually do an okay job with the context you give it — but in my experience, it's rarely the *best* design. I've gotten tables with way too many columns, no real thought given to how the schema will evolve over time, data that isn't grouped in any logical sense — even from the most powerful models. The focus is on getting the task at hand done quickly, not on where the schema needs to be in a year. You can throw a lot of rules and markdown files at the problem to make an agent's schema design better. But I firmly believe human review is still necessary to make sure it actually makes sense. At the end of the day, the human working on the project has more context than we can ever hand to a model. And these domain models get large and complex as a system evolves. I think a visual representation of the model is what actually makes it understandable — you can see the entities, see how they relate, see the shape of the thing instead of scrolling through a `schema.sql` file. That visual layer matters for engineers, but it matters even more for the non-technical people on a team who need to understand the system without reading code. Modeling the domain of a system is part of the core architecture, and with so much of the rest of the process getting automated, I'd argue this is the part that deserves the *most* attention — not the least. Even with agents in the loop, it's still expensive to drastically change a model once a project is well underway. Automation should make this part safer to touch, not something you touch less carefully. ## What nuzur does about it This is the problem [nuzur's MCP server](/docs/mcp-connect) is built to solve. You import your existing database (or create a new one) and inspect it visually — that's step one. From there, the MCP server lets an agent make changes to the schema, but every change is something you review: you see exactly what's changing, and it's kept as a record as the system evolves. I like to think of it as the agent proposing and you disposing — the agent never actually holds the pen. It doesn't get a live connection to touch anything on its own. It opens what's essentially a pull request against your schema: a change request describing a new entity, a new field, an index, a relationship. nuzur stages it, you see the diff, and only once you approve does anything become real. That review step is the whole point. A bad line of application code fails a test and gets caught. A bad schema change is a different kind of mistake, it reshapes the data itself, and data has memory. Dropping a column isn't something you `git revert`; it's a restore from backup and an incident to explain. The gate needs to be there precisely because the agent is fast enough to outrun anyone's ability to safely absorb its changes without one. ## It's not just schema — it's your data too The other part nuzur handles is [data management](/docs/data-manager-manage-data), following the same logic: an assistant can propose adding, updating, or deleting data, and you review those changes visually before anything commits. You can edit them if something's off, and you keep a record of what happened in case you ever need to go back and see why. nuzur also validates whatever the agent is trying to add or update — making sure required fields are present, formats are correct, and any validations you've defined on the model are actually applied. Nested entities (JSON fields) get validated too, if you've defined rules for them. The agent doesn't get to write bad data any more than it gets to write a bad migration; it just gets to propose. ## Built for how agents actually work The MCP server itself is optimized for agents specifically — granular, specific tools instead of one tool that expects a giant payload. Our first version had one big hammer: replace the whole project version with a new one. It technically worked, but it fought against how agents actually reason. Agents work in small steps — add this entity, then this field, then wire up the relationship — and forcing them to reconstruct and resubmit an entire model for every small change was slow, error-prone, and made the resulting change requests harder to review. So we rebuilt the tool surface around granular operations — `addEntity`, `addField`, `addIndex`, `addRelationship`, `addEnum`, and others — each one mapping to a small, legible piece of a change request. The agent composes them naturally, and what lands in front of you for review reads like a sequence of intentions instead of a wall of regenerated JSON. This isn't theoretical for us — we use nuzur on our own projects daily, and entire schemas have been built through agent sessions where every change flowed through this same review workflow. The friction we felt using it ourselves is the friction we went and removed. ## Where this is going I think this pattern — agents propose, humans approve, the system executes — is how agentic infrastructure should work anywhere the cost of a mistake is asymmetric. Databases are just the sharpest version of that problem: the place where "move fast" and "don't break things" are in the most direct conflict. If you're using Claude Code, Codex, Cursor, or any MCP-capable agent, and you've felt that flicker of hesitation before letting it near your schema — that hesitation is correct. You shouldn't have to choose between agent speed and database safety. Connect the [nuzur MCP server](/features#mcp-connector), point your agent at a project, and let it propose something. You'll still hold the pen. --- **Use nuzur for free.** Connect your agent, model your data, and review every change before it touches your database — no credit card required. Sign up and start for free →