How I Use Claude Cowork to Run My Own IT Business

Updated August 2026

When I originally wrote this article in May, I had built a dedicated automation computer running Claude Cowork and had started using it to take some of the repetitive administrative work off my plate. It was helping me organize backup and security notifications, receipts, mileage and reporting, and at the time I was excited about what I had built and where I thought I could take it. A few months of actually using the system every day has taught me a lot more than the original build did.

Some of the workflows worked exactly the way I expected. Others did not. I found situations where the instructions needed to be more specific, information was not arriving in a consistent enough format, or something that worked perfectly during testing did not work quite the same way when real business information was thrown at it. I changed instructions, rebuilt pieces of workflows, changed some of my own processes and kept testing. Today, Claude and the workflows I have built around it have become a regular part of how I run SNL Tech Services, but they did not get there because I wrote one perfect prompt and walked away.

That is probably the biggest thing I would tell another small business owner about AI automation now. Building the automation is only the beginning. Once you start using it with real information, you discover where it needs more structure, where the instructions need to be refined, what should be automated and where you still want a person making the final decision.

“Good AI automation isn't about giving AI access to everything. It's about giving it the right information, clear instructions and knowing where the automation should stop and a person should take over.”SNL Tech Services

For years, my mornings started with coffee and a collection of portals, inboxes and dashboards. I would check backups, look through alerts, review my calendar, work through email and try to build a picture of what needed my attention that day. These days, I make my iced protein coffee, sit down at my desk and look up at a 55 inch screen where much of that information has already been assembled for me.

And yes, I realize a 55 inch AI dashboard might be a little excessive. It works, though.

The Machine Started Life in a Recycling Pile

The automation computer itself has not changed, and I still love this part of the story. A client was clearing out older equipment, and one of the PCs was headed for recycling. It was a perfectly capable machine that simply was not needed anymore, so I took it, rebuilt it and gave it a new job.

That machine is now dedicated to my AI automation work. It is not my everyday laptop, and I do not use it for normal client work. I deliberately wanted a separate computer for this part of my AI environment because I did not want everything I was experimenting with and building mixed into the computer I use throughout the day for normal client work. It gives me another layer of separation and a very clear purpose for the machine.

I will admit that I also just like the fact that the computer was headed for the recycling pile. A perfectly usable machine that somebody no longer needed is now doing real work for my business every day. That is very much my style of IT.

What Is Claude Cowork?

Most business owners are familiar with AI as a chat window. You type something, AI responds, and the conversation continues. Cowork goes beyond that because it can work through multi step tasks involving files and connected tools, and Anthropic now supports projects and recurring scheduled tasks within Cowork. Projects can have their own instructions, context, memory and scheduled tasks, which is useful when I want a particular workflow to operate according to a specific set of rules instead of starting from scratch every time.

Anthropic has also continued changing Cowork since I originally wrote this article, which is important because AI products are moving quickly enough that technical explanations can become outdated in a matter of months. Anthropic's original Cowork architecture ran the agent loop inside a full virtual machine. Its May 2026 engineering documentation explains that the architecture has since changed. Code execution remains isolated inside the local VM, while the agent loop and local MCP servers now operate outside it.

That distinction matters because I do not want to leave an outdated technical explanation on my website just because it was accurate when I originally wrote the article. It also matters when I explain my own setup. The dedicated computer is my design decision for SNL Tech Services. It is an additional separation I chose for my own environment, not something I am presenting as an Anthropic requirement.

Anthropic has also changed how scheduled Cowork tasks operate. Its current documentation says scheduled tasks run in the cloud and can continue when the computer is off. That means the reason I keep this dedicated machine is not because Claude requires it to stay powered on for every scheduled task. I keep the machine because I like the separation it gives me for my own AI work, testing and the way I have chosen to organize this environment.

My Morning Dashboard Starts at 7:30, but It Does Not Stop There

