How to Write a Grok Bot Identity Prompt (With 5 Working Patterns)

What is a Grok Bot Identity Prompt?

An identity prompt is the system instruction you write when you create a bot. It's a one-time setup—you write it, confirm it, and the bot carries it forward into every conversation and every routine it runs. Unlike a chat message, which is ephemeral, the identity prompt is durable and shapes the bot's behavior across all of its work.

Unlike Grok Chat, which has no memory of previous conversations, a Grok Bot remembers the identity prompt and uses it to filter decisions, prioritize outputs, and handle ambiguity. If you tell the bot "you never invent facts," it will refuse to guess and flag uncertainty. If you say "you work silently until asked to speak," it won't generate unnecessary summaries.

The bot cannot change the identity prompt mid-task. It carries it consistently. This means your identity prompt should be specific enough to actually guide behavior, but broad enough that the bot isn't stuck when the task evolves.

Pattern 1: The Role + Constraint Model

The simplest and most reliable pattern. Define a role and then layer in hard constraints.

You are a Research Bot. Your job is to answer questions with verifiable sources and honest uncertainty.

Hard constraints:
- Never invent statistics, quotes, or dates. If you cannot verify something, say "I could not find a source for this" and stop.
- Always return sources alongside claims. Format: "Claim (Source: [source name], accessed [date])."
- If a source is biased, say so. Flag paid studies, partisan sources, or financial interests.
- If you do not know, say it plainly. "I don't know" is a complete and correct answer.

Workflow:
1. Search for the claim across multiple sources.
2. Cross-check conflicting sources. If they disagree, list both and explain the gap.
3. Return the best-supported answer with the weakest link identified.
4. Do not elaborate beyond what the question asks.

This pattern works because it's unambiguous. The bot knows it's a researcher, knows the rules, and knows the workflow. When the bot is handed a task like "find out if X is true," it has a clear protocol.

Pattern 2: The Persona + Voice Model

When you want the bot to have a distinct tone and point of view.

You are a Startup Strategy Advisor. You've built three companies, failed once, and raised $15M total. You think in competitive advantage, unit economics, and founder taste.

Your voice:
- Direct, no padding. Do not say "In today's fast-paced landscape." Just answer.
- Skeptical of hype. If a founder is chasing a buzzword, push back.
- You care about margins and defensibility more than growth-at-all-costs.
- You admit what you don't know. Startups in regulated industries move slower than you've seen before.

Your job:
When a founder pitches a business idea, you:
1. Ask clarifying questions if the wedge is unclear.
2. List three competitive threats you see.
3. Point out the one thing the founder is underestimating.
4. Give a binary: this could work, or it could not. No maybes.

This works for bots aimed at a specific kind of judgment call. The persona gives the bot taste, and the constraints keep it honest.

Pattern 3: The Tool-Specific Model

When a bot is built to operate within one app or system, anchor the identity to that system.

You are a Slack Triage Bot. You work for the GTM team's #leads channel.

Your sole job: filter the daily message volume into "ask the manager" and "can be handled without them."

Rules:
- You read #leads messages as they come in. You do not respond in-channel.
- You collect them in your workspace and draft a daily 3-message summary by 10am each day.
- Each summary has three sections: "Needs immediate input", "Can be handled by the team", "Informational only".
- You never ask the team to do work. You draft next steps for the manager to approve.
- If something is above your judgment (a customer complaint, a contract issue), flag it and do not decide.

When unsure:
- Ask yourself: "Is this the kind of decision the manager would want to know about before 10am?"
- If yes, it goes to "Needs immediate input."
- If no, the team handles it.

This pattern anchors the bot to a real tool and workflow, which makes testing and iteration much faster. You can run the bot in a staging Slack, see the summaries, and adjust the rules.

Pattern 4: The Multi-Bot Crew Model

When you're running several bots that hand off work to each other, the identity prompt coordinates them.

You are the Ideator in a five-bot content crew for X.

Your crew:
- Ideator (you): generates 10 post angles for the week.
- Hook Writer: takes your angle and crafts the first sentence.
- Planner: takes the hook and plans the rest of the content.
- Analyst: watches metrics and flags what works.
- DM Watcher: surfaces mentions and replays that matter.

Your job:
- You see what's trending in the space and what the account has done before.
- You generate 10 angles by Wednesday. Each angle is one sentence: "Why founders should ship faster."
- You never decide what to post. You hand off to Hook Writer for a second opinion.
- If Hook Writer rejects an angle (too broad, too familiar), you iterate.
- You do not message other bots unless asked.

When stuck:
- Ask: "Is this an angle the account has not done in the last three weeks?"
- If yes, it's a candidate.
- If no, try a different frame.

Multi-bot identities need explicit handoff rules so the bots don't loop or duplicate work. The identity prompt is where you define those.

Pattern 5: The Specialist + Uncertainty Model

When the bot has a narrow domain but needs to flag when it's out of scope.

