Execution (6): Dividing Work Solo — When a Person Becomes the Scheduler#

The last chapter of the execution part is about people, not technology. If you pick the idea, build the product with agents, add AI features, operate it, and promote it all by yourself, what does that “yourself” look like over a day? The introduction said that the “one” in a one-person startup is an organization of one decision-maker and several agent workers. This chapter is about how the human side of that organization should work. It is what I found when I investigated the causes of the fatigue I felt while working with several agents at once, and the rules I actually adopted.

The new bottleneck: this time it is the person#

With agents carrying out the final work, a person can now run several things at once. But I noticed a strange fatigue. Talking to two or three agents at the same time to push work forward, my hands were not busy, yet my head felt like it was constantly spinning in place. Every time a response notification arrived I switched to that session immediately to check it, and I was frazzled while overall output seemed to go down rather than up.

Pull the structure apart and it looks like this. An agent is not wired directly into my head, so conveying what I want requires a conversation, and that conversation keeps happening throughout the work. An agent’s responses take several minutes each. Simply waiting out those minutes is inefficient, so naturally you do something else in parallel, and the sessions grow to two, then three. Up to this point it is a chain of reasonable choices. The problem comes next. Every time you move between sessions, re-establishing “what was I doing in this one” and loading that context back into your head takes longer than you would think. With two or three sessions each cycling every few minutes, switches get forced on you every few minutes, and the person takes on the role of an operating system scheduler, endlessly swapping processes in and out. The difference is that an OS context switch takes microseconds and a human one takes minutes.

The evidence that this fatigue is not just a mood has been piling up for a long time. Attention residue, where cognitive activity on task A does not fully switch off after moving to task B and degrades performance on B, lingers most strongly when the previous task was left incomplete; and a conversation with an agent is an open loop waiting for a response, so structurally you always switch away in an incomplete state. Research puts the average time to return to the original level of focus after an interruption at over 20 minutes, so if you bounce between conversations with multi-minute response cycles on a notification basis, reaching focus is mathematically impossible. And the time it takes to resume an interrupted task shrinks dramatically if, right before leaving, you set a goal — “when I come back, I start with this” — and leave a visible resumption cue.

In short, switching immediately on every notification means repeating incomplete-state switches (maximum residue) at intervals of a few minutes (no recovery possible) with no cues (maximum resumption delay). It combines nothing but the bad conditions, so of course I felt frazzled.

The three rules I adopted#

Rule 1. No switching on notification; work like a coroutine#

When a notification arrives, do not jump over right away; finish the small unit of work in the session you are looking at, then switch. A “small unit of work” means a completion point on the order of “I read the whole reply and sent the next query.” In programming terms, this is a coroutine, not multithreading. In multithreading, the scheduler can cut off execution at any moment and hand off to another thread (preemptive); a coroutine yields only at points where each task has decided for itself that “it is safe to stop here” (cooperative). Switching on notification runs my head preemptively; switching after completing a task runs it cooperatively.

Keeping one asymmetry in mind makes this easier. An agent costs nothing to keep waiting. A reply read a few minutes late loses nothing, while the cost of interrupting a person’s thinking mid-stream has been measured. So the person’s rhythm always comes first.

Rule 2. Before leaving, leave a resumption note in the input box#

When you work with several agent sessions open in several windows, the most frequent problem is “what was I doing in this session?” Before leaving a session, spend just 20 seconds to write a short note on the current context and the next step into that session’s query input box. The input box is the first place your eyes land when you return, so it serves as a resumption cue by itself, with no separate note-taking tool. Taking it one step further, you can delegate this role to the agent. Before stepping away, ask it to “when I come back, put a summary of the current state and the decisions you need from me at the top,” and the resumption cue is prepared on screen automatically. The agent, not the person’s head, becomes the context store.

Rule 3. At most two interactive tasks at a time#

Split the tasks running in parallel into two kinds: interactive ones that require a human judgment every few minutes, and long autonomous ones that proceed on their own for an hour or more. Any number of long autonomous tasks can run; their switches happen only at planned moments. The problem is the interactive kind, and I decided to cap the number running concurrently at around two. The exact number can be adjusted to circumstances, but the principle — put a ceiling on the number of concurrent interactive tasks — is the core. Accounts from people who have run many agents in parallel converge on a similar point: beyond three or four, it is cognitively unmanageable.

There is one reinterpretation to add. The “depth” of a task is not a property of the task but a property of its phase. The same task is deep in the phase where you are thinking through the design and shallow in the phase where the agent implements on its own. So the rule becomes not “keep only one deep task” but “stagger the phases so the deep phases of two tasks do not overlap”: arrange things so that while one task is in its design phase, the other is in its implementation phase.

