我们如何设计 Grok Bot，让智能体能够超越单次会话而持续存在——从聊天记录到 Bot 名册、在线状态、Bot 专属的计算机，以及无需提示词即可启动的工作。
当我们开始设计 Grok Bot 时，核心问题之一是界面应如何塑造用户与智能体之间的关系。大多数 AI 界面都围绕用户操作的聊天会话展开。每个会话从设置开始，在用户的注视下展开，并在对话停止时结束。
我们希望设计一个能够超越任何单次会话而持续存在、并能独立承担责任的智能体。这意味着需要重新思考界面的一些基本对象和信号，包括侧边栏中应该放什么、智能体如何展示进度，以及它的工作何时应该变得可见。
Kenny
晚上 7:34
周五全员大会的演示文稿需要你确认。
Justin
8 份介绍草稿已写好——存放在 CRM 里，等你发送。
Luke
晚上 7:34
收件箱还有 3 封邮件。其中两封今天需要回复。
网站上线
上午 11:18
John：结账流程在预发布环境上已经干净了，关了 3 个 bug。
John
昨天
复现了结账崩溃的问题。详细说明写在工单里了。
Keith
Acme 那边有点摇摆不定。我起草了一份周四的同步沟通。
Tyler
上午 9:04
收到 14 张收据了。还缺你周二打 Uber 的那张。
Manuel
下午 2:20
发布帖已经上线了。前 200 次曝光。
Jenny
周二
SoMa 那边有 3 个地方。Folsom 那套两居室就是目标。
Chang
上午 10:12
来源：xAI：新闻（网页）
插件
彭正
肯尼
上午 9：41
嘿，今天的设计同步会主要有哪些收获？
团队大部分时间都在审阅新的引导流程。
最大的讨论围绕空状态展开。莎拉觉得现有的插图不符合新的品牌方向，在场大多数人也都认同。关于进度指示器应该放在页头还是侧边栏，大家也进行了长时间的来回讨论。
不过整体氛围是积极的。大多数人认为这个流程已经接近可以进入更大范围评审的阶段。
有人提到 Q3 路线图了吗？
提到了，出现了两次。马库斯说路线图评审现在预计在八月的第一周进行，普丽娅问引导工作会在那之前还是之后落地。会议上没有确定具体日期。
给肯尼发消息
肯尼的屏幕
日常任务
早间简报
每天上午 8:00
收件箱清理
工作日傍晚 6:00
每周团队动态
已暂停
重新思考基础概念
AI 产品在短时间内积累了大量词汇。聊天、会话、模型、上下文窗口、记忆、系统提示词、项目、技能、连接器、智能体、工具、沙盒、权限和自动化，这些都描述了这些系统中真实存在的组成部分。
但把每一个都作为独立的产品概念呈现出来，是在要求用户理解超出他们实际需要的内容。我们一开始问的是：一个人要与智能体协作，究竟需要哪些概念。
我们反复得出的答案始终是五个：
- Bot（机器人）是拥有自身身份、记忆、运行时和工具的持久化智能体。
- Chat（聊天）是与 Bot 协作的对话式界面。
- Prompt（提示词）为 Bot 提供上下文或指令。它们可以一次性使用、保存为技能（Skills），或作为例行程序（Routines）自动触发。
- 工具让 Bot 能够获取信息，并通过软件、API、连接器、shell 或计算机使用来采取行动。
- 工件（Artifacts）是 Bot 创建或修改的文档、设计、代码、数据以及其他持久性输出。
其他一切都可以保留在界面之下，直到用户有理由去关注它们。接下来的问题是，这五个对象中哪一个应该作为组织产品的核心。
从聊天历史到 Bot 列表
聊天是即用即弃的。我们开启一段对话是为了解决一个问题。它被推到侧边栏的下方。一周后，我们又开启另一段对话。你很少会回头翻看最近五条以外的内容。
当交互的单位是一个问题时，这种行为完全合理。但当交互的另一端本应认识你、记住之前的工作并长期承担责任时，这种行为就变得奇怪了。
因此，Grok Bot 中的主要对象是 Bot，而不是对话。一个 Bot 有名字，有头像和标题。它记得与你的对话。它有自己的计算机和工具。当你明天回来时，你回到的是同一个 Bot。
Acme 项目
根据周五通话内容起草一份给 Acme 的跟进邮件
重写定价一页纸
安全审查中我应该问些什么？
根据我的通话笔记构建一份支持者地图
用刁钻反对意见来演练演示
帮我对比这三份竞品方案
显示更多
Kenny
晚上 7:34
周五全员大会的演示文稿需要你确认。
Justin
8 封引荐邮件草稿已写好——放在 CRM 里，等你发送。
John
昨天
已复现结账崩溃问题。详细说明已写入工单。
Keith
Acme 那边在动摇。已起草周四的跟进沟通。
在场感即界面
一旦 Bot 从“你启动的一次会话”变成“你需要长期维护的东西”，Bot 在产品中的呈现方式就必须同时回答三个问题：
- 这是谁？
- 它们在做什么？
- 我需要了解多少？
这是谁
一份名单只有在能被快速扫读时才真正有用。随着名单不断变长，我们不希望用户每次打开产品都要逐一阅读每个名字。他们应该几乎仅凭余光就能从头像辨认出某个 Bot。
Kenny Kuh 与 Peng Zheng 对 Bot 头像视觉风格的探索
与此同时，我们希望头像之间保持足够的统一性，让人能看出它们是同一套体系。我们研究了插画、动画、游戏和界面设计中的角色体系，探索了从首字母、表情符号到像素画、水彩、黏土风格、Noritake 式线条画、剪影和 identicon 等各种方向。
大多数方案都只在一方面做得更好。水彩和黏土风格让单个 Bot 个性十足，但在侧边栏的尺寸下细节过多。更简洁的体系在界面中更自然，但往往让各个 Bot 看起来大同小异。
我们最终采用的系统保持了基本构造的一致性，使用简洁的造型和富有表现力的眼睛，再通过受控的变化和配饰来体现差异。每个 Bot 都能一眼被认出，同时又不会让人觉得它们来自不同的视觉世界。
它们在做什么
一旦头像成为 Bot 的身份标识，它自然也成为展示状态的最佳位置。一个 Bot 可能处于空闲、思考、工作、等待、受阻或完成等状态。我们本可以用独立的指示器来表示每种状态，但那会为用户增加一层需要解读的 UI。
相反，我们探索了头像本身能承载多少生命周期信息。
静止时，Bot 显得平静且略带好奇。当任务到来时，它会确认收到任务。工作开始时，它会进入运转状态。当它等待或需要帮助时，动作会再次变化，任务完成后则恢复平静。现在，头像既能显示 Bot 在做什么，也能表明它是哪个 Bot。
空闲 工作 等待 受阻 思考 完成
头像动作系统由 Benji Taylor 设计
我需要了解多少信息
一个相关的设计问题是，Bot 的执行过程需要展示多少。一种做法是标准的“三个动画点”，但那提供的信息太少，用户很难判断 Bot 是在工作还是卡住了。
正在搜索网络
环境就绪 387ms
已编辑 math.ts +14−10
已运行定向测试 npm test
已运行类型检查 npm run
短暂思考
已搜索代码“toFixed”
已读取 AGENTS.md
已编辑 math.test.ts +6−2
已运行完整测试套件 212 项通过
已提交修复：clamp NaN
环境就绪 387ms
已编辑 math.ts +14−10
已运行定向测试 npm test
已运行类型检查 npm run
短暂思考
已搜索代码“toFixed”
已读取 AGENTS.md
已编辑 math.test.ts，+6 −2
运行完整测试套件，212 项全部通过
已提交修复：对 NaN 进行钳制处理
我们还尝试过用一段简短的文字描述来展示 Bot 当前正在执行的操作，但一旦用户能看到某一步，他们就想看到其余所有步骤。用户调研显示，他们之所以要求看到这些细节，主要是为了确认 Bot 仍在正常工作、没有偏离方向。
在最终设计中，头像的动态首先提供了第一层安心感——表明 Bot 正处于活跃状态。如果用户想查看它正在做什么，只需悬停即可看到其当前操作。
那是它们的电脑，不是你的
每个 Bot 都拥有自己的电脑，可以用它来浏览网页、处理文件和运行软件。这又带来了另一个界面问题：这台电脑应该有多大程度的可见性？用户又应该在什么时候能够控制它？
我们探索了四种布局方案：
- 悬浮窗口：让电脑易于触达，但会遮挡对话内容。
- 并排显示：让工作过程持续可见，鼓励用户观看。
- 模态窗口：便于随时查看进度，但把 Bot 的工作区当作了一种临时打断。
- 全屏：给了电脑充足的空间，却完全挤掉了对话。
我们把电脑做得越显眼，产品就越倾向于引导用户去监督它。我们决定，它应该仍然是 Bot 的工作空间，界面则根据用户的需要提供不同层级的访问权限。
最终设计包含三个层级，让用户可以进入 Bot 的工作空间，却不必被卷入操作之中：
- 状态：电脑处于活动状态时，标题栏图标会变为紫色。
- 预览：打开后会展开一个固定的侧边面板，用户无需离开对话即可跟进工作进度。
- 接管：当 Bot 需要帮助时，用户可以全屏打开电脑、接管控制，然后再交还回去。
我们还设计了随时间变化的动态壁纸——清晨更明亮，夜晚更深沉。这一细节让 Bot 的电脑有了自己的时间感，也让它与用户的桌面区分开来。
动态壁纸由 Kenny Kuh 和 Luke Barker 设计。
这更像是与同事协作，而不是操作一台远程机器。你能看出对方正在工作，需要上下文时瞥一眼他们的屏幕，遇到需要你帮忙的事情时再坐下来接手。
信息的形态
早期版本的 Grok Bot 几乎对所有请求都用散文式文字来回应。它用文字描述五天的天气预报，而不是直接展示天气图；用叙述的方式罗列任务，而不是以看板形式呈现。用户随后不得不重新整理这些回答。这让我们意识到，回答的形式本身就是答案的一部分。
为了支持这一理念，我们在 Grok Bot 中构建了内联卡片和小组件。当散文式文字适合承载信息时，Bot 可以用文字回答；当不适合时，则使用结构化界面。
新邮件
准备发送
发件人：peng@grokbot.app
收件人：sarah@acme.com
主题：将周五的设计评审改到下午 2 点
嗨，Sarah，
我们能否把周五的设计评审从上午 11 点改到下午 2 点？临时有一个客户电话会议，我不想让我们的讨论太仓促。
谢谢，
Peng
发送邮件 放弃
Peng Zheng 的内联聊天小组件
同样的原则也适用于操作。当 Bot 创建 Routine、更改设置或向另一个 Bot 发送消息时，该事件可以直接出现在记录中。当有更多内容需要查看时，用户可以将其打开。
上午 9:41
早上好！你能帮我跟每个人确认一下情况吗？
正在处理——现在联系团队获取状态
与 Kenny Tyler 和 Jenny 的 6 条消息
一切顺利：Kenny 已上线落地页，Tyler 已发送本月发票，Jenny 已预订下周的面试。没有阻塞问题。
太棒了，你能每天早上都这样做吗？
已创建 Routine：晨间简报
搞定，你的晨间简报每天 9:00 会准时送达
其结果是形成一种异构记录，对话、系统事件、交互式对象和可视化内容共享同一条时间线。
组织智能
一旦用户创建了多个 Bot，产品还需要组织这些 Bot 如何协同工作。我们需要决定哪些上下文应归属于哪个角色，当 Bot 的工作范围重叠时它们应如何共享上下文，以及如何协调它们而不让用户变成调度员。
随着用户创建更多 Bot，我们看到一个答案逐渐浮现。有人设置了一个 Chief of Staff Bot 来负责协调多个专家 Bot。他们只需向一个 Bot 下达指令，而无需逐一检查每个 Bot 并亲自为每项任务分配路由。
赋予 Bot 不同的角色也迫使我们决定每个角色应该知道什么。一个法律 Bot 可能需要正在进行的纠纷的历史记录，而一个财务 Bot 可能需要多年的财务记录。将这些历史合并到一个大内存中，反而会让为每个 Bot 提供与其工作相关的信息变得更加困难。
因此，在 Grok Bot 中，能力与上下文的边界是不同的。工具和技能位于账户层面，因为许多 Bot 可能都需要浏览网页、处理文档或发送电子邮件。而记忆和例行任务则归属于 Bot 本身，因为它们反映的是该特定角色随时间推移所知道和做的事情。换句话说，能力可以广泛共享，而上下文则保留在需要它的角色手中。
有些工作会跨越这些角色边界。群聊为项目或团队提供共享上下文，同时允许每个 Bot 保留其专业化的记忆。设计师、工程师、产品经理和数据科学家可以在同一个对话中协作，互相交接工作，并共享项目所需的信息。
我们曾考虑添加仪表盘、任务分配板和显式交接控制来管理这些群组。每一种方案都会给用户带来更多的协调工作。相反，由协调型 Bot 处理常规路由，只在需要判断力做决策时才把用户拉进来。
持续推进的工作
大多数智能体会话始于用户发送提示词。这样一来，即使是常驻的 Bot 也要等待有人来激活它。Routines（例行任务）让用户能给 Bot 一项长期职责，按计划或响应事件运行，例如关注某个行业或每天早上准备简报。用户只需定义一次工作内容，Routine 就会在需要时激活 Bot。
我们最初把 Routines 当作次要配置。随着它们对自主工作越来越重要，我们将其移入了 Bot 的主界面。会话记录会显示运行了什么，并给用户一个查看结果或处理异常的地方。
每天早上 8:00
工作日早上 8:00
每周一早上 9:00
每月 1 日早上 8:00
每 30 分钟
工作日 · 9:00 AM
已在 grokbot 中创建 issue
在所有项目中提交 Issue
grokbot 上触发事件
grokbot 上的任意事件
grokbot 中开启 PR
spacexai 中合并 PR
acme 中关闭 PR
推送到 main 分支
grokbot 中 PR 的检查失败
grokbot 中添加 bug 标签
ops 中包含 /fix 的评论
grokbot 中审核通过
grokbot 中线程已解决
deploy.yml 工作流失败
当 webhook 收到 POST 请求时
#grokbot 中的新消息
#ops 中添加 :eyes: 表情回应
创建匹配 dev 的频道
#design 中的新消息
已在路线图中创建问题
问题状态 → 核心团队中进入审核
核心团队周期结束时
问题状态 → 设计团队中已完成
设计团队中有新消息
在设计团队中创建了频道
这也改变了对话的角色。提示词可以开启一个会话，但定时任务、事件或其他 Bot 同样可以。随着时间推移，越来越多的工作可能根本不需要用户在场就能开始。
逐渐消失的界面
到项目后期，大量设计工作都在做减法。我们去掉了窗口和面板控件、电脑视图选项以及智能体元数据。我们还设定了实际限制：每个账户约 50 个 Bot，每个群聊最多 6 个。每一个决定都回归到同一个问题：这是帮助用户完成委派，还是又给他们添了一件需要管理的事？
随着模型不断进步，操作 AI 与向同事委派任务之间的界限也在不断移动。Grok Bot 反映的是我们认为这条界限目前所处的位置。从最初探索到正式发布，设计 Grok Bot 的过程始终是在寻找这条界限，并帮助界面随之演变。当智能体承担更多责任时，界面应当对用户提出更少的要求。
How we designed Grok Bot for agents that persist beyond a single session — from a chat history to a Bot roster, presence, a computer of the Bot’s own, and work that starts without a prompt.
When we started designing Grok Bot, one of the central questions was how the interface should shape the relationship between user and agent. Most AI interfaces are organized around a chat session the user operates. Each session begins with setup, unfolds as the user looks on, and ends when the conversation stops.
We wanted to design for an agent that persists beyond any one session and can carry responsibility on its own. That meant reconsidering some of the basic objects and signals of the interface, including what belongs in the sidebar, how an agent shows progress, and when its work should become visible.
Kenny
7:34 PM
Need your yes on the Friday all-hands deck.
Justin
8 intros drafted — sitting in the CRM till you send.
Luke
7:34 PM
Inbox's at 3. Two need a reply today.
Website launch
11:18 AM
John: checkout's clean on staging, 3 bugs closed.
John
Yesterday
Repro'd the checkout crash. Write-up's in the ticket.
Keith
Acme's wobbling. Drafted a Thursday check-in.
Tyler
9:04 AM
14 receipts in. Still missing your Uber from Tuesday.
Manuel
2:20 PM
Launch post is live. First 200 impressions.
Jenny
Tuesday
3 places in SoMa. The Folsom 2bed is the one.
Chang
10:12 AM
Sourced 3. Skipped one already in your ATS.
Plugins
Peng Zheng
Kenny
9:41 AM
Hey, what were the main takeaways from today’s design sync?
The team spent most of the session reviewing the new onboarding flow.
The biggest discussion was around the empty states. Sarah felt the current illustrations don’t match the new brand direction, and most of the room agreed. There was also a long back and forth about whether the progress indicator belongs in the header or the sidebar.
The overall mood was positive though. Most people think the flow is close to ready for a wider review.
Did anyone bring up the Q3 roadmap?
Yes, it came up twice. Marcus said the roadmap review is now expected in the first week of August, and Priya asked whether the onboarding work would land before or after that. No firm dates were settled in the meeting.
Message Kenny
Kenny’s screen
Routines
Morning briefing
Every day at 8:00 AM
Inbox cleanup
Weekdays at 6:00 PM
Weekly team update
Paused
Rethinking the primitives
AI products have accumulated a large vocabulary in a short time. Chats, sessions, models, context windows, memories, system prompts, projects, skills, connectors, agents, tools, sandboxes, permissions, and automations all describe real parts of these systems.
But exposing each one as a separate product concept asks users to understand more than they need to. We started by asking which concepts a person actually needs in order to work with an agent.
We kept coming back to five:
- Bots are persistent agents with their own identity, memory, runtime, and tools.
- Chats are the conversational interface for working with a Bot.
- Prompts give a Bot context or instructions. They can be used once, saved as Skills, or triggered automatically as Routines.
- Tools let Bots access information and take action through software, APIs, connectors, the shell, or computer use.
- Artifacts are the documents, designs, code, data, and other durable outputs that Bots create or modify.
Everything else could remain beneath the interface until the user had a reason to care about it. The next question was which of these five objects should organize the product.
From chat history to a Bot roster
Chats are disposable. We start a conversation to solve a problem. It gets pushed down the sidebar. A week later, we start another one. You rarely go back beyond the most recent five.
That behavior is perfectly reasonable when the unit of interaction is a question. It becomes strange when the thing on the other side of the interaction is supposed to know you, remember previous work, and take responsibility over time.
So the main objects in Grok Bot are Bots, not conversations. A Bot has a name. It has an avatar and a title. It remembers its conversations with you. It has its own computer and tools. When you come back tomorrow, you are coming back to the same Bot.
Project Acme
Draft a follow-up to Acme after Friday’s call
Rewrite the pricing one-pager
What should I ask in the security review?
Build a champion map from my call notes
Practice the demo with hard objections
Compare these three competitor decks for me
Show more
Kenny
7:34 PM
Need your yes on the Friday all-hands deck.
Justin
8 intros drafted — sitting in the CRM till you send.
John
Yesterday
Repro'd the checkout crash. Write-up's in the ticket.
Keith
Acme's wobbling. Drafted a Thursday check-in.
Presence as interface
Once a Bot was something you maintain over time rather than a session you start, the way Bots appear in the product had to answer three questions at once:
- Who is this?
- What are they doing?
- How much do I need to know?
Who is this
A roster only works if it can be scanned quickly. As the roster grows, we did not want people to have to read every name each time they opened the product. They should be able to recognize a Bot from its avatar almost peripherally.
Bot avatar visual style explorations by Kenny Kuh and Peng Zheng
At the same time, we wanted to keep the avatars consistent enough to read as one system. We studied character systems across illustration, animation, games, and interface design, exploring everything from initials and emojis to pixel art, watercolor, claymorphism, Noritake-style line art, silhouettes, and identicons.
Most approaches solved one side of the problem better than the other. Watercolor and clay gave individual Bots plenty of character but carried too much detail at sidebar scale. Simpler systems sat more naturally in the interface, but often left the Bots looking interchangeable.
The system we landed on keeps the basic construction consistent, using simple shapes and expressive eyes, then introduces distinction through controlled variations and accessories. Each Bot remains recognizable at a glance without appearing to come from a different visual world.
What are they doing
Once the avatar became the Bot’s identity, it was also the natural place to show state. A Bot may be idle, thinking, working, waiting, blocked, or done. We could have represented each state with a separate indicator, but that would have added another layer of UI for the user to interpret.
Instead, we explored how much of the lifecycle the avatar itself could carry.
At rest, the Bot is calm and slightly curious. When work arrives, it acknowledges the task. As work begins, it kicks into gear. Its motion changes again when it is waiting or needs help, then settles once the work is done. The avatar now shows what the Bot is doing as well as which Bot it is.
Idle Working Waiting Blocked Thinking Done
Avatar motion system by Benji Taylor
How much do I need to know
A related design question was how much of the Bot’s execution to show. One approach would have been the standard “three animated dots” but that would have been too little information, making it hard for users to tell whether the Bot was working or stuck.
Searching the web
Environment ready 387ms
Edited math.ts+14−10
Ran focused tests npm test
Ran type-check npm run
Thought briefly
Searched code“toFixed”
Read AGENTS.md
Edited math.test.ts+6−2
Ran full suite 212 passed
Committed fix: clamp NaN
Environment ready 387ms
Edited math.ts+14−10
Ran focused tests npm test
Ran type-check npm run
Thought briefly
Searched code“toFixed”
Read AGENTS.md
Edited math.test.ts+6−2
Ran full suite 212 passed
Committed fix: clamp NaN
We also tried showing a short written description of the Bot’s current action, but once people could see one step, they wanted to see the rest. User research showed us that they were asking for that detail mainly for reassurance that the Bot was still working and on the right track.
In the final design, the avatar’s motion provides the first bit of reassurance by showing that the Bot is active. If someone wants to check what it is doing, they can hover to see its current action.
Their computer, not yours
Each Bot has its own computer, which it can use to browse the web, work with files, and run software. This created another interface problem. How visible should that computer be and when should the user be able to control it?
We explored four arrangements:
- Floating window: kept the computer easy to reach but covered the conversation.
- Side by side: made the work continuously visible and encouraged users to watch it.
- Modal: made checking in easy but treated the Bot’s workspace as a temporary interruption.
- Full screen: gave the computer plenty of room but displaced the conversation entirely.
The more prominent we made the computer, the more the product encouraged users to supervise it. We decided it should remain the Bot’s workspace, with the interface providing different levels of access as the user needed them.
The final design has three levels, which allow the user to enter the Bot’s workspace without being drawn into operating it:
- Status: the title-bar icon turns purple while the computer is active.
- Preview: opening it reveals a pinned side panel where the user can follow the work without leaving the conversation.
- Takeover: when the Bot needs help, the user can open the computer full screen, take control, and then hand it back.
We also designed wallpapers that shift throughout the day, becoming lighter in the morning and darker at night. The detail gives the Bot’s computer its own sense of time and makes it feel separate from the user’s desktop.
Dynamic wallpaper by Kenny Kuh and Luke Barker.
It is closer to working with a coworker than operating a remote machine. You can tell that they are working, glance at their screen when you need context, and sit down when something requires your help.
The shape of information
Early versions of Grok Bot responded to almost every request with prose. It described a five-day forecast instead of showing one and narrated a set of tasks instead of laying them out as a board. The user then had to restructure the answer. This led us to treat the form of a response as part of the answer.
To support this, we built inline cards and widgets into Grok Bot. A Bot can answer in prose when prose fits the information and use structured UI when it does not.
New email
Ready to send
From peng@grokbot.app
To sarah@acme.com
Subject Moving Friday’s design review to 2 PM
Hi Sarah,
Could we move Friday’s design review from 11 AM to 2 PM? A client call came up and I don’t want to rush our discussion.
Thanks,
Peng
Send email Discard
Inline chat widgets by Peng Zheng
The same principle applies to actions. When a Bot creates a Routine, changes a setting, or messages another Bot, the event can appear directly in the transcript. The user can open it when there is more to inspect.
9:41 AM
Morning! Can you check in with everyone for me?
On it — pinging the team for status now
6 messages with Kenny Tyler and Jenny
All on track: Kenny shipped the landing page, Tyler sent this month's invoices, and Jenny booked next week's interviews. No blockers.
Love it, can you do this every morning?
Created Routine Morning Briefing
Done, your Morning Briefing will be here at 9:00 every day
The result is a heterogeneous transcript in which conversation, system events, interactive objects, and visualizations share one timeline.
Organizing intelligence
Once people create several Bots, the product also has to organize how those Bots work together. We needed to decide which context should belong to each role, how Bots should share context when their work overlaps, and how to coordinate them without turning the user into a dispatcher.
We saw one answer emerge as people created more Bots. Some made a Chief of Staff Bot responsible for coordinating several specialists. They could give direction to one Bot instead of checking each one and routing every task themselves.
Giving Bots distinct roles also forced us to decide what each role should know. A legal Bot may need the history of an ongoing dispute, while a finance Bot may need years of financial records. Combining those histories into one large memory would make it harder to give each Bot the information relevant to its work.
Capabilities and context therefore follow different boundaries in Grok Bot. Tools and Skills live at the account level because many Bots may need to browse the web, work with documents, or send email. Memory and Routines belong to the Bot because they reflect what that particular role knows and does over time. Put another way, capabilities can be shared broadly while context remains with the role that needs it.
Some work crosses those role boundaries. Group chats provide shared context for a project or team while allowing each Bot to retain its specialized memory. A designer, engineer, PM, and data scientist can work in the same conversation, hand work to one another, and share what the project requires.
We considered adding dashboards, assignment boards, and explicit handoff controls to manage these groups. Each one gave the user more coordination work. Instead, coordinating Bots handle routine routing and bring the user in when a decision requires judgment.
Work that keeps moving
Most agent sessions begin when a user sends a prompt. That leaves even a persistent Bot waiting for someone to activate it. Routines let users give a Bot a standing responsibility that runs on a schedule or in response to an event, such as watching an industry or preparing a briefing every morning. The user defines the work once, and the Routine activates the Bot when it needs to happen.
We initially treated Routines as secondary configuration. As they became more important to autonomous work, we moved them into the Bot’s main interface. The transcript shows what ran and gives the user a place to review the result or handle an exception.
Every day at 8:00 AM
On weekdays at 8:00 AM
Every Monday at 9:00 AM
Monthly on the 1st at 8:00 AM
Every 30 minutes
On weekdays · 9:00 AM
Issue created in grokbot
Issue any event in all projects
Incident triggered on grokbot
Incident any event on grokbot
PR opened in grokbot
PR merged in spacexai
PR closed in acme
New push to main
Checks fail on PRs in grokbot
Label bug added in grokbot
Comment containing/fix in ops
Review approved in grokbot
Thread resolved in grokbot
Workflow deploy.yml fails
When webhook receives a POST
New messages in#grokbot
Reaction:eyes:added in#ops
Channel created matching dev
New messages in#design
Issue created in Roadmap
Issue status →In Review in Core
At end of cycle for Team Core
Issue status →Done in Design
New messages in Design team
Channel created in Design team
This also changes the role of conversation. A prompt can start a session, but so can a schedule, an event, or another Bot. Over time, more work may begin without the user being present at all.
The disappearing interface
By the end of the project, much of the design work involved taking things away. We removed window and panel controls, computer-view options, and agent metadata. We also set practical limits of roughly 50 Bots per account and six per group chat. Each decision came back to the same question: Did this help someone delegate, or did it give them one more thing to manage?
The line between operating an AI and delegating to a coworker keeps moving as models improve. Grok Bot reflects where we think it sits today. Designing Grok Bot from its earliest explorations through launch has been about finding that line and helping the interface change with it. As agents take on more responsibility, the interface should ask less of the person.