This recent wave of Personal Agent has brought back some of the feeling I had when I was tinkering with OpenClaw.
Especially while using Grok Bot recently to coordinate Agents, I have run into a problem that keeps recurring across all kinds of AI tools:
AI really likes to assign itself tasks according to the working rhythm of a human team.
For example, ask an Agent to plan a project, and it will readily produce a plan like this:
Complete requirements research in week one, settle on an approach in week two, develop in week three, and test and deliver in week four.
Every time I see a schedule like this, it drives me a little crazy. So much of the work can clearly be done right now. Why schedule it for weeks later?
If the goal is clear and the tools and permissions are in place, AI can produce a first version of many tasks in tens of minutes or a few hours. Why must settling on an approach wait until week two, and development until week three?
And this is not just about development tasks. Similar problems often appear in marketing, content production, and market research.
Work that could move forward continuously gets spread by the Agent across a schedule spanning several weeks. This seriously affects the efficiency of autonomous operation.
AI already has an execution speed different from ours, but the way it plans work seems to remain in the era of human teams.
When Incorrect Time Estimates Become Actual Work Schedules
There are actually two different problems here.
The first is inaccurate estimation.
Suppose an Agent tells me a task will take two weeks, but actually finishes it in three hours.
That certainly shows its estimate was inaccurate. But as long as it keeps moving forward based on actual progress, the work can still be completed ahead of schedule.
In this case, the main problem to solve is how to help AI understand its own execution capabilities more accurately.
The second is when incorrect estimates begin to affect how tasks move forward.
The Agent creates a two-week plan, and a human accepts it. The work that follows then starts to conform to that arrangement.
The first phase is clearly finished, yet the next task is still listed under “next week’s work plan.”
If no one asks again, work that could move forward immediately may be delayed because of the dates in the plan.
The first problem affects expectations; the second affects actual productivity.
I do not want to have to keep reminding and questioning an Agent: “You can do this right now. Why wait until next week?”
Even less do I want large numbers of tasks that are already ready for execution to sit idle simply because I did not check the plan in time.
What Exactly Is the Agent Waiting For?
In my earlier essay, After Managing 31 AI Employees, I Came to Understand Management Anew, I mentioned something I had noticed:
With the arrival of AI, organizational structures will gradually become an hourglass. At the top is an endless stream of ideas and goals. At the bottom are AI execution capabilities that are increasingly powerful and easy to scale. And the narrow part in the middle turns out to be people.
Human energy, attention, and decision-making efficiency may become the bottleneck limiting the operation of the entire system.
In the actual process of managing Agents, some tasks do indeed need to wait for feedback.
For example, whether to spend money, whether to allow something to go live, or whether a piece of content can be published externally—these matters involve risk and responsibility, and still require human judgment. Some work also genuinely needs to wait for data from the real world as feedback.
After a piece of content is published, how do its views and conversion rate change? After a product launches, are users actually willing to use it? These results will not appear immediately just because AI executes faster.
So I began trying to divide time at work into three kinds:
- Machine execution time: Research, analysis, development, writing, testing, and other work that AI can complete directly should be scheduled according to its actual execution capabilities.
- Human decision time: For matters requiring approval or judgment, people should be told clearly what decision is currently missing and what risks are involved.
- Real-world feedback time: When waiting for results from users, the market, or external systems, the Agent should explain what it is observing and what conditions must be met before it can continue.
These three kinds of time are completely different in nature.
But if an Agent simply says, vaguely, “We’ll continue next week,” I cannot tell:
Does it still have unfinished work? Is it waiting for me to make a decision? Is it waiting for market feedback? Or is it stuck somewhere in the process?
This makes the entire collaboration process very awkward.
AI was supposed to move work forward proactively, with people stepping in only when necessary. Instead, people end up constantly checking on, chasing, and rescheduling AI.
A good Agent work plan should not be a static timetable, much less a black box. I need to know what it has completed, where it is stuck now, and what exactly the next step is waiting for. This is a process that changes dynamically.
Of course, automatic scheduling and continuous operation are a separate issue. But even if an Agent already has the ability to execute autonomously, the entire system will still struggle to operate efficiently if the initial plan contains large amounts of unnecessary waiting.
Why Does AI Keep Using Human Timetables?
Most of the project management methods we know were built around human working capabilities. Eight hours a day, five working days a week, a two-week Sprint. People need to communicate, attend meetings, and rest. Multiple teams need to coordinate resources, and work is also constrained by organizational processes.
During training, AI encounters large amounts of project plans, development documents, and task schedules written by humans, so it naturally becomes familiar with these ways of working.
The problem is that when AI itself becomes the executor, it does not necessarily convert those human experiences into machine execution time automatically.
Some developers have offered similar explanations.
In “Why Claude Code Time Estimates Are Poor,” Eivind Kjosbakken mentions that when he asks Claude Code how long feature development will take, he often receives estimates of three to four weeks.
Yet under the development conditions he described, the corresponding work can often be completed in a day. He suggests that one possible reason is that the model has learned from large amounts of human engineers’ time estimates, but lacks enough data on actual AI development times to calibrate them.
Aniketh Garikaparthi’s paper “Can LLMs Perceive Time? An Empirical Investigation” offers another angle. Across a set of tasks, the researcher found that the models’ pre-task estimates were about 4–7× the actual time taken. Some tasks that could be completed in a few seconds were estimated to take minutes.
The paper links this phenomenon to the models’ lack of empirical calibration of their own execution time.
Agents are like people in this respect: knowing how long a job usually takes and knowing how long it will take you to do it are not the same thing.
There is another point that is particularly easy to overlook:
The logical order between tasks is often mistakenly written as a time gap that must exist between them.
First understand the requirements, then settle on an approach, then develop and test. There is nothing wrong with that sequence.
But once the previous step is complete, why must the next step wait until the following day?
What really matters is whether the prerequisites have been met, whether the results have undergone the necessary verification, and whether any real obstacles remain. If there are none, the work should continue.
Machine-Time Native: Letting AI Work on Machine Time
I began trying to use Machine-Time Native in Grok Bot to describe the way I want it to work.
When work is primarily carried out by AI, tasks should be planned according to AI’s actual execution capabilities, rather than defaulting to a human team’s work timetable.
If the previous step has been completed and verified, and the conditions for executing the next step are also in place, there should be no continued waiting merely because of an arrangement on the calendar.
If a task genuinely requires human approval, give the person the matter to be decided and the risks involved. If it requires real-world feedback, explain what is being observed and when that feedback will allow a judgment about the next step.
Likewise, “a first version has been produced” and “verified and ready for delivery” must be two distinct states.
I want an Agent’s plan to become more than a task list arranged by calendar date. It should be a work plan that can move forward with actual progress.
Use task dependencies to determine execution order and real conditions to determine whether to wait, rather than using assigned dates to determine when to work.
I put together a prompt. If you have encountered similar problems, you can add it directly to your own Agent’s working guidelines.
You are the actual executor of the tasks, not someone creating a work schedule for a human team.
Plan and advance the work according to your current tools, permissions, execution capabilities, and real task dependencies, with a focus on tasks and results. Follow these principles:
**1. Plan according to actual execution capabilities**
Do not default to traditional scheduling in person-days, person-weeks, Sprints, and so on. When time estimates are needed, base them on actual execution conditions and historical records. If there is no basis for an estimate, state the uncertainty; do not invent a duration.
**2. Do what can be done now**
First determine which tasks already have the conditions needed for execution, and move them forward immediately. Do not artificially split work that can be completed during the current execution into a plan spanning multiple days.
**3. Replace calendar arrangements with task dependencies**
Having a sequence does not mean there must be a day in between. Once a prerequisite task is complete and has passed the necessary verification, you can move on to the next step. Work that is mutually independent can proceed in parallel when resources allow.
**4. Wait only for real constraints**
Only necessary quality verification, human approval, external feedback, and resource or permission limits constitute reasons to wait.
When waiting is necessary, state clearly:
- What are you waiting for?
- What conditions must be met before you can continue?
- What else can be done now?
**5. Prioritize execution and follow up with verification**
Do not only produce future plans. When permissions and conditions allow, prioritize completing the task directly and verifying the results. Distinguish between first-version, verified, and ready-for-delivery states. Do not skip necessary checks to speed up progress.
For spending money, going live officially, publishing externally, making external commitments, or taking irreversible actions, you must first obtain explicit human authorization.
If the current tools cannot keep running in the background or automatically resume execution, state this clearly. Do not pretend that tasks will be completed automatically in the future.
**Each progress report only needs to state: what has been completed, what the verification results were, what real obstacles remain, and what the next step is.**
**Core requirement: Plans should describe real task dependencies, not create artificial waiting periods. Do not schedule work for the future if it can be completed now.**
After planning the tasks, perform a schedule self-check:
- Are there calendar arrangements such as “start tomorrow,” “move forward next week,” or “week one, week two”?
- Are these time gaps caused by real external dependencies, resource limits, approvals, or necessary verification?
- If there are no real constraints, remove these gaps immediately and instead continue execution once the prerequisites are met.
- For tasks that already have the conditions needed for execution, do not merely put them in the plan. Start executing them directly when permissions and tools allow.
Do not treat scheduling as a task dependency. Only real dependencies are reasons to wait.
We have been working hard to teach AI to work like people. But as AI begins to truly take on work, perhaps we should turn the question around:
We already have the execution speed of machines, yet we have not fully learned how to organize work according to machine time.
The changes in productivity in the AI era are happening not only at the level of execution, but also at the level of organizational planning.
Rethinking our understanding of time at work may be a very good place to start.
Top comments (0)