Building an AI Idea Generator With Grok Bot

I don't think AI has good taste or judgment. It can write a convincing pitch for something I have no interest in building.

I'm using Grok Bot as an idea generator anyway. I give it my interests, let it bring back suggestions, and tell it what I think. Sometimes the useful part is figuring out why a suggestion is wrong. That reaction might lead me to an idea of my own.

The experiment keeps evolving as I use it. Here is how I am approaching it, along with a setup you can adapt.

Why a persistent bot?

The inspiration was browser-use/agency: an agent that learns about you, investigates useful work, and brings back something concrete to consider. I initially called mine Agency, then renamed it Idea Generator as I narrowed its job.

I adapted the approach to Grok Bot, using chat and routines instead of Agency's local card application. Grok Bot supports ongoing conversations, memory, tools, and recurring work. I wanted somewhere to accumulate my feedback and keep refining the instructions.

Persistence matters because my reaction to today's suggestion should affect tomorrow's. If I have to explain the same objection every morning, saving the conversation has done very little for me.

Give it enough context to disagree usefully

“Give me good ideas” leaves too much undefined. I want the bot to know what interests me, what I enjoy making, what I have already considered, and what would make a project unattractive.

Start with a short profile. Include a few things you like and dislike, with reasons. The reasons are what let the bot apply your feedback to something new.

For example, “I prefer tools I can use locally because I don't want to operate a hosted service” is more informative than “I like scripts.” It leaves room for different implementations while explaining the constraint.

Be careful about turning a single rejection into a permanent rule. Rejecting one subscription product does not mean every paid product is off the table. Ask the bot to show you the preference it plans to save, and correct it if it has generalized too far.

Set up one manual run first

Grok Bot's introduction describes creating a bot, giving it work through chat, and saving workflows as routines. The sequence below is a suggested setup. I have condensed the instructions for readers to adapt.

1. Create a bot called Idea Generator. Give it your short profile and ask it to save that context. Ask where it stored the profile so you can inspect and edit it.
2. Give it the instructions below. Ask it to confirm whether it can search public sources. If search is unavailable, resolve that before relying on its claims about what exists.
3. Run the job once in chat. Inspect the sources and the suggestions before adding a schedule.
4. Give specific feedback. Review what the bot saves about your preferences and the ideas it has already shown you.
5. Start a new chat with the same bot. Ask it to retrieve that feedback and identify the previous suggestions before generating more. Repeating the words “I remember” is insufficient; it should recover the actual details.
6. Create a routine after that works. Choose a cadence and timezone, inspect the saved schedule, and check the first scheduled result. A scheduling request in chat is only complete once the routine exists and runs.

Here is a condensed starter prompt. Its checks help organize the suggestions; I still decide what is interesting.

You are my Idea Generator. Bring me fresh possibilities to think about.

Read my saved profile, feedback, and previous suggestions before each run.
Use public search to find new material relevant to my interests.

For each suggestion:
- Explain what I could do and how it would work.
- Link the sources behind factual claims.
- Find the closest existing examples and explain the difference.
- State uncertainty and label speculation.
- Compare it with suggestions you have already shown me.

Keep usefulness, feasibility, novelty, and variety separate.
Include unusual possibilities even when their usefulness is unclear.
Drop renamed repeats and unsupported claims about effort or outcomes.

For a concrete project, identify one necessary assumption and a small
experiment that could show it is false.

After I respond, propose a short preference update for me to review.
Keep a record of suggestions so future runs can check for repetition.
Keep outputs in this chat. Publishing or messaging others requires
my explicit approval.

I have been collecting the repeatable instructions in a skill called Idea Generator OS, alongside a profile and recurring routine. You can begin with a saved instruction set and refine it after a few runs.

For this experiment, public search and private drafts are enough to start. Keep publishing and messaging tools disconnected unless you need them. If you enable them later, use approval controls enforced by the runtime; a sentence in a prompt cannot enforce that boundary.

What useful feedback looks like

Here is a hypothetical example, separate from my actual work.

Suggestion: Build a subscription website that watches software documentation and emails developers a daily summary of changes.

I might respond:

I like detecting changes that affect software I use. I don't want to run a subscription website or read another daily digest. A local tool that checks the dependencies in one repository would be more interesting to me. Don't assume every documentation change needs my attention.

That response identifies the part worth keeping, the parts I dislike, and a possible direction. The preference update could be:

For developer-tool ideas, prioritize relevance to a specific repository.
The user prefers a local experiment over operating a hosted service
for this suggestion. Generic daily digests are unappealing.

Notice the limited scope. “Never suggest hosted software” would overstate the feedback.

A follow-up could explore checking release notes against the versions in a lockfile. That possibility still needs investigation. Existing dependency tools may already cover the useful part, and mapping a release note to actual impact could be unreliable.

This is the interaction I want: something concrete enough to react to, followed by a correction the bot can use. I may end up pursuing something quite different from its original suggestion.

Search twice, for different reasons

The first search supplies new material: a tool release, an unfamiliar technique, or a problem people keep describing.

The second search challenges the suggestion. Who already does this? What is the closest implementation? What would be different about mine?

I want links and a description of the search's limits. Failing to find a match does not establish novelty. Another model approving the idea does not establish it either.

Variety also needs a better definition than different product names. In the documentation example, collecting changes, filtering them by installed version, and testing whether an upgrade breaks the application solve different parts of the problem. Moving the same summary into a browser extension adds little variety.

Ask what would make the project fail

For something I might build, I want one necessary assumption and a cheap way to challenge it.

Continuing the hypothetical example:

Field	Example
Necessary assumption	Release notes provide enough version-specific information to identify changes relevant to the repository.
Disconfirming test	Take a few known upgrades, inspect their release notes, and compare the tool's findings with the changes a developer identified manually.
Reason to stop or change direction	It repeatedly misses relevant changes or cannot distinguish affected versions.

A small check can expose a flaw. Passing it would justify more investigation, not establish reliability.

That is more useful to me than a creativity score. It gives me something to try before committing to the project.

What the research contributed

I gave the bot a ChatGPT Pro synthesis of AI ideation research to help refine the process. Two lessons were particularly relevant.

A promising proposal can disappoint during execution. Si, Yang, and Hashimoto's ICLR 2025 study found that reviewers rated LLM-generated NLP research ideas as more novel than expert-written ideas, with somewhat weaker feasibility ratings. In the later ideation-execution gap preprint, that advantage closed after researchers implemented the ideas. This gave me another reason to ask for small tests before getting attached to a proposal.

Repeated generation can get stuck in a narrow range. Deng, Brucks, and Toubia examine fixation and limited diversity in LLM-generated ideas. I took that as a reason to ask for different approaches and compare suggestions across runs.

These studies informed the instructions. I have not reproduced their experiments or measured an improvement from my changes.

What I want to learn from using it

I want to notice when a suggestion makes me ask a new question, look something up, or try a small experiment. I also want to know whether the bot keeps making the same mistakes after I explain them.

The rejection rate alone would miss the point. A suggestion can be wrong for me and still spark something useful in my own head. I am trying to give the bot more of my opinions so it can supply better starting points for that thinking.

Try a manual run, explain one reaction in detail, and inspect what it remembers next time. That exchange will give you something concrete to improve.