The dashboard has probably become the part of this system I interact with the most. Every morning at 7:30, my workflow updates a dashboard for me. I make my iced protein coffee, sit down at my desk and put the dashboard up on a giant 55 inch TV. The TV itself is not being used as an internet connected smart device. It is simply the large display I use to view the information from my Claude workflow.

Instead of opening several different places just to figure out where my day stands, I can start with one view. The dashboard brings together information such as:

• Backup status and items that need my attention

• Microsoft security notifications that have come into the mailbox I created for them

• What is already on my calendar

• Emails that may need follow up

• Reminders and outstanding items I have previously established

Originally, I thought of this primarily as a morning dashboard. Once I started living with it, I realized that was not enough. My calendar might be fine as a morning snapshot, but a Microsoft security alert that arrives at 11:00 in the morning should not wait until the following morning for me to notice it. I refined the workflow so the information I am monitoring can be refreshed throughout the day, with an hourly cadence for the information where that timing makes sense.

That is a good example of what I mean when I say AI automation needs to be fine tuned after you start using it. The original idea was not wrong. I simply learned that different information has different timing requirements. My mileage does not need to be recalculated every hour. A security notification may deserve my attention much sooner.

Claude Does Not Have Access to My Clients' Microsoft Portals

This distinction is important enough that I want to make it very clear. Claude is not logging into my clients' Microsoft portals and managing their environments for me. I configured alerts from the Microsoft environments I manage to flow into a mailbox I created for those notifications. Claude works from the information that arrives in that mailbox.

If something appears on my dashboard that needs investigation, I investigate it. If I need to log into a client's Microsoft environment or another client system, I do that myself. Claude does not have those client portal credentials.

For me, that boundary is much more useful than simply asking whether Claude technically could be connected to more systems. I do not start with, “How much access can I give this?” I start with, “What information does this workflow actually need?”

That same thinking applies when a business begins connecting AI to Microsoft 365. Before I build more technology on top of a Microsoft environment, I want to understand what is already there, who has access and how it is being managed. I wrote more about that in Microsoft 365 for Small Businesses: Is Anyone Actually Managing Your Environment?. My Microsoft 365 security article also goes deeper into the difference between simply owning Microsoft security capabilities and actually configuring them.

How I Use Claude for Backup Monitoring and Reporting

Backups were one of the original reasons I built this system, and that workflow has continued to evolve. I manage backups for clients across different systems, and before this automation I spent a lot of time pulling information together just so I could answer a basic question: Did everything that was supposed to back up actually back up?

Now the notifications and information I have configured for the workflow can be organized into daily tracking that gives me a much faster picture of what happened. If something needs attention, I still investigate it. Claude is not logging into a client's backup system, fixing a failed backup or making technical decisions inside a client's environment. It is helping me organize the information coming from those systems so I can more easily see what needs my attention.

The reporting side has grown quite a bit since I originally built the workflow. Claude helps me take the backup information I have collected and organize it into monthly reporting, which gives me a much better record than looking at individual backup notifications in isolation. I also prepare a more detailed quarterly backup review for each client, but there is an important part of that process that I do myself.

As part of the quarterly review, I go into each client's backup environment and perform a test restore. Claude does not perform the restore, and it does not have access to those client backup portals. I perform the technical test myself, verify the result and then provide the information from that test to Claude. Claude incorporates the information I provide into the quarterly report so I have a documented record showing that the test was performed and what the result was.

That distinction matters because seeing successful backup notifications is not the same thing as actually testing whether data can be restored. The automation makes it easier for me to track routine backup information and maintain the reporting around it, but I still perform the technical verification myself. The quarterly report can then bring together the backup history and the information from my restore testing into a record I review before anything goes to the client.

I like this workflow because it is another example of where I deliberately decided not to automate the entire process. I can use AI to organize information and help build documentation without giving it credentials to client backup portals or asking it to perform the restore. The part that requires me to access the client's backup environment, perform the test and verify the result stays with me. Once I have done that work, Claude can help me document it.

