Jordan, the IT manager at Oakhollow Group, a fictional promo company with three divisions, gets a simple question from finance: who owns the AI usage on last month's bill? Jordan opens the workspace to find out and discovers three agents called Order Bot. One belongs to the apparel division. One belongs to the hard goods division. The third was built by someone in customer service who has since moved to marketing, and it appears to still be running, cheerfully, every fifteen minutes.
Jordan asks each division head who owns their Order Bot. Apparel says operations. Operations says IT set it up. Hard goods says theirs is "basically the same as apparel's," which turns out to mean it was copied from apparel's in March and has diverged in ways nobody can list. Finance would like an answer by Friday. Jordan would like a spreadsheet, a quiet room, and possibly a new job title.
Expand agents across a company only when each workflow has an accountable owner, bounded permissions, a tested way to stop and recover, and spending that someone answers for. Keep a register and a set of shared rules, and review changes to tools, permissions, models, and business logic before they reach production.
This is a recommended operating framework, not a description of a specific admin console. Before relying on any control, confirm what your platform actually enforces. A spending alert, a reporting view, and a hard limit that blocks further usage are three different things.
Start with a register, not a dashboard
Jordan's first instinct is to ask for a dashboard. A dashboard shows activity, but it can't tell you who is accountable for an agent or what it's allowed to do. That information has to be written down by people, and the simplest place to start is a register: one row per workflow.
| Register field | Example for apparel's Order Bot |
|---|---|
| Name and purpose | Apparel PO intake. Turns customer POs into draft sales orders. |
| Business owner | Apparel operations manager |
| Technical owner and backup | Business systems analyst, with an IT backup |
| Trigger | New message in the apparel orders inbox |
| Systems and access | Reads inbox and product catalog. Creates draft orders. Cannot release orders. |
| Review requirement | Every draft reviewed before release |
| Budget owner and cost center | Apparel operations, apparel cost center |
| How to stop it | Who disables it, and what happens to drafts in progress |
| Last reviewed | Date, and who reviewed it |
Keep credentials out of the register. Give agents distinct names that say what they do and for whom, so "Order Bot" becomes "Apparel PO intake" and "Hard goods PO intake." Similar names hide real differences. An agent that prepares a margin report and one that changes order charges may use the same data, but they carry very different consequences, and a shared label like "finance automation" doesn't tell anyone who may change which.
The NIST AI Risk Management Framework and its Govern playbook put accountability, documentation, and ongoing oversight at the center of managing AI risk. A register is the practical version of that for an operations team.
Set boundaries people can review
For each agent, define what it may read, create, edit, send, or delete, and which records and destinations are in scope. Mark where a person must approve, and keep preparing a recommendation separate from carrying it out.
Use permissions in the connected systems wherever they exist. An instruction to "be careful" is hard to audit and easy to interpret differently. A role that cannot release an order is a boundary anyone can verify.
Look for overlaps across the register. Two agents updating the same customer or order need agreed field ownership and coordination rules. An agent that can read a broad database and also send messages outside the company deserves extra scrutiny about what can leave and who receives it.
Write shared operating rules once
Oakhollow's three divisions handle the same situations in three different ways, and nobody decided that on purpose. Write a short set of company rules for common cases: ambiguous customer matches, missing prices, disputed invoices, changed delivery addresses, duplicate POs, and outdated source information. Give each rule a business owner and a way to approve changes.
Individual workflows can apply a rule differently when their scope requires it, but the difference should be visible and intentional. If one division pauses on an unverified address while another accepts it automatically, someone should be able to explain why.
Keep durable records of approvals and completed actions. The record should survive a restarted run and let someone other than the original builder recover the work.
Make spending something someone answers for
Agree on what an agent's cost includes. That might be platform charges, model usage, tool calls, outside API fees, and the human review time it requires. Map each agent's usage to a business owner and cost center, and confirm the billing units and current terms rather than estimating from a demo.
Trelium describes its usage model as workflow based, designed to make automation costs easier to understand and manage. That helps with attribution, but someone still has to own each line and decide whether the work was worth it. Track cost per accepted result alongside volume. A cheap run that gets redone three times isn't cheap, and an expensive run may be worth it if it finishes a task that would otherwise take hours. Our guide on measuring AI workflow cost and ROI walks through that comparison. Then decide what happens at the budget line, and test it.
An alert or a report
- Tells someone that spending passed a threshold.
- Usage continues until a person acts.
- Needs a named responder and a response time.
- Record it in the register as 'alert', not 'limit'.
An enforced limit
- Stops further usage under defined conditions.
- Can interrupt work that matters, so plan the fallback.
- Must be tested at the boundary before you rely on it.
- Record it as a limit only after a test shows it blocks.
For a weekly margin report, pausing at the budget may be perfectly acceptable. For a rush order queue, a pause could cost more than the usage, so it needs an escalation path instead. Decide which is which before the line is reached, not during.
Put changes through a light review
Changes to models, instructions, field mappings, tools, permissions, or business rules can all change what an agent does. Keep a versioned record of significant changes, who approved them, and what was tested. Separate experiments from the production workflow wherever your setup allows it.
After a material change, rerun the agent's representative cases. Our post on testing a fix without reintroducing old bugs covers how to build that set. At the organization level, the rule is simpler: no change reaches production without a named approver and a record of what was run.
Don't expand access as a troubleshooting shortcut. If an agent now needs a new data source, a new outside destination, or new write permission, treat that as a scope change and send it to the business and technical owners, not as routine tuning.
Plan for incidents and departures
Set an escalation route for wrong updates, suspected data exposure, unexpected spending, and long outages. Make it possible to stop one agent without stopping unrelated work, and confirm who can revoke the relevant accounts and sessions.
Oakhollow's third Order Bot is what happens without a departure process. When an owner leaves or a process is retired, review their agents and connections, reassign active work, and remove access that no longer has an approved purpose. Include unfinished jobs and any data retention obligations in that handoff.
Separate what you've proposed from what the platform does
Many of the controls in this post are operating practices: the register, shared rules, budget owners, change approval, and departure reviews. Others depend on product features. Keep the two lists separate, and verify the second one.
Trelium's security page describes centrally managed access through the identity tools IT already uses, with role based permissions and instant offboarding, and its site describes audit trails. Confirm how those work in your own deployment. For anything else you need, such as an inventory view, enforced budgets, approval routing, or version management, ask for a demonstration in your environment rather than assuming an admin console provides it.
What governance can't do on its own
A register records responsibility but can't enforce it. Written rules need working permissions, monitoring, and people who can step in. Budgets may leave out outside API or review costs, and stopping a workflow may not cancel a request another system has already accepted. Test those edges.
Readiness checklist for a company rollout
- Every agent is in the register with a distinct name, purpose, business owner, and technical owner with a backup.
- Each agent's read, write, send, and delete permissions are written down and enforced in the connected systems where possible.
- Overlapping access between agents has field ownership and coordination rules.
- Shared rules for common situations have owners and a change process.
- Each agent's usage maps to a budget owner and cost center.
- Every budget threshold is recorded as an alert or a tested limit, with a named responder.
- Material changes have an approver, a version record, and a test run.
- New access or destinations go back to the owners as scope changes.
- There's an escalation route for wrong updates, exposure, spending, and outages.
- Departures and retirements trigger a review of agents and connections.
- Proposed practices are listed separately from verified platform features.
Frequently asked questions
What should an AI agent inventory include?
One row per workflow with its purpose, business owner, technical owner and backup, trigger, systems and permissions, review requirements, budget owner, stop procedure, and last review date. Keep credentials out of it.
Who should own an AI agent's spending?
The business owner whose work the agent does, tied to their cost center. IT may administer the platform, but the person deciding whether the work is worth the cost should be the one who answers for it.
What's the difference between a spending alert and a spending limit?
An alert tells someone a threshold was passed, and usage continues until a person acts. A limit stops further usage under defined conditions. Only call something a limit after testing that it actually blocks usage.
How should changes to a working AI agent be approved?
Treat changes to models, instructions, mappings, tools, permissions, or business rules as releases. Each needs a named approver, a version record, and a rerun of the agent's representative cases before it reaches production.
What happens to an AI agent when its owner leaves?
Unless there's a departure process, it usually keeps running with nobody responsible for it. Review the person's agents and connections, reassign active work and ownership, and remove access that no longer has an approved purpose, including any unfinished jobs.
Friday at Oakhollow
By Friday Jordan has a register with fourteen rows, which is eleven more agents than anyone thought existed. The apparel and hard goods Order Bots now have distinct names, separate owners, and separate cost centers. The third one, running every fifteen minutes for a person in marketing, has been reviewed, found to duplicate apparel's work, and switched off with that owner's agreement.
Finance gets its answer, with a name next to every line. Jordan did not get a heroic new dashboard. Jordan got a spreadsheet, a quiet room for one afternoon, and a standing monthly review that takes thirty minutes. That turns out to be most of what governance is.
Anindo Neel Dutta
Member of GTM Staff
Get started
Ready to see Trelium in action?
Schedule a 30-minute conversation about the workflow you want Trelium to handle.
Book a Demo→
