I usually work with agents one project at a time on my computers. As the number of projects grew, I had to keep track of who should get each task, how far it had progressed, and where I needed to step in. I started dividing the work among bots in Grok Bot. Instead of dealing directly with more than 100 project agents, I started out dealing with seven or eight domain bots. Now I go to the bot responsible for a type of work; it contacts the projects involved and brings the progress back to me.
The middle layer has nine work areas: Home Agent Steward, MiaoOS, Grok Bot, Health, Social Media, Schedule Manager, InfiniSynapse BP, Finance, and Project Security. The last two came later, as the work called for them.
Drawn out, this is a three-layer structure. I (WilliamZhu) sit at the top alongside the Chief Reporting Officer. The domain bots occupy the middle layer, with the project agents they manage below them. I decide what needs doing; the Chief Reporting Officer brings the updates together; and the domain bots contact projects and follow up on the work. I can ask for an overall report or go straight to a particular bot when I have something specific to discuss.
Start with the work, then find the right project
Each project has its own files, discussions, and unfinished work. Treating a project as an agent makes it easier to pick up where I left off. Articles and other written materials, for example, stay in william-docs, along with the context needed to keep working on them.
When I think about what to do next, though, I tend to think in terms of a kind of work. The agents and computers at home need attention. Something needs posting on social media. Presentation materials need another revision. I may not want to start by looking up which project or computer each task belongs to.
So I gave each area a point of contact in Grok Bot. Home-related work goes to Home Agent Steward, social posts go to Social Media, and presentation materials go to InfiniSynapse BP. Those bots contact the underlying project agents, assign the work, and ask for updates.
Figure 1. WilliamZhu and the Chief Reporting Officer sit side by side at the top. The nine domain bots form the middle layer, with project agents below them.
Home Agent Steward and InfiniSynapse BP, among others, use AC Chat to reach project agents on Mob Studio, Homestudio, and Winstudio. william-docs is one of those projects. AC Chat provides the way to contact and coordinate them, the computers provide the runtime, and the work stays in its project.
The projects do not have to move into one place, and I do not have to remember which computer to enter for every task. I give the work to the bot responsible for that area, and it finds the project. Organizing work by responsibility can coexist with keeping projects on different machines.
I find Grok Bot well suited to being an entry point for other agents. These domain bots resemble middle managers: they know who should receive a task, follow up after sending it, and bring back problems that need my attention. Simply getting the communication and follow-up right is already useful.
Figure 2. WilliamZhu and the Chief Reporting Officer share the top layer. Nine domain bots sit in the middle, above the many project agents. Updates go to both top-level roles. AC Chat and the three computers identify how the project agents are reached and where they run.
The Chief Reporting Officer and I share a layer, but have different responsibilities. I set the direction and make decisions that require human approval. It collects changes and progress across the work areas. The bots below report to it and directly to me. When I want to ask about something, I can continue the original conversation.
Finance and Project Security were added as the need arose
I started with seven work areas. Later, the bills from various cloud services needed ongoing attention, so I added Finance to monitor the bills and manage spending. Grouping those costs under one responsibility gives me a place to discuss expenses across services.
Project Security was added in much the same way. It checks my websites for vulnerabilities. I tell it about problems and pitfalls I already know, and have it keep watch over them. We regularly discuss the checks and monitoring, and I add what I have learned.
Both bots have an ongoing responsibility. Billing spans different services, while security issues affect multiple websites. Looking at one project at a time can scatter that work. Giving each area a point of contact means there is someone responsible for following it through.
The number of domain bots can change with the work. I do not need to design every role at the outset. When an area needs its own attention, I can add a bot. If responsibilities change later, I can adjust or combine them.
A Twitter request picked up an extra instruction
One task handled by the social media bot gave me a clearer view of what the middle layer should do.
I said, “Post this sentence to Twitter.” The bot relaying the request added an instruction of its own: “Publish it exactly as written, without changing a word.” That extra requirement overrode the social-publish skill's default rule that posts on X must be in English. The tweet went out in Chinese. A skill here is a set of working methods and rules used by the underlying agent.
I corrected it: unless I explicitly emphasize a constraint, the middle layer must not add one for me.
I had asked for something to be published. The underlying agent already had instructions for adapting content to X. Adding “without changing a word” decided the wording on my behalf and displaced the platform rule. A few extra words in the handoff changed the result.
That made the relay's job clear: pass along the requirements I actually gave, without filling in requirements I did not give. Where the underlying agent already knows how to do the work, let it follow its skill.
Figure 3. The middle layer adds “without changing a word” to the original request, resulting in a Chinese tweet. WilliamZhu then corrects it. A separate task reaches a requirement for approval before publishing, and the Home Agent Steward brings the decision back to WilliamZhu.
Getting the intent right matters more than planning every step for the agent below. That agent already has project context and working methods. The middle layer needs to understand what it already knows.
Spoken names need to resolve to the right things
I also want these bots to handle the way I speak in ordinary conversation. Names in voice instructions are not always exact. In this case, “William Dots” meant william-docs, “Social Public Social Publish” meant social-publish, and “Sol6.1” meant gpt-6.1-sol.
Without resolving those names, a task might go to the wrong project, use the wrong tool, or stop because the named object does not exist. The middle layer needs to identify the intended project, skill, or model, report that interpretation to me, and save confirmed mappings in memory. The next time the same wording appears, there is a record to work from.
This clarifies what I am referring to. Adding “without changing a word” changes what I am asking for. Names should be resolved accurately, while the task requirements should be passed along as given. That lets me speak naturally, without preparing a list of exact project, tool, and model names before every request.
Decisions that need my approval should come back to me
During the same social media work, we also ran into two copies of the same skill. The copy under ~/.codex/skills required human approval before publishing and allowed only drafts on X. The third post stopped there and waited for approval.
The Home Agent Steward came directly to me for a decision.
It needed to bring back specific information: which copy of the skill was being used, what rule it had encountered, where the task had stopped, and what I now needed to decide. With that information, I could deal with the post in front of me.
In the earlier mistake, the bot had added a requirement I never gave. Here, the executing agent had encountered an existing requirement for human approval. Keeping those cases distinct tells the middle layer what to do: relay the task without changing it, and bring decisions back when my approval is required. It cannot approve something on my behalf.
Reports need a status, a link, and two destinations
After handing off a task, what I most need to know is how far it has got.
“Received” means the task has arrived. “Published” means the post has gone out. “Opened the detail page and checked it” means another verification step has been completed. The steward brings back links and checks the actual text. Those reports tell me whether I have a receipt for the task, a published post, or a result that has also been checked.
If all I get is “done,” I still have to find the post and check its content and language myself. A status and a link let me inspect the result and ask directly about anything that needs attention.
We also changed where the reports should go. The Chief Reporting Officer told the bots to send it updates whenever they made progress. I added, “Report to me as well as to him.” Updates now go to both the Chief Reporting Officer and me.
The Chief Reporting Officer gathers progress from across the work, while direct reports keep me informed about individual tasks. There is a combined report when I want an overview, and the original messages and links when I want to follow a particular task. The overview does not replace direct contact.
At the time, the bot receiving that instruction first checked that it really came from me before saving it. Changes to reporting relationships also need a clear source.
Start with one kind of work you regularly follow up on
If you already use agents across several projects, you could start by choosing one kind of work that regularly crosses project boundaries and giving it a domain bot. Tell it where the relevant projects are, how to contact them, and which decisions must come back to a person. Ask it to return a clear status, links to the results, and any issues that need attention.
Social media work can make the division of responsibilities easy to check. Did the bot find the right project and skill? Did it add instructions during the handoff? Did it bring back requests for approval? Did it check the published content? These all came up in the task described above, and each can be checked separately.
Once several areas have someone following them up, the Chief Reporting Officer can bring their progress together, while each bot continues to report directly to the person in charge. Getting one area working before adding more roles leaves more room to adjust than drawing a complete organization chart at the start.
Roles can change; people still set the direction
Bringing the number of agents I deal with directly down from more than 100 projects to a handful of domain bots has been the most immediate change. I go to a point of contact for each responsibility, and those bots reach the projects below. The three-layer structure organizes the projects while leaving me free to take part in specific work.
It looks much like a company's management structure. As I learn more about managing it, I will redraw responsibilities and add, remove, or combine bots. Finance and Project Security are two examples of roles added as the work changed.
But the whole system is driven by people. I propose the direction, assign the roles, and change the relationships. The bots can run regular checks, monitor things, and report back. They do not yet have a drive of their own.
That is why I see Sparse Agent as an important direction for the future. Domain bots have helped me organize these projects. The next thing to explore is how agents can keep moving work forward themselves. That is what I am building Sparse Agent for: you give it a goal for the coming weeks or months, and it keeps working on it and reports its progress. It is invitation-only for now, and you can join the waiting list at sparse-agent.com.