The way we think about automation is starting to change.
For years, automating work usually meant building something outside of the person doing the work. You connected systems with a tool like Zapier or n8n, built an internal application, or created some other workflow that could handle the process consistently.
That approach still makes sense for plenty of business processes. But AI tools that can work directly across an employee’s files, applications, and connected systems are creating another option.
Instead of turning every useful process into a centralized workflow, more automation can potentially live with the individual doing the work. There is also an interesting middle ground emerging between a one-off AI task and a fully centralized company automation.
Personal Automation
Consider something pretty normal: preparing for a client meeting.
I might need to review recent emails, find the latest project files, check outstanding tasks, look at previous meeting notes, and pull the useful information into a briefing.
Traditionally, automating that process could become a project of its own. Someone would need to connect email, project management, file storage, and possibly the CRM. Rules would need to determine which information matters, and the resulting briefing would need somewhere to live.
A personal AI environment changes the equation. If the agent already has access to the systems I use, I may be able to ask it to prepare me for tomorrow’s client meeting and let it assemble the process based on the context available to me.
My permissions determine what it can access. My files and communications provide the context. The agent handles much of the interpretation required to complete the task.
That is what I mean by personal automation. The workflow does not necessarily need to exist as permanent infrastructure before the task can be automated.
Shared Automation Works Differently
Now consider an automated lead-routing process.
A lead comes through the website. The system checks the CRM, applies qualification rules, determines ownership, assigns the lead, and records what happened.
That process belongs to the organization. It should behave consistently regardless of who is working. Failures need to be visible, changes to routing logic need to be controlled, and the process must continue operating when employees change.
This is much closer to the traditional automation model. The organization owns the workflow and the environment where it runs.
Both approaches are useful. The more interesting question is deciding which model a particular process actually requires.
Personal, Packaged, or Centralized?
| Model | Where the method lives | Where context lives | Good fit |
|---|---|---|---|
| Personal automation | With the individual | Individual workspace | Flexible knowledge work and situational tasks |
| Packaged personal automation | Shared across the organization | Individual workspace | Common methods applied to different personal contexts |
| Centralized automation | Shared infrastructure | Company systems | Reliable operational processes requiring control |
There Is a Missing Middle
The part I find most interesting sits between personal automation and centralized automation.
Imagine an account manager develops a useful process for preparing client account reviews. The agent looks at recent communication, reports, open tasks, project notes, and other relevant material. Through repeated use, the employee improves the instructions and gets increasingly consistent results.
Eventually, the process works very well.
The obvious next step might be to turn the workflow into a centralized application or build it in an external automation platform. That may be unnecessary.
The company could package the method instead.
Other account managers could receive the same skill, agent configuration, template, or set of instructions. Each person would run the method inside their own AI environment, using the files, permissions, clients, and applications available to them.
The organization shares the logic while the execution context remains localized to each user.
From Personal Workflow to Packaged Automation
This creates a different path for how automation can develop inside an organization:
1. Start With a Real Problem
An employee begins using an AI agent to help with recurring work. There may not be a formal workflow yet. The person experiments with instructions, different information sources, and different ways of approaching the task.
This is a useful place for automation to begin because the person building it already understands the work. There is very little distance between the problem and the experimentation.
2. Prove the Method Through Use
Repeated use starts revealing a consistent approach. Certain instructions keep showing up, the desired output becomes clearer, and common mistakes become easier to identify.
At this point, something more valuable than a good prompt has emerged: a working method tested against real situations rather than designed in the abstract.
3. Package What Is Repeatable
The reusable portions can become a skill, agent configuration, template, or structured set of instructions that other employees can adopt.
Another employee no longer has to recreate the process. They can start with a method that has already been proven, while the agent still works against their own information and access.
Sharing the automation does not require centralizing the context.
4. Centralize When the Requirements Change
Some packaged personal automations will eventually need to move into shared infrastructure.
A process may need to run every night regardless of user input, or it may begin changing financial records, require reliable retries, or demand standardized logging and approvals.
Those requirements provide a reason to centralize the workflow. Popularity alone does not.
A useful personal automation can remain personal even after the method becomes widely shared.
Why This Matters for Traditional Automation
This model could reduce the amount of external automation companies need to build.
Many lightweight workflows exist because software has historically required us to define almost everything ahead of time. A system needed to know where data comes from, how decisions are made, and where outputs go.
AI agents can interpret parts of the environment while the task is being performed. That makes some workflows possible without building permanent integrations for every step.
Meeting preparation is a good example. A centralized version could require connections across email, calendar, CRM, project management, and file storage. A personal agent may already have access to most of those systems through the user.
When that is the case, the economics of building another workflow change. The question becomes less about whether the process can be automated and more about whether the organization needs to own the execution.
What Should Stay Personal?
Personal automation is a strong fit when the work depends heavily on individual context and human review remains part of the process.
Meeting preparation, research, document review, account analysis, content preparation, and project organization all fit this pattern. The method may be consistent even though the inputs change constantly.
Agents are particularly well suited to situations where interpreting available information is part of completing the task.
What Should Become Centralized?
A different standard applies when the process becomes operationally critical.
Payroll processing, system synchronization, financial transactions, customer-facing workflows, and compliance-heavy processes should not depend on individual initiation.
The more a process requires guaranteed execution, controlled permissions, consistent results, or centralized visibility, the stronger the case for shared infrastructure.
| Question | Leans personal | Leans centralized |
|---|---|---|
| Does individual context improve the result? | Strongly | Minimally |
| Does a person review the output? | Usually | Rarely |
| Must it run without user involvement? | No | Yes |
| Does it update a critical system of record? | Rarely | Frequently |
| Is centralized logging important? | Limited | High |
| Must every employee get highly consistent results? | Some variation is acceptable | Consistency is required |
A Different Automation Strategy
Companies may eventually manage automation as a portfolio rather than a collection of workflows.
Some work will be handled by personal agents. Some methods will be packaged and distributed while execution remains local. Other processes will continue to run through centralized systems.
This changes the questions worth asking before building automation:
Does the process depend heavily on personal context? Can the output be safely reviewed before action is taken? Could a shared method solve the problem without centralizing data? Does execution need to run independently of a person?
The answers determine how much infrastructure is actually necessary.
Automation May Become Something We Distribute
Software has traditionally been distributed as applications, while automation has been distributed as centralized workflows. AI agents introduce a third option: distributing methods that run inside each employee’s environment.
A useful way of working is developed, tested in real use, and then packaged so others can apply it using their own systems, permissions, and context.
For a large portion of knowledge work, that may be enough.
As AI environments become more capable, some automations that once required dedicated systems may no longer need to be built at all.
The better strategy may sometimes be to package the method and let the work stay with the person who already has the context.
