After using Grok Bot for a while, I increasingly feel that it is well suited to being the entry point for interacting with a group of Agents. Once I have handed off a task, I can keep talking about the next one, add to earlier requirements, or correct its understanding of what I meant. Several tasks can move forward on their own while the conversation continues.
That continuity matters more in daily use than a slightly faster individual answer. If the entry point is often occupied by the task at hand, I have to wait for it to finish before giving it something new to do. As the work builds up, I end up opening projects one by one and asking each for an update. Grok Bot has shown me another way to organize work: keep the conversation in front of me and delegate execution to the layers below.
Here, the main Bot is the entry point that talks directly with a person; sub-Bots take responsibility for particular kinds of work and continue following up; project Agents do the work within specific projects. I do not have complete official material on Grok Bot's internal architecture. The division of responsibilities described below is my understanding, based on using it and organizing Bots myself.
The entry point needs room to understand the person
In earlier accounts of using Grok Bot, I wrote that it was quick to remember rules and preferences, and that it could follow several tasks in the same conversation. Taken together, those two experiences come closer to what I mean by efficiency.
When the main Bot is not tied up with one specific task for a long time, I can keep adding requests. It takes in what I say, works out what I want to do, delegates execution, and remains in the conversation. An article already being revised can continue through its revisions while another request starts being arranged. The main interface can then support both communication and progress without making me wait through the entire execution of a particular task.
This also leaves the main Bot time for things more worth its attention: understanding how I make requests, which preferences recur, where it needs to check its understanding with me, and how I usually decide when faced with tradeoffs. If a correction only changes the current task, I will have to explain it again next time. If it understands the correction properly, our work together can build on it.
That learning happens through conversation. An extra comment, my rejection of an approach, or a decision about what to do first may all help it understand the next request more accurately. The main Bot needs to remain available for conversation to keep learning these things. Sub-Bots can continue handling file changes, checking results, and waiting for work to finish.
Figure 1. The person gives requests to the main Bot, which delegates work to sub-Bots. The sub-Bots contact the Agents in their respective projects. Projects A–D are illustrative.
From my perspective as a user, this division keeps communication continuous. While one task is running, I can make another request. If the original direction needs changing, there is still someone available to respond. The number of tasks that can actually run in parallel remains limited by execution resources and dependencies between tasks, but no single task has to occupy the entire entry point.
More projects call for someone to follow up on my behalf
I used to work with Agents one project at a time. Each project has its own files, discussions, and unfinished work, so it feels natural to keep opening conversations around it. The project Agent knows the project and can readily pick up where it left off.
The difficulty comes when the number of projects grows. With dozens or hundreds of projects, each with its own conversations, I have to remember who received which task, where each discussion left off, and which questions still need an answer from me. Individual Agents can work well, yet across all those projects, I still have to contact them one by one. It is much like a manager directly supervising every frontline employee in a company: assignments, progress updates, and problems all pass through that one person.
My previous article, “How I Built a Company-Style Organization in Grok Bot,” recorded how I adjusted to this problem. I narrowed my direct points of contact to a few Bots organized by kind of work, and had them contact the project Agents. Names such as “家里 Agent 管家” (Home Agent Steward), “日程管理大王” (Schedule Manager), and “InfiniSynapse BP” correspond to the kinds of things I tend to think about in daily work.
Figure 2. The Bot list from the earlier article's materials shows the Chief Reporting Officer (首席汇报官), along with entry points such as 家里 Agent 管家 (Home Agent Steward), 健康 (Health), and 日程管理大王 (Schedule Manager).
This layer has specific responsibilities. A sub-Bot receives a request, finds the relevant projects, passes the requirements to the project Agents, and follows their progress. It brings back questions that need a human decision, and brings back the results when the work is done. Files and actual operations within a project remain the responsibility of its project Agent.
In this arrangement, one project corresponds to one Agent. A project may have multiple discussions and conversations, but the management layer above it has a clear point of contact for the work. A sub-Bot can contact several projects, and I can keep checking on that work through the same entry point. The middle layer organizes the projects so I do not have to relay every message or ask for every update myself.
Figure 3. The earlier article's organization diagram has WilliamZhu and the Chief Reporting Officer at the top, domain Bots in the middle, and project Agents at the bottom.
The earlier diagram placed me and the Chief Reporting Officer at the same top level to explain how I organized different kinds of work at the time. This article focuses further on the main Bot that talks directly with the person: it understands requests, sub-Bots handle the management in between, and project Agents do the specific work. Connecting the conversational entry point to those responsibilities below creates a management hierarchy from the person down to the projects.
Broad knowledge still requires allocating context windows and attention
Why delegate the work at all? Large language models already know a great deal. If we keep expanding the context window, could all the projects fit into a single conversation?
How much a model knows is separate from how much it can read and handle at one time. The context window is the range of material it can bring into the current piece of work. Project files, past discussions, content being revised, and new requests all occupy that space. The window can grow, but the material that needs handling also grows as more projects are added.
Attention imposes another limitation. Material being inside the window does not mean every detail will be handled equally reliably. A recently changed requirement in one project, an unconfirmed issue in another, and a preference I have just added may all affect the next step. The model needs to identify what is currently relevant among those details.
By attention, I mean both the attention mechanism through which the model processes context and the ability to focus and make choices that it shows in use. I do not treat it as a capacity to which I can casually assign a number. The point is that even a model with extensive knowledge cannot therefore be assumed to have an unlimited context window or unlimited attention.
Figure 4. Knowledge materials available on demand appear at the top. The left puts several tasks in one limited window; the right shows separate windows and current areas of focus for the main Bot, sub-Bots, and project Agents. All quantities and sizes are illustrative.
The value of a hierarchy is that each layer can use its window and attention for its own concerns. The main Bot focuses on the person's goals, preferences, and decisions that need to be made. Sub-Bots focus on arrangements, progress, and dependencies in the work they oversee. Project Agents focus on specific files, operations, and checks. Project details stay in the project, and matters that require judgment from a higher layer are brought up to it.
This distributes the pressure on context windows and attention across different units of work. Each has its own boundaries and can process the relevant material together. Communication across those responsibilities does have a cost: requirements may be distorted in transit, and results may be summarized inaccurately. The necessary information still has to be conveyed clearly between layers.
I recorded one such deviation in an earlier article. When a Bot in the middle passed on publishing requirements, it added “without changing a single word” on its own, changing how the work would be carried out. I later corrected it: do not add constraints I have not stated. This shows that the middle layer needs to learn from my decisions while passing requirements down accurately. Adding more Bots does not, by itself, automatically improve collaboration.
People divide work for similar reasons. A person can learn many things and still be unable to keep track of every detail across all projects or give sustained attention to every task. Dividing responsibilities lets people direct their limited learning effort and attention toward the work they are responsible for. A model's store of knowledge can be far broader than an individual's, but when it comes to continuously handling multiple tasks, its context windows and attention still need to be organized this way.
So I keep the layers that are needed and adjust them to the actual work. If a kind of work deserves ongoing follow-up, I assign it to a sub-Bot; project Agents continue looking after their own projects. The usefulness of a hierarchy depends on whether it reduces the demands on my attention and keeps the necessary work moving forward.
Grok Bot is the AI interaction entry point for a new era. What I value is this arrangement: a person makes requests in a place where the conversation can continue, the main Bot gradually comes to understand that person, sub-Bots manage the work, and project Agents carry it out. Dividing responsibilities across layers lets limited context windows and attention support more work.
This article continues the discussion in my accounts “How I Built a Company-Style Organization in Grok Bot” and “I Gave Grok Bot a Set of Tools: Communication, File Storage, and Health Management.” It also draws on earlier posts about multitasking, preference learning, and working in layers with Grok Bot.
Sources of the earlier images (the following are paths within the repository):
- Figure 2 comes from the original material for “How I Built a Company-Style Organization in Grok Bot,” at
writing-studio/auto-coder/grok-bot-project-delegation/images/source/reference/bot-list.jpg, copied to this article'simages/existing-bot-list.jpg. - Figure 3 comes from
writing-studio/auto-coder/grok-bot-project-delegation/images/01-from-projects-to-domains.pngin the same article, copied to this article'simages/existing-three-level-organization.png.
Figures 1 and 4 were drawn for this article to illustrate the division of responsibilities. They are neither product interfaces nor diagrams of the official internal architecture. The reproducible Three.js scenes and export scripts are in the scene/ directory alongside this article; the image records are in scene-manifest.json.