There is a way of understanding productivity with artificial intelligence that seems fairly straightforward: if a task used to take two hours and now takes twenty minutes, we have gained an hour and forty minutes.
That calculation works for a task in isolation. When you start working with several agents and many simultaneous projects, other things need to be counted too.
In my experience, two factors combine. The first is agentic organisation: I can keep ten or twenty projects running in parallel. The second is response time. I give an instruction and the answer may arrive thirty seconds later or half an hour later.
While I wait, I can do something else. And that is exactly what I do.
I open another project, review a result, give another instruction. Then I return to the first, or an answer arrives from the third. Added to that are tasks whose full course takes hours, days or weeks.
AI allows me to set much more work in motion. But that work comes back.
It comes back as a proposal I must read, a decision I have to make, a test I need to check or a question that requires recovering the context.
While I wait, I open another front
Making use of waiting time makes sense. If an agent needs twenty minutes to prepare something, I do not have to sit staring at the screen.
The problem appears when I repeat that decision many times. Each additional assignment opens up an opportunity to make progress, but it can also create a future obligation to review.
Moreover, answers do not necessarily arrive in the order I requested them. A short task can get stuck. Another may finish sooner than expected. Several may demand attention at almost the same time.
Two clocks coexist here: the time the system needs to produce a result and the moment when I can deal with it.
For each assignment, waiting determines the next step. For the projects as a whole, my attention can become the scarcest resource.
Thirty seconds and thirty minutes are different kinds of waiting
Nor can every wait be put to use in the same way.
Thirty seconds can be enough to break the rhythm, but too little to really get into another activity. Thirty minutes allow progress on another project, although afterwards you have to return to the previous one.
And returning requires more than opening a window.
What exactly had I asked for? Which version are we reviewing? What decision did we make earlier? Why did we reject that alternative? Does this result fulfil the assignment or does it merely look good?
That effort of reconstruction is also part of the work.
That is why I am interested in distinguishing between execution time, review time and the time needed to get my bearings again. If we only measure how long AI takes to respond, we leave out an important part of the experience.
Producing more can also mean having more left to do
A study published by Anthropic on 16 October describes how work changes within the company itself as the use of agents spreads. Its observations include pressure on human attention and the growth of tasks devoted to organising, supervising and coordinating these systems.
It is an internal study, conducted in a company with particular characteristics. Its results cannot be turned into a general law for all organisations. But it raises an issue I recognise in my own experience: increasing agents' output also increases the need to manage what they produce. Source: How employment is changing at Anthropic.
An answer finished by AI may still be unfinished work for me.
It still has to be checked, assessed for usefulness, integrated into the project and, sometimes, sent back for correction. If results arrive faster than I can do these things, the backlog moves elsewhere.
Previously, I might have been waiting for the work to be produced. Now I may have completed output waiting for my attention.
Twenty projects need more than memory
This leads to an organisational question: how do you keep twenty projects moving without losing information, forgetting decisions or leaving things stalled for days?
A project can stop without anything technically failing.
The agent has finished its part. An answer from me is missing. I am busy with something else. Nobody takes up the next step.
The information may also exist but be scattered across conversations, documents and versions. Recovering it is possible, although each recovery forces me to investigate my own work.
Saving conversations helps. Maintaining continuity requires knowing what they mean for the project's current state.
I need to be able to identify what we want to achieve, what has been completed and checked, what is missing, who needs to act and what is blocking progress. If something is waiting, I also need to know when it should be looked at again.
A history tells us what happened. Organisation should help decide what happens next.
This is where Alonides comes in
This need connects with Alonides, the project I am building.
My approach is to have a single point of contact: an AI bot that knows and coordinates all my projects. I can speak directly to the bots working on a particular matter or turn to my coordinator, Alonides.
In the latter case, I want Alonides to distribute my instructions, check that they are carried out and give me feedback on results, obstacles and decisions that need my involvement. That way, I can alternate between going into the detail of a project and directing the whole from a single conversation.
That is the system I am building: keeping the option to intervene directly, while being able to delegate day-to-day follow-up to a coordinator who maintains the overall picture. So that it does not depend on me remembering who I assigned each thing to and asking again how it is going.
It is a development goal. We need to check in practice which parts work and which still need intervention.
For me, an important test will be the ability to leave a project, work on other matters and return to it without reconstructing its entire history. Another will be detecting that something has been stalled for too long and understanding why.
It also matters to distinguish between an executed task and a verified result. If the system presents both as equivalent, it hands back to me the burden of finding out what is actually finished.
An organiser can overwhelm you too
Centralising every alert does not by itself solve the attention problem. It can concentrate it.
If every small advance generates a notification and every uncertainty becomes an interruption, I end up working to the rhythm of the system's calls.
The organisation I need has to distinguish what requires an immediate decision, what can be grouped for later review and what can continue within the limits already agreed.
That also means accepting limits on simultaneous work. Being able to open twenty projects does not mean it is wise to keep twenty matters demanding decisions at once.
Sometimes, the organiser's best contribution will be helping me finish something before opening another front.
Productivity is tested at completion
That is why I want to look at more than the speed of answers.
I want to know how many results are accepted and usable, how much time I spend correcting them, how many matters await a decision from me and how often I have to recover information that should be at hand.
I do not yet have a definitive formula. I do have an increasingly concrete question: am I managing to finish more work, or simply to keep more work open?
Agents' capabilities expand what I can attempt. Making use of them also requires organising the moments when they wait, the moments when I wait and the moments when I need to concentrate in order to decide.
That is a central part of what I want to solve with Alonides.
I have learned to make use of the time when AI is working. Now I have to learn to protect the time when it is my turn to think.
Sources and further reading
Text by Roberto Ortega, prepared with AI editorial assistance. The Norwegian and English editions are editorial adaptations of the Spanish original.
