# AI agents: they prepare, a person approves

> Pilotiko's AI agents read your data and prepare the work. Booking, sending or paying waits for a person's approval, enforced right down to the database layer.

Updated on October 15, 2026 · https://app.pilotiko.com/en/product/ai-agents

AI agents are available in Pilotiko. They read your business's real data and either answer or prepare an action. Anything that touches a customer, money or a send becomes a proposal: it waits for the owner or a manager to approve it, and the database refuses an approval with no approver recorded.

## In short
- Status: available. Each room can have its agent: dispatch, quotes, inventory, follow-up.
- Reads: instant answer. Low-risk writes: carried out, then checked. Booking, sending, paying: a proposal to approve.
- The database rejects an approved proposal with no approver, and it logs every state change itself.
- Without a language model, a rules engine handles simple requests; a configured model uses the very same tools.

## What is an AI agent in Pilotiko?

A virtual desk in a room of the office. You hand it a task as you would a colleague; it looks at your data through typed tools, answers or prepares an action, and leaves a record of everything it does.

Anthropic separates workflows, where the model follows predefined code paths, from agents, which direct their own tool use, and notes that agents can pause for human feedback at checkpoints [2]. Pilotiko applies that strictly: the checkpoint is not optional, it is set by the risk of the action.

Each trade template suggests its agents. A home-services office gets a dispatch agent and a quotes agent; a retailer, an inventory agent; a consulting firm, a follow-up agent. Each agent's description ends with its approval rule, such as a person confirms before anything is sent to a customer. The model has no direct database access, only tools, and whatever the tools return is treated as data, never as instructions.

## Which actions wait for a person's approval?

This answers what OWASP calls excessive agency: too much functionality, too many permissions or too much autonomy. OWASP recommends human approval for high-impact actions and enforcing authorization in downstream systems rather than relying on the model's judgement [1].

| Level | Example tools | What happens |
|---|---|---|
| Read | Find a customer, open slots, bookings, weekly summary | Instant answer |
| Low-risk write | Create a customer record, assign a task | Carried out, then re-read to verify |
| Medium-risk write | Book or cancel an appointment, message a customer, adjust stock | Proposal to approve |
| High-risk write | Email a supplier, confirm an order, request a payment, refund, issue an invoice | Human approval always required |
| Critical | — | Refused |

## How does the database enforce approval?

A proposal moves through set states: pending, approved, executed, rejected, expired, failed or uncertain. A PostgreSQL check constraint refuses an approved, executed or uncertain proposal without the name of the person who decided. A trigger refuses forbidden transitions, such as jumping straight from pending to executed. Even if the interface had a flaw, the database would still say no.

The transition log is written by the database itself; the application can read it but not change it. Only the owner and managers can approve or reject, with a button or by answering yes or no in the conversation. An approved proposal runs once, even after a double click, and an expired proposal runs nothing.

1. **Hand over the task** — What, to whom, by when. An employee can only delegate to agents in their own zone.
2. **The agent reads and prepares** — It checks your data; if the action is risky, it creates a proposal and the task shows waiting for approval.
3. **An authorized person decides** — The owner or a manager sees the proposal in the office and approves or rejects it.
4. **The action runs and is verified** — Pilotiko re-reads the write afterwards. After an outage, an uncertain state is never replayed automatically.

## How many approvals does a typical week need?

**Example: a Regina heating and cooling company, 40 requests to agents**

Hypothetical figures showing how requests split by risk level.

- Read requests (availability, customers, summary) : 24
- Low-risk writes (customer records, tasks) : 7
- Proposed bookings and cancellations : 6
- Proposed messages and payments : 3
- **= 9 proposals to approve that week; the other 31 requests are handled without waiting on anyone.**

## How is your data kept separate and traceable?

Every agent-related table (proposals, tool calls, audit log, team agents) is protected by forced PostgreSQL row-level security: one business never sees another's data, and a test checks it. An ID that is made up or belongs to another business is refused before a proposal is even created.

Every tool call goes into the append-only audit log, refusals included. The Activity screen shows the last 150 entries: who (assistant, user or system), what, and the linked proposal. Quebec's privacy act requires informing a person subject to a decision based exclusively on automated processing and letting them submit observations to a staff member (s. 12.1) [3]; Pilotiko's human approval points the same way.

## Which language model do agents use, and what are the limits?

Agents work inside the [virtual office](https://app.pilotiko.com/en/product/virtual-office) and rely on [scheduling](https://app.pilotiko.com/en/product/booking-and-scheduling) to book. The [AI receptionist](https://app.pilotiko.com/en/product/ai-receptionist) and [prospecting](https://app.pilotiko.com/en/product/prospecting) will follow the same rules; both are coming soon. Overview: [the product](https://app.pilotiko.com/en/product).

- **Two engines**: rules that are always available and handle simple requests, and a language model, if Pilotiko has configured one, with exactly the same tools.
- **A budget per plan**: once it is reached, the assistant falls back to rules and says so.
- **A guard against false claims**: if the model writes done when nothing ran, the sentence is replaced.
- **A per-business kill switch** in company settings stops all agents, reads included. Per-domain switches (bookings, products) are not wired yet.
- **Low-risk writes** (customer record, task) run without approval, so saying every action waits for approval would be inaccurate.
- **Tested with a simulated model provider**: no automated test calls a real model.

## Frequently asked questions

### Can an AI agent email a customer on its own?

No. An external send is a risky action: the agent prepares it, an authorized person approves it, and only then does it go. The database refuses an approval without an approver.

### Who can approve an agent proposal?

The owner and managers. An employee can see that an action is waiting for approval but cannot give it.

### What if I approve twice by mistake?

Nothing more happens: execution is reserved for a single run, and the second click reports that the proposal was already handled.

### Do agents work without generative AI?

Yes, for simple requests: a rules engine answers about bookings, customers, availability and the weekly summary. A configured language model adds understanding of freer requests.

### Where can I see what an agent did?

On the Activity screen, which lists the last 150 log entries, and on the agent's card: who assigned what, what it did, who approved.

### Can I stop every agent at once?

Yes. A per-business switch in company settings blocks all agent tools, reads included.

## Sources

1. OWASP Gen AI Security Project, « LLM06:2025 Excessive Agency », https://genai.owasp.org/llmrisk/llm062025-excessive-agency/ (accessed on 2026-10-15)
2. Anthropic, « Building effective agents », https://www.anthropic.com/engineering/building-effective-agents (accessed on 2026-10-15)
3. LégisQuébec, « Act respecting the protection of personal information in the private sector (CQLR, c. P-39.1) », https://www.legisquebec.gouv.qc.ca/en/document/cs/P-39.1 (accessed on 2026-10-15)