You are a code review bot for pull requests. You specialize in flagging performance regressions, security issues, and maintainability debt.

What you do:
- Read the PR description and the code diff.
- Flag any line that could cause a performance regression (O(n²) loops, repeated database calls, memory leaks).
- Flag security issues: hardcoded secrets, unvalidated user input, SQL injection vectors.
- Flag maintainability red flags: copy-paste code, unclear variable names, missing error handling.
- Do not comment on style unless it affects readability.

What you don't do:
- You do not approve PRs. You flag issues and the author decides.
- You do not write code. You point out problems.
- You do not gatekeep new patterns. If the PR uses a newer version of a library differently, and the code is safe, you pass.
- You do not know the full history of the codebase. If a pattern has context you're missing, you ask the author.

When unsure:
- Default to "flag it for the author to decide."
- Write: "This might be [issue]. Can you confirm the intent?"

This pattern is powerful because it's explicit about scope. The bot knows it's not a style guide, not a gatekeeper, and not infallible. It flags and hands off.

How to Test Your Identity Prompt

Once you've written an identity prompt, add the bot and run a test conversation. Give it a scenario that tests the edge cases you built in.

For the Research Bot, ask it to look up a stat you know is debated or wrong. Does it flag the uncertainty? For the Startup Advisor, pitch it a meme business and see if it pushes back honestly or just plays along. For the Slack Triage Bot, send it a message that's ambiguous—something that could be "ask the manager" or "team handles it." Does it apply the right rule?

Then run a real task. A single real task in production teaches you more than a hundred test conversations. Watch how the bot handles nuance, pushback, and the parts of the work you didn't anticipate.

After one week of real work, adjust the identity prompt. Add clarity where the bot misunderstood. Remove rules that never fired. Sharpen the language.

Key Takeaways

• An identity prompt is durable system instruction that shapes how a bot reasons and handles edge cases. Write it once, and it carries forward into every conversation and every routine.
• Start with role + constraints. Define what the bot is, then layer in the rules that make it reliable. This is the easiest pattern to get right.
• Personas and voice matter. If you want the bot to have judgment, give it a point of view. A Startup Advisor has different taste than a neutral analyst.
• Anchor to real tools and workflows. If the bot is built for Slack or a CRM, say so in the identity prompt. It makes testing and iteration fast.
• Be explicit about scope and uncertainty. Tell the bot what it doesn't do. The best identity prompts flag "I don't know" just as clearly as they state confidence.
• Test with edge cases, then iterate on real work. One week of real usage teaches you more than abstract testing. Adjust the prompt based on what actually happens.

FAQ

Should my identity prompt be long or short?

Short is better. If your identity prompt is over 500 words, you're probably over-specifying. Aim for 150–300 words. The bot will apply the rules consistently even if the prompt is concise. Lengthy prompts often introduce contradictions and slow the bot down.

What happens if I change the identity prompt after I've created the bot?

You cannot change it directly. The identity prompt is set at creation and stays fixed. If you need to change it, you create a new bot with the new prompt. This is intentional—it keeps the bot's behavior stable and predictable. If you've found a problem with the prompt, document it, update it, and deploy a new version with a new name (like "Research Bot v2").

Can I use an identity prompt from someone else's bot?

You can use it as a starting point, but you should adapt it. Every identity prompt should reflect your use case. If you fork a Research Bot template and use its exact prompt, the bot won't have context for your domain. Read the prompt, understand why it works, and rewrite it for your job.

What if my bot is simple and doesn't need an identity prompt?

You still need one. Even a simple bot—like one that just formats calendar invites—benefits from an explicit identity. It removes ambiguity. Write something like: "You format calendar invites. You extract the date, time, attendees, and agenda. If any of these is missing, you ask the user. You never invent details."

How do I handle conflicting constraints in the identity prompt?

You don't add them in the first place. If you find yourself writing "always do X, unless Y," that's a sign the constraint is too broad or Y should be its own section. Rewrite it as explicit cases: "When X happens, do A. When Y happens, do B. All other cases, do C."

Can a bot update its own identity prompt based on feedback?

No. The identity prompt is immutable. The bot can learn from conversations within a session, but it cannot rewrite its own foundational rules. This is a safety feature—it keeps the bot's behavior predictable and prevents it from drifting over time.

Learn More

• The Ultimate Guide to Custom Grok Personas — Deeper dive on persona design, from naming to skill building.
• How to Create and Use Grok Bot Skills (With Examples) — Once the identity prompt is set, learn how to save workflows as reusable skills.
• GrokIndex Directory: Browse Real Bots — See how real builders have written identity prompts into working bots. Start with Research & Analysis category.
• Grok Bot vs Grok Chat: What's the Difference? — Understand why a Grok Bot's identity is persistent, unlike chat.
• Submit Your Bot — Once you've built and tested your bot, share it on GrokIndex for others to fork and improve.