Changing data
There are three ways to change the rows of a table: insert adds new rows, update changes existing ones and delete removes them. You ask for these in plain words, and the assistant or agent makes the change with a tool.
Inserting rows
An insert adds rows to one table, for example "Add Dana Levy, dana@example.com, as a customer".
Columns left out get their default value, or stay empty, and
the automatic id is filled in for you. The insert fails if a
required column has no value or a
unique column would get a duplicate.
One tool call inserts at most 500 rows, so agents add larger lists in batches.
Updating rows
An update sets new values on every row that matches a filter, for example "Mark order 3 as shipped".
Deleting rows
A delete removes every row that matches a filter, for example "Delete the cancelled orders".
Deleting removes rows, while the table and its columns stay. To remove a whole table, its schema has to change, which asks for your approval. A deleted row can't be restored from Tunori, so make sure you mean it.
Why the filter matters
The filter decides which rows change. "Mark order 3 as shipped" changes one row, while "mark orders as shipped" could change every order in the table. This is one of the most common and costly database mistakes.
In Tunori, an update or delete always needs a filter. Changing every row has to be requested explicitly, and the assistant or agent confirms it with you first.
The filter can still match more rows than you expect, so before a large change, ask how many rows it would affect. "How many orders are open and older than a year?" shows whether the condition is right. Each result reports how many rows were changed.
Transactions
A transaction is a group of changes that either all succeed or all have no effect. The classic example is a bank transfer: taking money from one account and adding it to another must not stop halfway.
In Tunori, each tool call is one transaction:
- An insert of 500 rows adds all of them, or none if any row is refused. You won't be left with half a batch.
- An update or delete that fails or is stopped changes nothing.
- A schema change with several steps on one table applies completely or not at all.
A task that takes several tool calls isn't one transaction. If an agent inserts an order and then its items in a second call, and the second call fails, the order stays without its items. The agent sees the error and can correct it or tell you, but the database doesn't undo the first call. After a task with several steps goes wrong, ask the agent to check what was saved. Scheduled runs deserve the same care, because nobody is watching them when they run.
Who can change what
| Change | Viewer | Editor | Admin |
|---|---|---|---|
| Look up rows | Yes | Yes | Yes |
| Insert, update and delete rows | No | Yes | Yes |
| Create and change tables and indexes | No | No | Yes |
A custom agent follows its own Database access level instead of the role of the person chatting with it. To check an agent's changes before they happen, editors can set its write tools to ask for approval.
If the database goes over its storage quota, inserts and updates are refused until space is freed or the plan changes. Reads and deletes keep working.
Seeing what changed
The Activity page lists everything run against the database: when it ran, who ran it, which agent it went through, which tables it touched, how many rows it affected and what the outcome was. It doesn't hold the old values, so it can't undo a change. The log is kept for 90 days.