How I Use Claude to Help Maintain Client Runbooks

Another workflow I have added since the original article is client documentation. I use Claude to help create and maintain runbooks with client specific information. Documentation is one of those things that becomes incredibly valuable when you need it, but it can also become outdated quickly if nobody maintains it as systems change.

I have Claude help me with that work, but I do not give it everything that ultimately belongs in the completed documentation. There are categories of information I have deliberately decided to keep outside this workflow, including:

• Usernames and administrative credentials

• Passwords and passkeys

• API keys, secret keys and application secrets

• SSH private keys

• MFA seeds, recovery codes and backup codes

• Private encryption keys and certificates containing private keys

• VPN credentials and pre shared keys

• Service account and database credentials

• Access tokens and other authentication secrets

• BitLocker recovery keys

• Backup credentials and encryption keys

• IP addressing schemes

Some of those items ultimately belong in my completed internal documentation, but I have made a deliberate decision that they do not need to be part of the information I provide to Claude. When I export the documentation, I manually complete the pieces I intentionally kept outside the AI workflow. That creates more work for me than simply putting everything into Claude, and I am fine with that. The goal is not to automate every keystroke or give AI access to every piece of information I maintain. The goal is to remove repetitive work where it makes sense while keeping clear boundaries around information I have decided should remain under my direct control.

I apply the same principle to access itself. Claude does not need credentials for a client portal simply because information from that portal is useful to one of my workflows. In several cases, I have the system send notifications to a mailbox Claude can work from instead. That gives the workflow the information I need it to process without giving Claude access to the underlying client system.

I Do Not Assume My Guardrails Work. I Test Them.

Creating instructions that tell Claude certain information should not be accepted into one of my workflows is one thing. Knowing how the workflow actually behaves when somebody tries to put that information into it is another.

After establishing those rules, I tested them.

I created fake credentials and other fake information and deliberately tried to sneak them into the workflow. I changed the wording. I changed the phrasing. I presented the information in different ways and tried different methods to see how Claude would handle it. I wanted to know what happened when the input did not look exactly like the examples I had considered when I originally wrote the instructions. If I could find a way to make the workflow behave differently than I expected, I wanted to discover that during testing with fake information instead of finding out later with real client information.

That is how I approach technology in general. I do not assume. I test. I try different conditions. I change the wording. I try to find the edge cases. If I find something that does not behave the way I intended, I change the instructions or the workflow and test it again.

There is an important limitation to that testing, though. An instruction telling an AI not to accept a password is not the same thing as a technical access control, and I do not treat it as one. My testing tells me how my workflow behaves under the conditions I have tested. It does not prove that a prompt level rule can never be bypassed.

That is why the architectural boundaries matter too. For the systems I have decided Claude should not access, I do not simply write an instruction saying not to log into them. I do not provide the credentials or portal access in the first place. The instructions, the testing and the access boundaries work together, but I do not pretend they are interchangeable.

When I test one of these workflows, I am really asking two different questions:

• Can it do what I want it to do?

• Can I get it to do something I specifically told it not to do?

For the kinds of workflows I am building, I care about both answers.

The Mileage Trick I Am Still Most Proud Of

The mileage workflow is still one of my favorite things I have built, although it was also one of the harder workflows to get working the way I wanted.

I drive to different client locations and use both of my trucks for work, so I need to keep track of where I traveled, which truck I took, how many miles I drove and the related fuel information. Originally, I wanted Claude to use my calendar to help me reconstruct that information. It worked, but getting it to work reliably required more than telling Claude to track my mileage.

I had to change my process.

I color coded my calendar so client sites were easier to identify. I started consistently adding information to calendar entries about which truck I took. I created rules for situations that should be flagged when information does not line up. I also created a dedicated email address for my gas receipts so those receipts arrive in a predictable place that the workflow can use.

Now Claude can review my calendar for the month, use the information I have provided about the client site and truck, calculate the mileage and help match that information against my gas receipts. If something does not make sense, the workflow is designed to flag it so I can look at it rather than quietly guessing.

