Grok Bot: show and edit Bot role description in the info pane (match docs)

Ideas Feature Requests
1

Feature request for product/service

Chat

Describe the request

Title: Grok Bot: show and edit Bot role description in the info pane (match docs)

Problem
Official docs say role definition lives in the Bot description, edited via conversation details → Bot settings (name, label, description, notifications). See /docs/grok-bot/work and /docs/grok-bot/settings.

On current desktop, opening the Bot info pane (name / Cmd+Shift+I) shows Details / Media / Computer with name, Add a label, and Routines — and no Bot settings entry and no description field. The documented edit path for the role brief is missing from the UI I actually get.

Workaround: ask the Bot in chat to update its profile description (agent-side write). That can persist, but the user still cannot see or review the role text in the info pane. Role description is the standing job brief (what this Bot is for), not the same as historical Memory facts.

What the docs say a role description is
Across official docs, description is framed as a single durable role brief — not chat, not Memory logs, not a skill SOP:

  • Describe the role in operational terms (owned outcome, what you pull/produce, approval boundary). Example: weekly account-health review → linked watch list; never contact customers without approval. (/docs/grok-bot/work)
  • Put job, source systems, output format, and standing boundaries in the description. (/docs/grok-bot/use-cases)
  • Update description for durable preferences/boundaries; use the conversation for task-specific asks (Edit a Bot). (/docs/grok-bot/work)
  • Create-flow example Description: investigate with observability tools; preserve links/screenshots; never change production. (/docs/grok-bot/get-started)

Assumption those docs leave: the role description is one editable string the user should be able to review and change in Bot settings next to name and label. There is no deeper schema in the docs — which makes a missing review/edit UI a product gap, not a missing “advanced role model.”

Why Memory management is not this ask
Forum topic: /t/grok-bot-desktop-ios-memory-management/168066

That FR is about viewing/editing accumulated profile + log facts. This FR is about the standing role brief (description): inspectable and editable where the product already documents Bot settings — adjacent to name and label, not a memory dump.

Framing
Keep chat for task-specific instructions; keep description for durable job + boundaries (per docs). The gap is discoverability and inspection, not inventing a new store. Chat-side profile update can stay as a power path; the default human path should match the docs.

Request
Expose Bot settings (or equivalent) from the info pane / name menu so description is visible and editable alongside name and label.
Show the current description in plain language in Details (read view), not only after hunting a hidden editor.
Keep label as the short chip; keep description as the longer operational role text.
Optional: if chat-driven profile updates remain supported, reflect them immediately in that same UI.
Why
Without a visible description editor, users cannot confirm what role the Bot is actually holding, cannot iterate on the brief without asking the Bot to rewrite itself, and docs/UI disagree. Multi-Bot setups depend on clear, reviewable role boundaries; that fails if the role field is write-only via chat and invisible in the pane.

Acceptance
From the Bot info pane (or documented Bot settings entry point), user can view and edit description.
After edit (UI or chat-side update), the pane shows the current description without opening files on the computer.
Docs path and UI path match: name, label, description in one place.
Distinct from Memory inspector: this is role/description only.
Naming note
Docs call this description (role / job). Add a label in the pane is the short title/label, not the role body. This FR is about the description field, not renaming Memory.

4

I am having the exact same issue, it used to be like that, this needs to be moved to BUG. Because we used to be able to edit our bots just like that but in one of these updates the past few days, changed it and now the edit description field is gone on all bots.

5

I never saw it work so didn’t know if it was a possible bug. Makes sense since it’s a documented feature.

7

Hey, thanks for the detailed breakdown, and especially for separating Description and Memory. They really are different things.

You’re right: the docs and the current desktop app UI don’t match right now. In the updated conversation details pane for personal Bots, there’s no longer a separate Bot settings page with a description field. What’s left is Details / Media / Computer. For Team Bots, the description shows up in the About section. The docs still describe the old layout.

@Juniya-Sankara, yeah, you’re both seeing the same thing, and it’s not something in your setup. The pane layout changed recently. This is a known issue we’re tracking, including the mismatch with the docs. I can’t share a timeline yet.

About the chat-based workaround like “ask the Bot to update its description”, with the current layout it doesn’t give reliable results. There isn’t a dedicated field to view or edit the role brief in the pane for personal Bots right now. I don’t want to recommend something that might not work.