The highest-leverage intervention is not switching well but reducing the number of switches in the first place. Before the main work, run an exploration pass once — “do not implement yet; first investigate and bring me a list of the decisions I need to make” — or instruct the agent to “collect anything you get stuck on and ask all at once when the stage is done,” widening the interval between incoming questions. The longer and farther an agent can go on a single instruction, the more the person’s context switching problem eases on its own.

An agent that keeps working after the laptop closes#

Once you cap the number of interactive tasks, the rest of the work has to go to the long autonomous kind. But if the agent’s execution environment is tied to a laptop, the agent stops the moment the lid closes. The whole point of using agents is to hand off work while you are away, yet on the move you can only check in; it is hard to keep the actual work going. This is especially true for time-consuming jobs like long test runs, dependency installs, and repository analysis.

So I changed direction: keep the agent on an always-on remote server and direct it by message from anywhere. Put a resident agent on a small cloud instance, have the actual command execution happen in a container inside it, and use a messenger app as the driver’s seat.

Three things mattered in the setup. First, keep the instance small and simple. This is a personal execution environment, not large-scale service operations, so rather than an elaborate cloud configuration, a simple service where you only need to understand an instance, a static IP, a firewall, and snapshots was enough. The firewall restricts SSH to my IP only, and the agent’s API or dashboard ports are never opened to the outside. Second, execution happens inside a container. Separate the workspace so the agent cannot touch sensitive files on the host like config files, SSH keys, and environment variables. A folder that is not mounted into the container does not exist as far as the agent is concerned. Third, never leave secrets in public documents. Model API keys, messenger bot tokens, repository tokens (fine-grained tokens that can only reach the repositories they need), and server keys live only in config files on the host, and appear in chat logs and posts only as placeholders.

The choice of messenger turned out to matter more than expected. A company messenger is right for shared team bots and work-channel integrations, but for a personal remote development agent, creating a personal server with a dedicated channel was simpler. Long job logs and team conversations do not mix in one space, and on mobile the personal agent stays separate from team communication.

Once this environment existed, the arrangement of work changed. At the laptop I run two interactive tasks, and long autonomous tasks like long test runs, repository analysis, or overnight aggregation get handed to the remote agent by message. I check results and leave the next instruction while on the move, and when I come back, the results are ready.

Owner of areas, not roles#

Finally, working alone with several agents is ultimately running a small organization. And the criterion for dividing that organization is not traditional job functions. A shift I observed at work made this clear. As AI tools and agent environments advanced, it became common to see one person try planning, design, and development all by themselves, and who is responsible for the goals and outcomes of which area became more important than job titles. Humans move toward defining goals, priorities, constraints, and accountability; AI moves toward carrying out the actual work.

In a one-person startup this is even sharper. The founder is the owner of every area and assigns agents to each one: coding agents to the product area, writing and translation skills to the content area, the resident agent’s cron jobs to the operations area, query skills to the analytics area. What the founder has to decide is the same for every area.

• What the goal is
• What constraints to operate within
• How far changes may be applied automatically, and which changes always need a human check
• What counts as success
• How to roll back when something goes wrong

An area where these criteria are clear can be handed to an agent; one where they are not must stay in the person’s hands for now. And the most dangerous thing is mixing experiments with operations. Pushing an agent’s quickly produced experimental results straight into production only defers the review cost and the outage cost. Experiment freely; apply to production in small, clear units. The principle from the product chapter applies just as well to running the organization.

People say this is the age where the ability to use agents well matters. I feel that half of that ability lies not in prompting but in scheduling on the human side. Agent performance keeps improving, so the remaining bottleneck is the human head moving between sessions. That bottleneck is not solved by changing tools; it is a matter of habits: taking back control of the switch, limiting the number of open loops, attaching a resumption cue to every open loop, and sending long jobs to a remote agent. These rules may just be techniques for getting through the transition period until agents’ autonomous execution becomes good enough. But that transition may be longer than you think, so the techniques for getting through it are worth setting up properly.

Checklist#

1. I decide when to switch, not the notification. Move on only after completing a small task.
2. Before leaving a session, leave a resumption note in the input box or have the agent prepare a status summary.
3. At most two interactive tasks at a time; long autonomous tasks without limit.
4. Run an exploration pass before the main work to gather decisions up front, and have questions batched at the end of each stage.
5. Hand long jobs to an always-on remote agent by message.
6. The remote agent works inside a container; secrets stay on the host; the only open port is SSH.
7. For each area, define the goal, constraints, scope of automatic application, success criteria, and rollback method, and hand the clearest areas to agents first.