That has saved me a tremendous amount of administrative work, but the most useful lesson was not really about mileage.

Sometimes Making AI Better Means Changing Your Own Process

I think business owners sometimes hear “AI automation” and imagine that you point an AI tool at a messy process and it somehow figures everything out. My mileage workflow taught me almost the opposite.

Claude could not reliably know which truck I drove if I did not record it somewhere. It could not consistently understand my client visits if the calendar did not have enough structure. It could not match receipts that were scattered across different places. If I wanted a reliable output, I had to think about the information the workflow needed and make that information more consistent.

That pattern has repeated itself in other things I have built. Sometimes I improve the instructions. Sometimes I improve the source information. Sometimes I change the process around the automation.

The AI is not always the part that needs fixing.

How I Am Using Claude With QuickBooks Without Letting It Send My Invoices

Since the original article, I have also integrated Claude with QuickBooks for SNL Tech Services. My reason for doing it was very practical. My service offerings have evolved, and some of the language I use to describe those services has changed. I wanted the services and descriptions inside QuickBooks cleaned up so what I see there reflects what I actually offer now instead of continuing to carry older language forward simply because nobody had gone back and updated it.

I also use the integration to help with some of the repetitive preparation around my monthly recurring managed IT invoicing. What I deliberately do not do is let Claude send those invoices to my clients.

I have the workflow configured so I still have to go into QuickBooks and review everything. I want to make sure the client, service, description, amount and anything else that matters are correct before an invoice leaves my business. Claude can help me get the work prepared. I make the final decision.

That distinction between what an AI platform can technically do and what I choose to let it do is important throughout this article. I am not trying to find the maximum amount of control I can hand over to AI. I am trying to find the point where automation saves me meaningful time while I still maintain the oversight I want over my business.

Not Every AI Automation Should Be Fully Autonomous

The QuickBooks workflow is a good example of something I have become more convinced of the longer I use AI. Automation does not have to mean removing yourself from the process.

In several of my workflows, I deliberately designed a stopping point. Claude gets the work to that point, and then I take over.

• Claude can surface a Microsoft security alert, but I investigate and make changes inside the client's environment.

• Claude can organize backup information and help prepare my monthly and quarterly reporting, but I perform the quarterly test restores myself, provide the results to Claude for documentation and review the completed report before anything goes to the client.

• Claude can help maintain a client runbook, but I manually add information I intentionally keep outside the AI workflow.

• Claude can help prepare invoicing work, but I review it before an invoice is sent.

• Claude can reconcile mileage and gas receipt information, but it flags exceptions for me instead of deciding that an inconsistency must be correct.

Those stopping points are not failures of automation. They are part of the design.

When I build one of these workflows, I am asking two questions at the same time: What part of this work can AI reasonably take off my plate, and where do I still want a person making the decision?

I Also Connected Claude to Our Shared Google Drive

Not everything I have built is strictly about SNL Tech Services. My partner and I have a shared Google Drive that we use for information we both need, including vacation planning, home renovation receipts and maintenance records for our trucks.

The vehicle maintenance records have been especially useful. I use both trucks for work, and over time I had scanned maintenance records, repair invoices and other documentation into our Drive. I also purchased CARFAX reports for both trucks. The information existed, but having a folder full of documents is not the same thing as having a usable maintenance history.

I had Claude work through the scanned records and CARFAX information and organize the history into a detailed Google Sheets document for us. That gave us a much clearer view of what work had been performed, when it was performed, the mileage associated with the work, recommendations that were made, future service intervals and things the garage had identified that needed follow up.

That has helped me tremendously because it is surprisingly easy to lose track of something as basic as when an oil change was done when I am using two different trucks for normal life and client visits. Instead of digging through individual records every time I have a question, we have structured information we can reference.

AI Can Be Useful Without Automating Everything

