There is a point at which building a small piece of software feels cheaper than explaining the problem to somebody else. Connect enough agents, tools and context, and that point spreads to research, administration, analysis and the management of the agents themselves.
It feels like a superpower. It can also create an extraordinary amount of rubbish.
I have called the first feeling the Matrix moment: the realisation that many things which used to be implausible are now merely tasks. This series has followed the path towards it, from working with one coding agent, through letting go of individual actions, to parallel agents and the factory which builds the software. The final lesson is not how to automate everything. It is how to decide which new possibilities deserve to survive.
Abundant Execution Meets Finite Attention
Code can become cheaper without software becoming free.
Every new system still occupies a name, a security boundary, a deployment, a set of dependencies and a corner of somebody’s understanding. It creates decisions about ownership, data, failure and retirement. An agent can generate the first version in an afternoon, but the organisation may operate it for five years.
The same applies outside engineering. Reports, proposed projects and monitored channels may all become cheaper to produce while leaving us with more material to judge, a larger portfolio to choose between and more exceptions to handle. Automation often moves effort away from execution and into selection, verification and maintenance. Those costs are less visible because they arrive later and are spread across people.
This is the human limit underneath the technical progress. We can add model calls, machines and background workers. We cannot add hours to the day at the same rate. Attention remains the resource deciding which failures are noticed and which opportunities are pursued.
The human coordination ceiling is therefore not solved by an orchestrator. The queue moves upwards. Instead of coordinating individual edits, we coordinate goals, exceptions, budgets and the consequences of systems which continue while we are elsewhere.
When the Agent Never Goes Home
Always-on agents make this trade-off unusually clear.
Google Cloud Platform’s open-source Always On Memory Agent is a small demonstration of the pattern. Its current README describes a process which watches an inbox, stores structured memory in SQLite, periodically consolidates new memories and answers later queries. By default, the consolidation loop runs every 30 minutes. It is a reference implementation, not evidence that autonomous memory remains accurate or useful at personal or organisational scale.
Still, the direction is easy to imagine. Give an agent access to a folder of notes and it can surface related ideas. Add a calendar and it can propose time for them. Add email and it can draft the conversation. Add authority and it can send the message, move the meeting or commission another agent to build the idea.
Each step increases usefulness. Each step also changes the risk.
Reading notes can expose private material to a model provider or an accidentally broad log. Consolidating them can turn an uncertain interpretation into persistent “memory”. Connecting unrelated notes can reveal a useful pattern, or manufacture one. Calendar access exposes relationships and routines. Sending messages lets an error affect other people. Payment, deployment or identity permissions turn a mistaken inference into an external event.
The important boundary is not whether the agent is running in the background. It is what the background process may observe, remember and do.
Memory Is Not Truth
A personal knowledge base is attractive agent infrastructure because it contains the context missing from a short prompt. Priorities, decisions, projects and previous arguments can all become available without repeating them in every session.
But a vault is not a clean database of facts. It contains abandoned plans, speculative notes, contradictory opinions and statements that were true two years ago. Human memory has similar problems, of course. The difference is that an automated system can repeat a stale interpretation at machine speed and attach actions to it.
An agent which searches a vault should preserve provenance. Which note supports the answer? When was it written? Was it an observation, a decision or an idea? Did a later note reverse it? If the system writes a consolidation, we should be able to distinguish that generated interpretation from the original material and delete or correct it without archaeology.
The maintenance work is not optional:
- credentials and connectors expire or gain new scopes;
- model behaviour changes;
- instructions accumulate contradictions;
- retained data creates privacy and legal obligations;
- scheduled jobs fail, loop or spend money quietly;
- summaries drift away from their sources;
- nobody remembers why an automation was allowed to act.
An always-on system also needs an off switch which works when the model does not. Rate limits, cost ceilings, timeouts, audit logs and revocable credentials belong outside its reasoning loop. The more personal the context, the less comfortable I am with “the prompt says not to do that” as the main control.
Separate Thinking From Acting
Some of the best uses of agents do not require much authority.
Searching a large body of notes for repeated themes, contradictions or forgotten work can extend our ability to think. The agent can propose a connection and show its sources. We can disagree. The value comes from exploring a space too large to hold in working memory, not from pretending the system knows us better than we know ourselves.
Action needs a different standard. A useful default is progressive authority:
| Mode | What the agent does | Sensible boundary |
|---|---|---|
| Observe | Search, compare and identify possible patterns | Read-only sources, citations and no external side effects |
| Propose | Draft a plan, message or change | Human chooses whether the proposal represents their intent |
| Prepare | Create a reversible artefact in an isolated workspace | Independent checks and a clear diff before acceptance |
| Act | Change an external system | Narrow credentials, explicit policy, audit and tested recovery |
| Operate continuously | Repeat actions without a fresh prompt | Budget, stop conditions, exception routing and a named owner |
There is no shame in stopping at “propose”. A calendar assistant which suggests three slots may provide nearly all the value without gaining permission to rearrange somebody else’s day. The same boundary lets a research agent assemble evidence without publishing the conclusion, or a coding agent prepare a deployment without holding production credentials.
We should automate the part whose correctness we can evaluate, then make the remaining decision visible. Removing the final click needs a policy which explains when the system may proceed and when a person must decide.
The Automation Test
Before building an automation, I would write down six answers.
What recurring problem does it remove? “We can build it” is not a problem statement. If the task happens twice a year and takes ten minutes, the automation may never repay its maintenance.
What happens when it is confidently wrong? Consider the affected people and data, not only whether the process throws an exception. A polite but incorrect email is still an incident for the recipient.
Can success be checked independently? Tests, reconciliation, source citations and observed outcomes give an agent something better than its own confidence to work against. If success is mainly taste or an unresolved strategic choice, assistance is a better fit than autonomy.
Is the action reversible? Drafting a file in a disposable branch is different from deleting records, spending money or speaking publicly in somebody’s name. Irreversibility should pull authority back towards a person.
Who will operate it next year? Include inference cost, connector changes, incident response, documentation, data retention and eventual deletion. A weekend build without an owner is a future support request.
What will we stop doing to make room for it? This is the question abundance encourages us to avoid. Every worthwhile new capability still competes with another project and with the attention required to live outside the backlog.
The answers lead to a fairly ordinary portfolio:
- Automate repetitive, bounded and reversible work with cheap verification.
- Use agents to prepare or analyse work which needs judgement.
- Keep ambiguous, relational or irreversible decisions human-owned.
- Delete automations whose ongoing value no longer exceeds their operational cost.
The boundary will move as our checks improve. That is healthier than declaring autonomy as the destination for every task.
What I Would Not Automate
I would be very cautious about delegating decisions whose value lies in accepting responsibility: telling somebody they are no longer needed, resolving a conflict between people, choosing a medical or legal risk, publishing a personal position, or deciding which part of a life deserves more time.
An agent can gather evidence, expose options and draft language. It may reveal an assumption we missed. But making the final decision is not merely an inefficient calculation. It creates a relationship between the decision-maker and the consequence.
I would also reject automation which exists only to compensate for a broken process. An agent that copies fields between two systems may be a useful temporary bridge. Left in place, it can preserve the duplication and make the real simplification less urgent. Cheap glue has the same tendency as cheap code: it accumulates until nobody knows which pieces are load-bearing.
Finally, I would not keep an agent running simply because idle agents feel wasteful. Compute can be available while there is no worthwhile work to do. Maximising utilisation is a factory objective; it is not a life objective.
After the Matrix Moment
The four parts of this series describe a repeated movement: learning to work with an agent, replacing supervision with constraints, coordinating several agents and eventually building systems which coordinate them for us. At every stage, a human bottleneck is removed and a more consequential one appears.
The current evidence does not tell us where that progression ends. Formal verification may make stronger guarantees economical for more generated components, or remain practical only for selected cores. Some AI-native organisations may build better small teams while others produce enormous queues of poorly understood change. Persistent personal agents could become trusted tools, though they bring privacy and memory risks of their own. Most likely, outcomes will differ by domain and by how seriously we treat the boundaries.
The Matrix moment is real in one modest sense: the cost of trying has fallen enough that many ideas can become prototypes. That is worth enjoying. It is not the same as saying every prototype should become a product, every suggestion should become a decision, or every part of ourselves should become available to a machine.