{"id":835431,"date":"2026-09-03T20:56:16","date_gmt":"2026-09-03T20:56:16","guid":{"rendered":"https:\/\/www.newsbeep.com\/us\/835431\/"},"modified":"2026-09-03T20:56:16","modified_gmt":"2026-09-03T20:56:16","slug":"designing-grok-bot-for-a-world-of-persistent-agents","status":"publish","type":"post","link":"https:\/\/www.newsbeep.com\/us\/835431\/","title":{"rendered":"Designing Grok Bot for a world of persistent agents"},"content":{"rendered":"

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.<\/p>\n

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.<\/p>\n

\"\"\"\"<\/p>\n

Need your yes on the Friday all-hands deck.<\/p>\n

8 intros drafted \u2014 sitting in the CRM till you send.<\/p>\n

Inbox’s at 3. Two need a reply today.<\/p>\n

John: checkout’s clean on staging, 3 bugs closed.<\/p>\n

Repro’d the checkout crash. Write-up’s in the ticket.<\/p>\n

Acme’s wobbling. Drafted a Thursday check-in.<\/p>\n

14 receipts in. Still missing your Uber from Tuesday.<\/p>\n

Launch post is live. First 200 impressions.<\/p>\n

3 places in SoMa. The Folsom 2bed is the one.<\/p>\n

Sourced 3. Skipped one already in your ATS.<\/p>\n

\"\"<\/p>\n

Peng Zheng<\/p>\n

9:41 AM<\/p>\n

Hey, what were the main takeaways from today\u2019s design sync?<\/p>\n

The team spent most of the session reviewing the new onboarding flow.<\/p>\n

The biggest discussion was around the empty states. Sarah felt the current illustrations don\u2019t 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.<\/p>\n

The overall mood was positive though. Most people think the flow is close to ready for a wider review.<\/p>\n

Did anyone bring up the Q3 roadmap?<\/p>\n

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.<\/p>\n

Routines<\/p>\n

Morning briefing<\/p>\n

Every day at 8:00 AM<\/p>\n

Inbox cleanup<\/p>\n

Weekdays at 6:00 PM<\/p>\n

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.<\/p>\n

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.<\/p>\n

We kept coming back to five:<\/p>\n

Bots are persistent agents with their own identity, memory, runtime, and tools.
\nChats are the conversational interface for working with a Bot.
\nPrompts give a Bot context or instructions. They can be used once, saved as Skills, or triggered automatically as Routines.
\nTools let Bots access information and take action through software, APIs, connectors, the shell, or computer use.
\nArtifacts are the documents, designs, code, data, and other durable outputs that Bots create or modify.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

Draft a follow-up to Acme after Friday\u2019s call<\/p>\n

Rewrite the pricing one-pager<\/p>\n

What should I ask in the security review?<\/p>\n

Build a champion map from my call notes<\/p>\n

Practice the demo with hard objections<\/p>\n

Compare these three competitor decks for me<\/p>\n

Need your yes on the Friday all-hands deck.<\/p>\n

8 intros drafted \u2014 sitting in the CRM till you send.<\/p>\n

Repro’d the checkout crash. Write-up’s in the ticket.<\/p>\n

Acme’s wobbling. Drafted a Thursday check-in.<\/p>\n

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:<\/p>\n

Who is this?
\nWhat are they doing?
\nHow much do I need to know?<\/p>\n

Who is this<\/a><\/p>\n

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.<\/p>\n

Bot avatar visual style explorations by Kenny Kuh and Peng Zheng<\/p>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

What are they doing<\/a><\/p>\n

Once the avatar became the Bot\u2019s 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.<\/p>\n

Instead, we explored how much of the lifecycle the avatar itself could carry.<\/p>\n

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.<\/p>\n

IdleWorkingWaitingBlockedThinkingDone<\/p>\n

Avatar motion system by Benji Taylor
\nHow much do I need to know<\/a><\/p>\n

A related design question was how much of the Bot\u2019s execution to show. One approach would have been the standard \u201cthree animated dots\u201d but that would have been too little information, making it hard for users to tell whether the Bot was working or stuck.<\/p>\n

Environment ready 387msEdited math.ts +14 \u221210Ran focused tests npm testRan type-check npm runThought brieflySearched code \u201ctoFixed\u201dRead AGENTS.mdEdited math.test.ts +6 \u22122Ran full suite 212 passedCommitted fix: clamp NaNEnvironment ready 387msEdited math.ts +14 \u221210Ran focused tests npm testRan type-check npm runThought brieflySearched code \u201ctoFixed\u201dRead AGENTS.mdEdited math.test.ts +6 \u22122Ran full suite 212 passedCommitted fix: clamp NaN<\/p>\n

We also tried showing a short written description of the Bot\u2019s 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.<\/p>\n

In the final design, the avatar\u2019s 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.<\/p>\n

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?<\/p>\n

We explored four arrangements:<\/p>\n

Floating window: kept the computer easy to reach but covered the conversation.
\nSide by side: made the work continuously visible and encouraged users to watch it.
\nModal: made checking in easy but treated the Bot\u2019s workspace as a temporary interruption.
\nFull screen: gave the computer plenty of room but displaced the conversation entirely.<\/p>\n

The more prominent we made the computer, the more the product encouraged users to supervise it. We decided it should remain the Bot\u2019s workspace, with the interface providing different levels of access as the user needed them.<\/p>\n

The final design has three levels, which allow the user to enter the Bot\u2019s workspace without being drawn into operating it:<\/p>\n

Status: the title-bar icon turns purple while the computer is active.
\nPreview: opening it reveals a pinned side panel where the user can follow the work without leaving the conversation.
\nTakeover: when the Bot needs help, the user can open the computer full screen, take control, and then hand it back.<\/p>\n

\"\"\"\"<\/p>\n

We also designed wallpapers that shift throughout the day, becoming lighter in the morning and darker at night. The detail gives the Bot\u2019s computer its own sense of time and makes it feel separate from the user\u2019s desktop.<\/p>\n

Dynamic wallpaper by Kenny Kuh and Luke Barker.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

Frompeng@grokbot.app<\/p>\n

Tosarah@acme.com<\/p>\n

SubjectMoving Friday\u2019s design review to 2 PM<\/p>\n

Hi Sarah,<\/p>\n

Could we move Friday\u2019s design review from 11 AM to 2 PM? A client call came up and I don\u2019t want to rush our discussion.<\/p>\n

Thanks,
Peng<\/p>\n

Send emailDiscard<\/p>\n

Inline chat widgets by Peng Zheng<\/p>\n

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.<\/p>\n

9:41 AM<\/p>\n

Morning! Can you check in with everyone for me?<\/p>\n

On it \u2014 pinging the team for status now<\/p>\n

6 messages withKennyTylerandJenny<\/p>\n

All on track: Kenny shipped the landing page, Tyler sent this month’s invoices, and Jenny booked next week’s interviews. No blockers.<\/p>\n

Love it, can you do this every morning?<\/p>\n

Created RoutineMorning Briefing<\/p>\n

Done, your Morning Briefing will be here at 9:00 every day<\/p>\n

The result is a heterogeneous transcript in which conversation, system events, interactive objects, and visualizations share one timeline.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

We initially treated Routines as secondary configuration. As they became more important to autonomous work, we moved them into the Bot\u2019s main interface. The transcript shows what ran and gives the user a place to review the result or handle an exception.<\/p>\n

Monthly on the 1st at 8:00 AM<\/p>\n

Issue any event in all projects<\/p>\n

Incident triggered on grokbot<\/p>\n

Incident any event on grokbot<\/p>\n

Checks fail on PRs in grokbot<\/p>\n

Label bug added in grokbot<\/p>\n

Comment containing \/fix in ops<\/p>\n

Review approved in grokbot<\/p>\n

Thread resolved in grokbot<\/p>\n

Workflow deploy.yml fails<\/p>\n

When webhook receives a POST<\/p>\n

Reaction :eyes: added in #ops<\/p>\n

Channel created matching dev<\/p>\n

Issue status \u2192 In Review in Core<\/p>\n

At end of cycle for Team Core<\/p>\n

Issue status \u2192 Done in Design<\/p>\n

New messages in Design team<\/p>\n

Channel created in Design team<\/p>\n

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.<\/p>\n

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?<\/p>\n

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.<\/p>\n","protected":false},"excerpt":{"rendered":"When we started designing Grok Bot, one of the central questions was how the interface should shape the…\n","protected":false},"author":2,"featured_media":835432,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[45],"tags":[182,181,507,74],"class_list":["post-835431","post","type-post","status-publish","format-standard","has-post-thumbnail","category-artificial-intelligence","tag-ai","tag-artificial-intelligence","tag-artificialintelligence","tag-technology"],"_links":{"self":[{"href":"https:\/\/www.newsbeep.com\/us\/wp-json\/wp\/v2\/posts\/835431","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.newsbeep.com\/us\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.newsbeep.com\/us\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.newsbeep.com\/us\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.newsbeep.com\/us\/wp-json\/wp\/v2\/comments?post=835431"}],"version-history":[{"count":0,"href":"https:\/\/www.newsbeep.com\/us\/wp-json\/wp\/v2\/posts\/835431\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.newsbeep.com\/us\/wp-json\/wp\/v2\/media\/835432"}],"wp:attachment":[{"href":"https:\/\/www.newsbeep.com\/us\/wp-json\/wp\/v2\/media?parent=835431"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.newsbeep.com\/us\/wp-json\/wp\/v2\/categories?post=835431"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.newsbeep.com\/us\/wp-json\/wp\/v2\/tags?post=835431"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}