AI agents in real work: owners and guardrails

An agent that only chats is easy to ignore. An agent that runs inside the business is not. It reads a ticket. It drafts a bill. It files a purchase order. When it is wrong, a customer sees it, or money moves.

Before that agent is allowed to run, it needs four things. A named owner. A short list of what it may read and what it may change. A way to turn it off. A review loop that a person actually does.

I am not ranking tools. Copilot, Cursor, and Claude Code already sit in a lot of repos. Using an assistant to write code is not the same job as letting an agent act on a customer, an invoice, or a ticket. If you just put a person on a product that already has users, start with what an AI engineer owns in week one. This piece is what you do when the agent itself is going to do the work.

A named owner

The owner is a person. One name. Not a committee, and not "the AI team."

That person can answer, on a Tuesday, what the agent did yesterday and whether it should still be on. If they are out, a backup name is written next to theirs. If there is no backup, the agent stays off until they are back.

Support is a clean example. The agent reads an open ticket and the public help article. It drafts a reply. Maya on the support team owns it. If the draft is wrong twice in a week, Maya turns that action off. Not the vendor. Not the person who wrote the prompt six months ago and left.

Billing is the same shape. The agent reads invoices that are past due. It drafts a reminder. Jordan in finance owns it. Jordan is the only person who can let a reminder go out. If Jordan is on leave and nobody else is named, the agent does not send.

A short list of what it may read and change

Two lists. Keep them short. If a list needs a paragraph, the agent is doing too much.

What it may read is named records, not "the database." The open ticket. The public article. The invoice number, the amount, and the due date. Not the card number. Not the full customer file because a dump was easier.

What it may change is smaller than what it may read. A draft in a queue. A note a person will see before anything is sent. Not a sent email. Not a posted payment. Not a price. Not a write into the system of record until a person has looked.

Work	May read	May change	May not
Support reply	The open ticket and the public help article	A draft reply in the queue	Send the reply, or read the payment method
Past-due reminder	Invoice number, amount, due date	A draft email	Change the price, or send the mail
Purchase order	The approved vendor and the item	A draft order under the dollar limit	Submit the order, or draft anything over the limit

A purchasing agent can create a draft under the limit. The buyer submits it. Over the limit, the agent does not draft. It asks.

If the agent has to reach a CRM, a billing system, or an internal API, that connection needs a login, a short permission list, and a log. That is a governed connection to the systems you already run, not a paste into a chat window. Customer values, secrets, and live dumps do not go into a prompt. If the tool is not approved for that data, it does not get the paste.

A way to turn it off

Turning it off has to be something a person who did not build the agent can do before lunch. A flag on the admin screen they already use. A paused key. A button that stops the job.

If the only way to stop it is to find the person who deployed it and roll back a release, you do not have an off switch. You have a hope.

The switch should cover one action, not only the whole agent. You should be able to stop "send the reminder" and leave "draft the reminder" on. The owner should know which switch is which, and the on-call list should include that person.

The old path stays up. People can still answer the ticket, send the reminder, and cut the purchase order by hand. The agent is an extra pair of hands. It is not the only path.

A review loop someone actually runs

Once a week, the owner reads a sample of what the agent did. Ten items is enough to start. They mark what was right, what was wrong, and what should never have been attempted.

Wrong twice on the same action means that action stays off until the list changes. The review is a calendar hold with the owner's name on it. If the hold gets skipped, the agent drops back to draft-only until the review happens.

A dashboard nobody opens is not a review. A channel that fills up with agent chatter is not a review. The loop is a person, a sample, and a decision.

What you do not hand the agent yet

You do not hand it the authority to send, pay, price, or delete on day one. You do not hand it a production copy "so it can learn." You do not pick a model vendor because a demo sounded fluent. You can name the constraint: how fast the existing step has to stay, where data is allowed to go, and what must stay in your environment.

You also do not run a second project to rebuild the product so the agent has somewhere to sit. The ticket queue, the invoice, and the purchase order already exist. The agent works on those, or it waits.

Healthcare is stricter. If the path can see a patient record, the agent does not get an export to a laptop, and it does not get a paste into a tool that is not approved for that data. Clinical systems belong with Maxiom Labs. Say so on day one.

Who does the work

Do it yourself this week when someone on the team already owns the queue, the data, and the off switch. One page. Four names and lists: owner, reads, changes, how it turns off. Put the review on the calendar before you turn anything on.

Staff a senior engineer when you need a person inside your process who has shipped this into a business that already runs, and the people you have can prompt an assistant but have not owned an agent that acts. That is staff augmentation at Maxiom Dev.

Scope a build when you want a defined slice on the product you already run: the connection, the two lists, the flag, and the review. That work is adding an AI feature to a product that already has users. The broader practice is AI development. If the product is an app, that practice also lives at Maxiom Apps. If you are still arguing which shape fits, use the engagement model picker.

We have been shipping software since 2002. Assistants changed how code gets written. They did not change the fact that work inside a business needs a name, a short permission list, an off switch, and a person who looks.

Same idea, other angles

This is the piece about owners and guardrails. The same idea is on the other Maxiom sites this week, each from a different seat.

• AI features without blowing the budget, on Maxiom Apps.
• Hire AI engineers or train your team, on Maxiom Dev.
• AI agents for prior auth and intake, on Maxiom Labs.

Questions I get about agents that actually run

What does an AI agent need before it runs inside a business?

A named owner, a short list of what it may read and what it may change, a way to turn it off, and a review loop a person actually runs. If any of the four is missing, it stays on drafts or it stays off.

Who should own it?

The person who already owns that work. Support owns the reply agent. Finance owns the reminder agent. Buying owns the purchase-order agent. "The AI team" is not an owner. A backup name sits next to the first one.

What belongs on the read list?

The few fields the task needs. A ticket and a public article. An invoice number, an amount, a due date. Not a card number, not a full customer export, and not a patient record on a laptop.

What is it allowed to change?

A draft a person will see. A note in a queue. Not a sent message, not a price, not a payment, and not a submit, until the owner has said yes for that action.

What counts as a way to turn it off?

A control the owner can use without a deploy. One switch per action, so you can stop sending and keep drafting. The old path still works when the agent is off. If only the builder can stop it, it is not off.

What does the review loop look like?

A weekly look at about ten things the agent did. Right, wrong, or should never have been tried. Two wrongs on the same action and that action stays off. If the meeting is skipped, the agent drops back to draft-only.

Is a coding assistant the same thing?

No. Copilot, Cursor, and Claude Code help people write code. They do not own your customer, your invoice, or your off switch. An assistant in the repo is useful. An agent that acts on live work is a different seat.

We handle patient data. What changes?

The four things stay. The access does not. No export to a laptop, and no paste into a tool that is not approved for that data. Product work on clinical systems goes through Maxiom Labs.

Should we hire, or ask for a defined slice?

Hire when you own the process and need a senior person in your standup. That is Maxiom Dev. Ask for a defined slice when you want the connection, the lists, the flag, and the review delivered on the product you already run. That is adding an AI feature to a product that already has users. If you are still arguing, the engagement model picker is there.

If you need a person inside the team that already ships, start at Maxiom Dev. If you need the agent scoped on work you already do, start with adding an AI feature to a product that already has users or request a scoping call. Thirty minutes is enough to pick a shape, or to hear that we are not the fit.

I write from the seat of a working engineering company, not a tool vendor. More at antoniochagoury.com.