Database tools for agents

Database tools for agents

Let an agent use your database during a conversation — look a caller's record up, create one, or change one while they're still on the line.

"Let me pull that up… I've got your booking for Friday the 12th, under the Gold plan. Shall I move it to Monday?"

These are different from filling a campaign or logging calls, which both work in bulk after the fact. These run mid-sentence.

Before you start: connect your database. These tools appear only once a connection exists.

The three tools

Add them under Agent → Tools → Add tool → Database → your engine. Add only what the agent actually needs — a lookup alone is a perfectly good tool.

Look up a record

Step 1 — Choose the table

Read off your connection, so you pick rather than type. On MongoDB this is the collection.

Step 2 — Tick the columns the agent may read

This is the setting that matters most on this page. Whatever comes back goes into the model's context and can be spoken aloud.

Agent may read
  ☑ name     ☑ plan      ☑ renewal_date
  ☐ email    ☐ card_last4
  ☐ internal_notes        ☐ password_hash

Only ticked columns are returned. We never SELECT * — which also means a column your team adds to that table next year cannot quietly start reaching a live call.

Step 3 — Tick the columns it may search by

Searchable by
  ☑ phone    ☑ booking_ref

Usually the caller's number and one reference. The agent cannot search a column you didn't tick, so it can't probe the table — and it can't dump rows by searching a common value in a column you never meant to expose.

If you tick exactly one, the agent doesn't have to name it; it just searches.

What the agent gets back

Up to 20 records (5 by default), each with only your ticked columns. If it searches a column you didn't allow, it's told which columns are searchable and can try again — it doesn't silently get nothing.

An empty search is refused rather than answered with "here are the first five customers".

Create a record

Step 1 — Choose the table

Any column you don't offer must be nullable or have a default — the insert names only the fields you pick.

Step 2 — Press Load fields and tick what the agent can fill

Those become the tool's named fields:

create_ticket
  subject   (required)
  priority
  customer

The agent never guesses a column name, and a wrong choice is caught here rather than as a failed insert mid-call.

Update a record

Step 1 — Choose the table, then Identified by

A column that identifies one record — a primary key.

The agent can only change the record whose key value the lookup returned, and never more than one at a time. It cannot invent a key or write its own condition, which is what stops an update landing on records nobody was talking about.

Include the key column in the lookup's readable columns, or the agent won't have the value to pass and the update can't run.

Step 2 — Load fields and tick what it may change

Same as create. Only the fields you tick can be written, and only the ones the agent actually fills are changed — the rest of the row is untouched.

If the update matches nothing

The agent is told it changed nothing. It won't confirm a change that didn't happen, which is what would occur if a "0 rows updated" were reported as success.

Putting them together

A typical support agent has look up and update:

1. Caller rings. The agent searches phone for their number.
2. It reads back the booking from the columns you allowed.
3. The caller asks to move it. The agent calls update with the booking_ref the lookup returned, setting date.
4. Your table is changed before the call ends.

Pair look up with create instead when the caller usually isn't in your system yet — recognise them if they are, log a new lead if they aren't.

What we will and won't do

• Only the columns you ticked are ever read — on MongoDB as a server-side projection, so unlisted fields never leave your machine.
• Only the columns you ticked can be written.
• One record at a time for updates, keyed on your column.
• Every value is bound, never pasted into a statement — a caller saying something that looks like SQL is just text.
• Table and column names are checked against the ones you picked before any statement is built.

Limits

When something goes wrong

The agent receives your database's own message and can say something useful rather than failing silently.