An AI assistant answers. An AI agent acts.

That one difference changes everything about how you should build and deploy it. When a system can update a CRM record, send an email or create an invoice, a wrong answer is no longer just a wrong answer. It is a wrong action in a real system, with real consequences.

This guide covers the principles we think matter most when putting AI agents to work inside a business.

Assistants and agents are different kinds of risk

An assistant produces text. A person reads it and decides what to do. The human is the safety layer.

An agent produces actions. It plans steps, calls tools and changes things. If nothing sits between the agent's decision and the system it acts on, the safety layer is gone.

So the question for any enterprise agent is not "how capable is it?" but "what is it allowed to do, and who decides?"

Principle 1: Scoped tools, not open access

An agent should work through a defined set of tools, each with a narrow purpose: search_deals, update_deal_stage, create_task. It should not have a general-purpose connection with broad credentials to your CRM or database.

Narrow tools make behaviour predictable, make permissions enforceable and make logs readable. If an agent needs a new capability, add a new tool deliberately rather than widening an existing one.

Principle 2: Never more than the person

An agent acting on behalf of a user should never be able to do more than that user could do themselves. If a sales rep can't see another region's deals, neither can the agent working for them.

This sounds obvious, but it is easy to get wrong. Agents are often connected through a single service account with wide access, which quietly gives every user the agent's permissions. Permission checks need to happen per user, per request.

Principle 3: Separate reading from changing

Most useful agent work is reading: finding records, summarizing activity, spotting what needs attention. Reads can usually run straight away.

Writes are different. Updating a record, sending a message or triggering a workflow changes the world. A sensible default is:

  • Reads: automatic, within the user's permissions.
  • Low-risk writes (a reminder for yourself): automatic or lightly confirmed.
  • Consequential writes (changing a deal stage, emailing a customer, anything financial): shown to a person with the exact change, and executed only after approval.

The approval step should show precisely what will happen: which record, which field, from what value to what value. "The agent wants to update your CRM" is not an approval; it is a shrug.

Principle 4: Plan, then act, then verify

Good agents follow a visible sequence: understand the request, plan the steps, check permissions, act, then verify the outcome.

Verification is the step most often skipped. After an action, the agent should confirm the result (the record now shows the new stage; the invite was accepted by the calendar) and report back. If verification fails, it should say so plainly rather than assume success.

Principle 5: Everything is recorded

Every agent session should leave a trail: the request, the plan, each tool call with its inputs and outputs, every approval and who gave it, and the final result.

Audit trails are not only for compliance. They are how teams learn to trust an agent, how you debug a surprising outcome and how you improve the system over time.

Principle 6: Proactive, not presumptuous

Some of the most valuable agent behaviour is proactive: noticing that a large deal has gone quiet, that a renewal is due with no quote prepared, or that a task is overdue. Monitoring and reminders like these save real work.

But noticing is not the same as acting. A proactive agent should surface what it found and suggest a next step, such as drafting a follow-up, and leave the decision with a person unless the action is explicitly pre-approved.

A practical checklist

Before putting an agent into production, ask:

  1. What tools does it have, and is each one as narrow as it can be?
  2. Are permissions checked per user, on every request?
  3. Which actions require approval, and does the approval show the exact change?
  4. Does the agent verify outcomes and report failures honestly?
  5. Is every step logged and reviewable?
  6. Can an administrator switch a tool off instantly?

If any answer is unclear, the agent isn't ready.

Where QuerySafe fits

QuerySafe Agent, currently in development, is designed around these principles: an AI brain for your CRM and business systems that understands plain requests, plans the work, checks permissions and keeps a person in control of anything that matters. It builds on QuerySafe Intelligence, which answers questions from your BigQuery data.

If you are thinking about where agents could help your team, talk to us.