Your AI agent has given you another job

I don't want a second job supervising an AI assistant.

If a business owner has to approve every filed attachment, every internal note and every update to a routine report, the automation has kept them in the middle of the work. It may move the mouse faster. They still have to sit there.

I also wouldn't solve that by handing the agent an administrator account and hoping it remembers the instructions. The useful work is in deciding what it can finish on its own, what needs a real decision, and what it should never be able to do.

That belongs in the project scope before anyone promises you an autonomous business.

Cover: AI-generated editorial illustration of a fictional office. It does not depict a client or a real software interface.

Make the routine work genuinely routine

Take a hypothetical contractor receiving project documents by email. Someone reads each message, matches it to a project, files the attachment and updates a tracker. That is a reasonable place to look for automation. Asking the owner to repeat all four decisions in an approval window is a disappointing outcome.

I'd start by writing down the circumstances in which those decisions are already settled: the sender is on the project's approved list, the project number matches, the destination folder exists, and the attachment is a permitted type. The system can carry out that narrow job and leave a record of what it did. Unexpected senders, conflicting project numbers and attempts to overwrite an existing document go to a review queue.

Opening every mailbox, changing folder permissions and emailing documents to a new subcontractor are separate capabilities. They don't become necessary just because the agent can ask for them.

This also gives the person buying the system something understandable to approve: a defined operating rule, with specific exceptions. You can change the rule later without reauthorizing the same ordinary action hundreds of times.

An approval screen is not the same as a permission boundary

A detail in GitHub's July announcement of agent automation controls is worth reading carefully. Its review interface can hold suggested issue changes for a person to accept. GitHub also explicitly explains that those approvals are a workflow convenience: an agent with permission to change an issue can apply the change directly.

That is a useful feature with a stated limit. It is not a reason to pretend the review screen enforces a restriction that it doesn't enforce.

For your own system, ask a plain question: if the agent tries to skip this approval, what stops the action? For consequential operations, the answer should be a restriction in the service, account or execution layer. A sentence in the prompt asking it to behave is not an equivalent control.

On September 17, GitHub made workflow execution protections generally available. These control which actors and events can start an Actions workflow, with rules that can target particular workflow files. Its evaluate mode lets teams inspect what would be blocked before enforcing a rule. That is a separate mechanism from the issue-review interface, and it illustrates a useful design principle: put the control where the operation actually runs.

You don't need to use GitHub to apply that principle. A document-filing worker might get access to one destination library and no ability to change its sharing settings. If the connector cannot provide the scope you need, that limitation belongs in the buying decision.

Save approvals for decisions worth a person's attention

Some interruptions are the job working correctly. If an assistant is about to send a proposal to a customer, commit to a delivery date or delete records, stopping can be appropriate. The approval request still needs to give the reviewer enough information to make that decision.

Imagine an agent asking to send a project update. I'd want the actual recipients, the message and attachments, which project they belong to, and whether this is a first send or a retry. A generic “allow email tool” prompt makes the person reconstruct the action themselves.

The permission should cover the reviewed action. Changing the recipients or attachments after approval should require a new decision. If the underlying system cannot enforce that relationship, say so instead of calling the process safe by default.

For ordinary filing, a daily summary and an accessible activity log may be more useful than a stream of pop-ups. For an uncertain match, show the conflicting evidence and let the person choose. Different work deserves different handling.

Ask for a working recovery demonstration

Before expanding a pilot, I'd ask the developer to demonstrate a duplicate input, a failed connection and a request outside the worker's allowed scope. Watch what happens on the second attempt. The same incoming document should not create a second tracker entry simply because the first response was lost.

There should also be a way to pause new work, identify what already happened and correct the changes that can be corrected. An activity record should let a maintainer follow a particular input through its actions without copying confidential document contents into every log.

Recovery has limits. You may restore a previous document version; you cannot promise to retrieve an email from every recipient after sending it. That difference should affect the authority you grant at the start.

A small pilot can make these limits visible. Measure how much work finishes without intervention, how often someone has to correct it, and the time spent reviewing exceptions. Include the maintenance effort. “It ran 1,000 tasks” is not a useful saving if someone spent the afternoon checking every one.

Buy a workflow you can hand over

At Rosecraft, our construction operations integration work includes connecting Procore and Microsoft 365 workflows, routing information and documenting the handover. It is an example of systems integration, not a claim that an AI ran the business or that a particular amount of time was saved.

That's the level at which I'd start an automation conversation: one recurring job, the systems it touches, the decisions already made, and the exceptions that need someone. You can then judge whether AI helps interpret the inputs or whether a simpler rule does the work.

If your proposed automation still needs you at every step, the next improvement may be a better-defined job and narrower access rather than a more expensive model.

Have a workflow you're tired of supervising? Talk through your automation with us. Tell us which tools are involved, what should happen routinely, and where a person still needs to decide. We can discuss the integration and engineering work needed to make that handoff practical.