AI agent governance starts mattering the moment an agent can do more than answer a question. If it can read your inbox, write to your calendar, add rows to a sheet or send a customer an email, you need plain answers to a few questions before it does:
- Who owns this piece of work?
- What may the agent read, and what may it change?
- Which changes wait for a person?
- What record is left afterwards?
- What happens when the agent is unsure?
Big companies write policies about this. A small business needs the answers to live in the tool itself, so they hold on a busy Tuesday. Here is a governance model you can run without a committee, and how Tensor Autonomous puts each part in the product.
1. One owner per responsibility
Tensor's unit of work is a responsibility: one job you hand it, such as "log maintenance requests and acknowledge them" or "follow up on open quotes". Each responsibility has an owner, the person who set it up, approves its changes and gets its receipts. In a five-person office that is usually the owner or the office manager; in a larger one it is whoever runs that corner of the admin.
That is the whole ownership model. Not a steering group, one named person per job, and a list of the jobs. Your Library of responsibilities is that list: what Tensor does for you, who owns each, which accounts it uses, and whether it is running.
2. Reading is wide, writing is narrow
Separate what the agent may look at from what it may change.
Tensor reads what the job needs: the inbox the requests arrive in, the calendar it checks, the sheet it keeps. Reading is low risk and the agent needs context to do good work; a follow-up written without the thread it belongs to is worse than none.
Writing is where governance lives. Every responsibility names the places it writes, the connected accounts it writes with, and nothing else. A responsibility that logs maintenance requests can add rows to its sheet and draft acknowledgements in the leasing inbox; it cannot touch the rent ledger because that was never connected to it. Credentials stay with Tensor, never in the agent's view, and you can disconnect an account in one click.
3. Approval by default, limits by choice
The core rule: Tensor asks before it writes or sends. When a task reaches a change, it shows the exact change (the event, the row, the draft) and waits; nothing it drafts is sent until you send it. This is the default for every new responsibility.
Once you trust a routine, you set limits instead of approving each time: which kinds of change may run without asking (adding a row, creating a draft, adding an event), a daily cap, a days-and-hours window, and for each write an amount ceiling and a limit on recipients. Within the limits the work runs; at the edge it stops and asks. Sending email, payments and refunds, and moving or cancelling a calendar event always ask; limits can't cover them.
That is the difference between governance that exists and governance that is a document. The limit is enforced by the thing doing the work, not by a policy the agent is asked to remember.
4. A receipt for every run
After Tensor writes, it reads the record back from where it was written and compares it with what it sent. The receipt for the run shows what was asked, what it read, what it proposed, who approved it and when, what it wrote, and whether the read-back matched. Receipts are kept per responsibility, so the question "why did this tenant get that email?" takes a minute, not an afternoon.
Mistakes are recoverable. Next to each write in a responsibility's work, Undo removes what Tensor created (an event, added rows, a draft); you read exactly what will be removed and confirm, and if it has since been changed, Tensor leaves it alone. A responsibility can be paused, or rolled back to an earlier version of its guide, while you read what happened. The one thing no tool can take back is an email that has been sent, which is why every send waits for your OK; limits can't cover sending.
5. When unsure, stop
The best thing an agent can do with a case it does not understand is nothing, loudly. Tensor stops and asks when the request does not match the job, when the records disagree, when a limit would be crossed, or when a message would promise something you have not offered. A high number of stops in the first week is not failure; it is the agent showing you where the job's edges really are, so you can set the limits properly.
6. The register is the Library
The last piece of textbook governance is an inventory of agents and their powers. In Tensor that is your Library of responsibilities: for each one, the owner, the accounts it uses, what it may change alone and what waits for you, and its recent receipts. It is kept by the product as a side effect of the work, which is the only way an inventory in a small business stays true.
What this is not
Governance in the tool does not replace your own judgment about which work to hand over, and it is not legal or compliance advice. Anything regulated, anything to do with staff, payments or contracts, stays with people. Tensor is for the office work that repeats: inquiries, bookings, logs, follow-ups, documents.
Where to start
- Security: where credentials live, what Tensor can reach, and how access is removed.
- Product: responsibilities, approvals, limits and receipts in one tour.
- Try it live: approve one real change on sample data and read its receipt.
- Plans from $149 a month.
Related reading
- Automated approval: what should run by itself, and what should wait for you
- What is an AI agent?
- AI workflow automation
See it in a demo
Watch one responsibility run end to end: the request, the proposed change, your approval, the write and the receipt.