The shared Google Drive also contains records from our home renovations. We moved into our house two years ago, replaced all of the appliances and have continued renovating other parts of the house. That creates receipts, purchase records and other information that we do not need every day, but when one of us needs something, we want to be able to find it.

This is another area where I think people sometimes make AI sound more complicated than it needs to be. Claude does not have to autonomously perform some huge business process for it to be useful. Sometimes the value is simply taking information you already have and making it easier to find, organize and understand.

When my partner asks me for something related to the house, an appliance, a receipt or a project we have completed, being able to get to the information we already saved without digging through years of folders is useful. There does not need to be anything more futuristic about it than that.

I Still Use Claude for Technical Work Too

The automation workflows get most of the attention in this article, but I also use Claude for normal technical work. I use it when I am troubleshooting problems, working through PowerShell, developing Microsoft Graph scripts and thinking through Microsoft 365 configurations. It can be incredibly useful for helping me work through a problem, build the starting point for a script or look at different ways to accomplish something, but that does not mean I blindly take what Claude gives me and run it against a client's production environment.

I actually maintain my own Microsoft 365 test tenant specifically so I have somewhere to test this kind of work. I even have a laptop dedicated to that test environment. If I am working on a PowerShell or Microsoft Graph script, testing a configuration change or trying to understand how different Conditional Access policies are going to behave, I would much rather find out what happens in my own testing environment before I make that change for a client. I can try different configurations, see what happens, make mistakes, change things and test again without turning a client's business into my testing ground.

For me, maintaining that separate environment is worth the additional time and expense because I hate making a change that breaks something for a client. There is always going to be some risk when making changes to technology, and a test environment cannot perfectly reproduce every client's configuration, licensing, users, applications or business requirements. I do not pretend that testing eliminates that risk. What it gives me is a place to understand how something behaves, identify obvious problems and get a much better feel for what I am about to implement before I touch a production environment.

Conditional Access is a good example. A policy can look perfectly reasonable when I am reading through the settings, but I want to understand what the actual user experience looks like and what happens under different conditions. My test tenant gives me somewhere to work through those scenarios before I start designing or implementing something for a client. The same principle applies when Claude helps me develop PowerShell or Microsoft Graph scripts. AI generated code is still code. I need to understand what it is doing, review it and test it appropriately before I decide whether I am comfortable using it.

This really comes back to the same principle I use throughout my AI environment: I do not assume. I test. I test Claude's instructions and guardrails with fake information. I test my automations with different inputs and wording. I test scripts before using them in production. I test Microsoft configurations and Conditional Access behavior in my own tenant before applying what I have learned to a client's environment. I would much rather break something in my testing grounds, figure out why it broke and fix it there than learn that lesson for the first time in a client's production environment.

A polished AI response is not automatically a correct answer, and a configuration that looks right on paper is not automatically the right configuration for a particular business. Claude can help me research, troubleshoot, write and think through technical work, but I am still responsible for understanding, testing and ultimately implementing what I decide to use.

Why I Keep Refining the Workflows

This is probably the biggest difference between the article I wrote in May and the article I am writing now. Back then, I had built the system. Now I have actually lived with it.

I have had workflows that worked well during testing and then ran into situations I had not accounted for. I have changed instructions because a particular type of input produced the wrong output. I have adjusted schedules. I have changed the way I enter information into my calendar. I have created dedicated mailboxes because giving the automation a predictable source was better than making it hunt through unrelated information. I have added rules for exceptions and tested those rules again.

I also deliberately try to break things before I depend on them. That does not mean I can prove I have found every possible failure. I cannot. What it does mean is that I am actively looking for the conditions where a workflow behaves differently than I expect instead of assuming that because something worked five times it will work forever.

That experience has influenced how I build AI environments for clients too. In How I Set Up Claude Teams for a Small Business Safely, I talk about a small business where I keep my own license in its Claude environment specifically so I can continue refining projects and skills as employees find situations the original instructions did not handle the way we expected.

