Your Job Is Now Running the Inbox, Not Doing the Work

The useful question about AI assistants is no longer, “What can this chatbot write for me?” It is, “What work can I send away, inspect later, and either accept or return?”

That change sounds administrative. It is also where the productivity gain begins. A chat assistant still holds you in a loop: prompt, wait, read, correct, repeat. A background agent lets you dispatch one bounded job and move to another. Run several at once and your day starts to resemble an operations desk. Work arrives in an inbox. You triage it, reject weak output, resolve exceptions, and combine the pieces that pass.

Recent projects show the pattern appearing at very different levels of complexity. On September 17, Stanford Medicine described a virtual biotech company that uses thousands of AI scientist agents in coordinated research workflows. At the smaller end, the open-source Pizza Bot project describes itself as an inbox for AI agents working in the background. One tackles scientific research; the other gives developers a queue. Both point to the same practical change: the human spends less time waiting inside a conversation and more time directing, checking, and routing work.

That does not prove every office will run on agent swarms next year. It does tell us what to practice now.

Redesign one workflow before adding more agents

Start with one recurring workflow you already understand. Weekly market research is a good candidate. So is first-pass contract triage, customer feedback synthesis, release-note drafting, or checking a codebase for a known class of bug. Avoid a vague goal such as “help with marketing.” Choose work with a recognisable input and a result you can judge.

Write down the workflow as it exists today. Mark three kinds of steps: decisions that need your judgment, execution that can follow a specification, and irreversible actions such as sending, publishing, deleting, or approving. Keep the decisions and irreversible actions with a person. Delegate the specified execution first.

This boundary matters. “Research our competitors” is an invitation to receive a polished pile of uncertainty. A usable assignment names the competitors, date range, allowed sources, required fields, citation standard, output path, and what the agent should do when evidence conflicts. The quality bar must be observable. “Make it good” cannot be checked. “Every factual claim has an inline link to a primary source” can.

Give each delegated step an output contract. State the input, the required artefact, the acceptance checks, and the stop condition. If the agent cannot access a source or cannot verify a claim, require it to mark the gap rather than fill it with a plausible answer. If a step could trigger an external action, require a review state instead of permission to proceed.

Then run a small batch. Three parallel jobs are enough to expose operating problems without creating a landfill of half-finished drafts. You are testing the workflow, not demonstrating how many agents you can launch.

Treat the inbox as a control system

Background work only saves time when every result has a clear state. At minimum, distinguish work that is running, blocked, ready for review, rejected, and accepted. Without those states, an agent inbox becomes another place where uncertain work accumulates.

Review at set times rather than reacting to every completion alert. For many office workflows, two review windows a day are a sensible starting point. During each window, inspect the evidence before the prose. Open the cited source. Run the test. Compare the output with the requested schema. Check that the file exists where the agent says it does. A confident summary is not proof that the task succeeded.

Use rejection as data. When an output fails, record the exact acceptance check it missed. A missing citation suggests a source rule. A correct analysis in the wrong file suggests a path check. A draft sent before approval suggests a permission boundary. Improve the contract instead of adding another paragraph of encouragement to the prompt.

Portability will matter as these workflows grow. A September 17 launch on Hacker News, Skillsync, pitches portable chat sessions and skills across different agents. That is a vendor claim, not proof that one standard has won. It is still a useful market signal: builders expect people to move context and procedures between specialised systems rather than keep all work inside one chat window.

Do not make portability your first problem. A folder containing the brief, source material, output contract, artefact, and review notes is enough to begin. Another agent or another person can then pick up the job without reconstructing your intentions from a long chat transcript.

Build the skill that the workflow now demands

The scarce skill in this setup is decomposition: turning a goal into pieces that can run independently, defining the joins between those pieces, and knowing what evidence is sufficient at each join.

That skill changes how junior work should be designed. Repetitive first drafts and routine searches have traditionally doubled as training. If agents take more of that execution, managers cannot assume new staff will learn through repetition in the same way. They will need explicit practice in reviewing evidence, spotting omissions, comparing outputs with specifications, and tracing an error back through a workflow. Audit can teach a great deal, but only when someone explains why an output passed or failed.

There is also a hard limit to the “run a dozen agents” idea. Parallel work multiplies review demand. If ten agents each save an hour of execution but create twenty minutes of checking, the arithmetic may still work. If their outputs overlap, contradict one another, or arrive without evidence, you have moved the bottleneck rather than removed it. Measure accepted output, correction time, and failures that escape review. Do not measure prompts sent.

A practical first week is straightforward. Pick one workflow on Monday. Write the current steps and acceptance checks on Tuesday. Delegate one bounded step on Wednesday. Review three runs on Thursday and tighten the contract around the failures. On Friday, decide whether the workflow saved time while meeting the same quality bar.

Keep the human approval point for anything public, costly, destructive, or hard to reverse. Everything else can earn more autonomy through repeated, verified performance. That is how an assistant moves from a chat window to a dependable background worker.

Start with one queue, one contract, and one review rhythm. If the accepted results are faster and no worse than your current process, add the next workflow.