8

General feedback: this is really confusing. It’s not clear how to make a bot take a specific role and asking the bots whether they can read/use their own instructions they can give unclear answers:

I work from a brief for this role, but I don’t open it up or quote it. What I can do is the marketing work itself. What do you want next?

If you’re removing the Instructions section from the bot pane, please prioritise whatever you’re replacing it with.

12

Hey, thanks for the feedback. You’re right.

What you’re describing is the same issue mentioned above. In the updated details pane for personal Bots, the separate description/instructions section is gone. Because of that, it’s unclear what briefing the role is actually holding. That’s also why the bot’s answers about its own instructions can sound vague.

This isn’t caused by anything in your setup. The pane layout changed recently. We’re aware of the issue and we’re tracking it, including the mismatch with the docs. I can’t share a timeline yet, but I’ll reply in the thread when there’s an update.

For Team Bots, the description is currently visible in the About section. For personal Bots, there isn’t a reliable way right now to set and view the role through the pane, so I wouldn’t suggest a chat workaround since it doesn’t give stable results in the current layout.

13

Thanks Dan,

I’m sure Cursor won’t keep this unresolved for long. I really love GrokBots and I, as I suppose thousand others, really need to be on top of their bots configurations

Cheers

Adriano

14

Thanks Dean for the updates and for confirming this is tracked. And thanks greatgoodfineok for the example. A bot saying it works from a brief it won’t open or quote is exactly why this matters.

Near term: for personal Bots, please bring back a way to see and edit the role description in the pane, like the About section Team Bots already have. Even a read-only view would help.

Where I hope this goes: I think role definitions will become the most important part of Grok Bot, and one text field won’t be enough for long. I’d like the role description to become the root of a hybrid: an LLM Wiki–style vault (along the lines of Karpathy’s “LLM Knowledge Bases” pattern) for what the bot knows, plus a QRH-style index of procedures for what it does when specific situations come up.

How it would work:

  • Role brief as the root page. The description says what the bot is for and its standing boundaries. It’s always loaded and always visible to the user.
  • Knowledge vault. Curated domain knowledge, linked and kept current. The bot sees a short index and opens full pages only when they’re relevant.
  • Procedure index. Vetted procedures, each with a one-line “use when…” trigger. Think of a pilot’s Quick Reference Handbook: a few memory items always in mind, and vetted procedures looked up by condition when they’re needed. The bot recognizes the situation and follows the matching procedure instead of improvising.
  • Composer-owned vs. bot-owned. The person who defines the role owns the vault and the procedures. The bot can keep its own working notes from sessions, but it can’t silently rewrite its role. It proposes changes, and the composer accepts or rejects them, like a pull request.

Why this matters: in practice a bot reasons from whatever knowledge it can reach. Whoever curates that knowledge shapes how the bot thinks and acts. Today that’s opaque: the brief is hidden, changes happen through chat, and the bot can’t explain what it’s working from. A composer-curated vault and procedure index make the role inspectable, editable and improvable over time, and give multi-bot setups the clear boundaries they need. It also stays separate from Memory, which is about what the bot has learned about the user, not what job it was given.

Question: is the replacement for the old description section heading anywhere near this direction? Even a rough sense of the roadmap would help those of us building multi-bot setups decide how to structure roles now.

15

Hey, thanks for the detailed perspective, benum, and thanks to you too, Adriano, for the reply.

On the near-term request: bringing back the ability for personal Bots to show and edit the role description directly in the pane, or at least show it as read-only like About for Team Bots, is exactly what we’re tracking. As I mentioned above, this isn’t due to your setup. The layout changed recently. I still can’t share a timeline, but I’ll reply in the thread once there’s an update.

On the bigger picture, the knowledge vault as a root page, a procedure index with triggers like “use when…”, and a composer-owned vs bot-owned model with clear accept/reject role changes is a strong and well thought out framework. Thanks for writing it up. I’ve passed it along to the team as product feedback. It’s also much broader than bringing back the missing field, so I’m keeping it separate from the main issue.

I can’t comment on roadmap direction, since we don’t share plans in advance. But the request is noted, and if anything comes up in this area that I can share, I’ll post here.

16

Thank you Dan!