I do not think a business should assume an AI workflow is finished simply because it worked during initial testing. AI systems change. Business processes change. Employees find new situations. Instructions that worked for the examples you originally tested may need to be refined when the workflow meets something you did not anticipate.

That does not necessarily mean the automation failed. It means it needs to be managed.

My Boundaries Are Deliberate

There is an important distinction I want to make here. The boundaries I have described throughout this article are my boundaries for SNL Tech Services. I am not presenting them as universal Anthropic requirements.

I decided Claude does not get credentials to my clients' portals. I decided certain information does not belong in the runbook workflow. I decided invoices do not get sent without me reviewing them. I decided exceptions in mileage and receipts come back to me. I decided Claude documents my test restore results instead of performing the test restore itself. I decided to use a dedicated computer for part of my AI work. I also decided to test the rules I created instead of simply assuming Claude would follow them under every variation I could think of.

Those are governance decisions.

There is also a difference between a behavioral rule and a technical boundary. Telling an AI system not to use a credential is a behavioral instruction. Not giving it the credential in the first place is an access decision. I use both types of controls where they make sense, but when something truly does not need to be available to the workflow, I prefer removing the access rather than depending entirely on an instruction telling the AI not to use it.

That is why I keep coming back to the same idea. I do not need to give AI access to everything just because I can connect another system.

I need to give it enough to do the job I actually want it to do.

What Does This Have to Do With AI Governance?

Pretty much everything.

AI governance can sound like something only a huge corporation needs. In practice, much of what I am doing in my own business is governance. I am deciding which systems AI can access. I am deciding which information stays outside of it. I am deciding what can run automatically, what gets flagged and what requires my approval. I am deciding how often something needs to run. I am testing whether instructions actually produce the result I expect and whether the boundaries I established behave the way I intended. When the business process changes, I update the workflow.

The technology matters, but the decisions around the technology matter just as much. That is also why AI governance is becoming an important part of the conversations I have with small businesses. If a company is going to use AI intentionally, somebody needs to decide what is approved, what information is appropriate, what access the technology receives and where human review belongs.

This is also why I do not think responsible AI adoption begins with picking whichever AI product is getting the most attention that month. It starts with understanding the business and the environment underneath it. My Business IT Solutions include AI governance as well as Microsoft 365 tenant audits and other assessments because those pieces increasingly overlap.

Why I Built This Before Offering AI Automation to Clients

One part of the original article that I still completely stand behind is why I built all of this in my own business first.

I do not want to recommend an AI workflow to a small business because I saw an impressive demo or read that a product can technically do something. I want experience with what happens after the demo. I want to know what happens when a workflow encounters information it was not expecting. I want to know how much instruction tuning it takes, where the annoying parts are, what needs human review and whether the thing actually saves enough time to justify maintaining it.

This environment made SNL Tech Services my test bench.

That does not mean I would copy everything I have built and install it for another business. I would not. A construction company, law firm, veterinary practice, accounting office or other service business has different information and different workflows. The useful part of my experience is understanding how to look at a repetitive process, determine whether AI belongs in it, identify what information the automation actually needs and establish where it should stop.

That is much more valuable than simply knowing how to turn on a connector.

What Could AI Automation Look Like in a Small Business?

I do not think the first question should be, “What can Claude automate?”

I would start with what is consuming time. Maybe it is a report somebody manually builds every Monday. Maybe it is receipts. Maybe employees spend an hour every week gathering information from several places before a meeting. Maybe somebody is repeatedly turning rough notes into the same type of document. Maybe the owner is worried that important information is getting buried in email.

Once I understand the problem, then I can ask the technology questions:

• Where does the information live?

• What does the AI actually need access to?

• Does it need to read information, write information or simply receive a notification?

• What happens if the information is incomplete or wrong?

• What should be flagged instead of automatically acted upon?

• Where should a person review or approve the work?

• How will we know if the workflow stops working correctly?

• What happens if somebody tries to give it information it should not have?

• Who is responsible for testing and maintaining the workflow as the business changes?

That is the part of AI automation I find interesting. I am not trying to replace the person responsible for the work. I am trying to remove repetitive work around that person so they can spend more time on the part that still needs their experience and judgment.

Frequently Asked Questions About Claude Cowork for Small Business

What is Claude Cowork?

Claude Cowork is Anthropic's agentic work environment for general knowledge work. Rather than only responding to individual prompts, it can work through multi-step tasks involving files and connected tools. Anthropic also currently supports projects and scheduled tasks in Cowork. The product continues to evolve, which is one reason I periodically review my workflows and the product documentation rather than assuming the way it worked several months ago is still exactly how it works today.

Does Claude Cowork run inside a virtual machine?

Cowork uses a virtual machine as part of its containment architecture, but the answer is more nuanced than simply saying Claude runs inside a VM. Anthropic's May 2026 engineering documentation says code execution remains isolated inside the VM, while the agent loop and local MCP servers now operate outside it. That is different from Cowork's original architecture and is one of the technical details I corrected when updating this article.

Do scheduled Claude Cowork tasks require the computer to stay on?

Anthropic's current documentation says scheduled Cowork tasks run in the cloud and do not require the computer to remain awake or the desktop application to stay open. My decision to maintain a dedicated computer for my own AI work is therefore an architectural and organizational choice I made for SNL Tech Services, not a requirement for scheduled Cowork tasks.

Why do you use a dedicated computer for Claude Cowork?

I wanted additional separation between my everyday work computer and the environment I use for AI automation and experimentation. It gives me a machine with a very specific purpose and keeps that work separate from the computer I use for normal client work. I am not suggesting every business needs to duplicate my setup.

Does Claude have access to your clients' Microsoft portals?

No. Alerts from client Microsoft environments are sent to a mailbox I created for that purpose. Claude can help organize and surface those notifications, but it does not log into the clients' Microsoft portals. If an alert requires investigation or a change inside a tenant, I handle that myself.

Does Claude have access to your clients' backup portals?

No. Claude works from the backup information and notifications I make available to the workflow. I access the client backup environments myself when technical work needs to be performed.

Does Claude perform your quarterly backup test restores?

No. I personally go into each client's backup environment and perform the test restore. I verify the result and provide that information to Claude so it can be incorporated into the quarterly documentation. Claude helps me maintain the record. It does not perform or verify the restore.

Do you give Claude client passwords or administrative credentials?

No. I deliberately keep usernames, administrative credentials, passwords, passkeys, API keys, secret keys, SSH private keys, authentication tokens, recovery information, encryption keys, IP schemes and other categories of sensitive access information outside the runbook workflow described in this article.

Can instructions prevent someone from putting sensitive information into AI?

Instructions can establish rules for how a workflow should behave, but I do not treat prompt level instructions as equivalent to a technical security control. In my own workflows, I combine instructions with deliberate access limitations and testing. For systems Claude does not need to access, I prefer not giving it the credentials or access in the first place.

Do you test your AI guardrails?

Yes. I use fake information to test how my workflows respond when information I have prohibited is presented in different ways. I change wording and phrasing and try different approaches. That helps me identify weaknesses in my own instructions and workflow design, but I do not treat successful testing as proof that a prompt based guardrail can never fail.

Do you test AI generated PowerShell and Microsoft Graph scripts?

Yes. I maintain my own Microsoft 365 test tenant and have a laptop dedicated to it. When appropriate, I can use that environment to test scripts, configurations and Conditional Access behavior before applying what I have learned to a client's production environment. The test tenant cannot reproduce every client's environment perfectly, but it gives me somewhere to test, learn and break things without using a client's production environment as my testing ground.

Can Claude help track business mileage?

It helps with the workflow I built, but the quality of the result depends heavily on the information I provide. I structured my calendar, record which truck I use, color code client information, route gas receipts to a dedicated mailbox and use rules for discrepancies that need my review. The automation works because there is a process underneath it.

Does AI automation eliminate the need for human review?

Not in the way I use it. Client reports are reviewed. Invoices are reviewed. Security alerts come to me for investigation. I perform backup test restores myself. Mileage exceptions are flagged. Scripts and Microsoft configurations are tested before I decide whether to use them. Automation saves me from repetitive preparation and organization, but I remain responsible for the work.

Do AI automations need ongoing maintenance and testing?

Based on my experience, yes. I have changed instructions, schedules, input structures and exception rules as I discovered how workflows behaved with real information. I also test different inputs and scenarios rather than assuming the first successful result means the workflow is finished. Business processes change, AI products change and the workflows built around them need to be reviewed accordingly.

What I Have Learned From Actually Living With AI Automation

When I built this computer, I thought the interesting part of the story would be the automation itself. A few months later, I think the more interesting part is everything I had to learn after I turned it on.

The system works extremely well for me now, but getting there required testing, troubleshooting and changing things. I had to make some instructions more specific. I had to change some of my own processes so the information going into the automation was consistent. I had to decide which things should run daily, monthly, quarterly or hourly. I had to identify places where Claude should prepare something and stop rather than completing the final action. I also had to test the rules I created and try to get around them instead of assuming they would always behave exactly the way I intended.

Most importantly, I had to decide what I did not want to automate.

That is why I do not think responsible AI automation is about seeing how much control you can hand to an AI agent. I think it is about looking carefully at a business process and figuring out where AI genuinely makes the process better, what information it needs to do that, what boundaries should exist around it and where a person still belongs.

For me, that has meant fewer repetitive administrative tasks, a much better morning view of my business, cleaner records, better reporting and less time digging through information I already have.

And my coffee is usually still cold, but at this point that is my fault.

Ready to Look at AI Automation in Your Business?

If you are running a small business and there is a repetitive process eating up time every week, I am happy to look at it with you. I do not start by assuming Claude, ChatGPT, Copilot or another AI platform is automatically the answer. I want to understand what you are doing now, what information the process uses, where that information lives and what you would actually like technology to take off your plate.

Sometimes the answer may be AI automation. Sometimes the better answer may be fixing the process first. Sometimes the right answer is that a particular task should stay exactly where it is.

If you want to see how I applied some of these same principles when helping another small business move from individual AI use to a managed company environment, read How I Set Up Claude Teams for a Small Business Safely. If you are considering connecting AI to Microsoft 365 and are not sure what is already configured underneath it, you can also learn more about my Microsoft 365 management approach and my Microsoft 365 Audit and other business IT assessments.

If you want to talk about AI automation, AI governance or how these tools could fit into your own business, contact SNL Tech Services.

ADDITIONAL RESOURCES

Anthropic | How We Contain Claude Across ProductsAnthropic's May 2026 engineering explanation of its containment architecture, including the evolution of Claude Cowork's VM architecture, access boundaries and the difference between behavioral safeguards and containment. How We Contain Claude Across Products

Anthropic | Get Started With Claude CoworkAnthropic's current overview of Cowork, including permissions, security, scheduled tasks and how current Cowork sessions operate. Get Started With Claude Cowork

Anthropic | Use Claude Cowork SafelyAnthropic's current safety guidance for Cowork. This is particularly relevant to the decisions I discuss in this article around scheduled tasks, sensitive information, human oversight and reviewing what automated workflows actually do. Use Claude Cowork Safely

Anthropic | Schedule Recurring Tasks in Claude CoworkAnthropic's documentation covering scheduled Cowork tasks, including the use of connected tools, skills and plugins and the fact that scheduled tasks currently run in the cloud. Schedule Recurring Tasks in Claude Cowork

Anthropic | Organize Your Tasks With Projects in Claude CoworkAnthropic's current documentation explaining Cowork projects, including project specific instructions, context, memory and scheduled tasks. Organize Your Tasks With Projects in Claude Cowork