Innovation is a core value of Red Hat's emerging technologies team. Beyond simply developing brilliant ideas, we work to align them within Red Hat's portfolio—ensuring every concept addresses a genuine need and fits purposefully into our broader ecosystem. To simplify the emerging technologies team's vetting process, we created IdeaBot, the central figure of our automated innovation workflows.
Built on Red Hat OpenShift, IdeaBot acts as a dedicated platform that helps Red Hatters incubate, research, and foster their ideas for open source projects, new technologies, product integration, and more. It also allows users to create and refine a standardized report addressing all critical dimensions of an idea to deliver to leadership for further assessment.
The platform's primary objective is to codify institutional knowledge into an intuitive enablement tool that helps users anticipate key questions and assemble supporting evidence before formally presenting their concepts. To achieve this, the system must autonomously query internal knowledge bases, extract external data, perform analytical synthesis, and derive actionable insights from its findings.
Why UX is at the center of IdeaBot
Artificial intelligence—specifically large language models (LLMs)—offered the natural technical foundation for IdeaBot. Nevertheless, delivering an effective AI solution presents distinct hurdles, including user adoption, over-automating risks, and diminishing human agency, all of which can erode user trust.
We chose to develop IdeaBot as an AI-enabled SaaS platform rather than a suite of specialized LLM skills to encourage adoption beyond engineering teams. Designing it as a complete solution rather than a singular tool or platform supported our user-first approach, maintaining a balance between practical utility and user autonomy. This also embedded our required validation standards into the workflow, providing firm yet unobtrusive guidance that users can override if necessary. Rather than constraining the user's journey, IdeaBot actively opens new pathways and offers fresh perspectives in 4 stages: discovery, research, refinement, and synthesis.
Discovery
As the starting point for every new idea, the discovery stage is a structured, conversational interface. IdeaBot leverages the user's initial input to analyze the surrounding domain and define foundational elements of the concept. This guided dialogue explores essential factors such as the intended audience, the problem the user wants to solve, relevant prior art, and potential existing collaborators.
When the model identifies promising candidates for specific details, it proactively suggests single- or multiple-choice options. Users retain full control throughout this interview phase: they can enter custom text if none of the suggested choices fit or pivot the discussion to explore a different angle entirely. Once this preliminary exploration concludes, users are free to navigate to other perspectives and return to review accumulated insights at any time.
Research dispatch
This section introduces the automated research capabilities within IdeaBot. Users can launch deep research agents into isolated internal and external data domains, ensuring complete contextual separation to prevent corporate data exfiltration. The system searches across Google Workspace, Jira, Git repositories, Red Hat documentation, Red Hat Knowledgebase articles, and public web sources (Figure 2). Collected findings are automatically organized into structured categories, including external and internal prior art, persons of interest, product alignment, and competitive analysis.
Refinement board
This perspective aggregates all gathered findings, providing users with complete freedom to edit, refine, and curate the results. Because full ownership remains with the user, they retain complete authority to remove any irrelevant content generated by the underlying LLMs. Within this workspace, users can evaluate confidence scores for individual insights, assign priorities, inspect original references, and trigger on-demand revalidation to continuously cross-reference updates against primary sources (Figure 3).
Synthesis view
At this stage, we're close to finalizing the "idea package." In this step, all gathered information is compiled and synthesized into a standardized format focused on 5 key deliverables, as shown in Figure 4:
- Executive summary
- Problem statement
- Proposed solution
- Market analysis
- Prior art and state of the art
Every attachment is generated as a structured document rooted in the collected findings. Once produced, users can manually review and edit the output. Additionally, automated validation continuously checks the deliverables against established guidelines, flagging any discrepancies. While these flagged issues don't block submission, they serve to highlight potential gaps and areas for improvement.
Isolation on all levels
Given that IdeaBot handles sensitive internal data, impersonates user credentials across external platforms, and indexes public web content, maintaining a robust security posture is essential. Additionally, LLMs require strict operational boundaries, as their goal-driven processing can inadvertently trigger destructive actions or expose confidential information.
To address these challenges, we established 3 core security principles:
- Session isolation: Every conversation operates inside a dedicated pod featuring an isolated network namespace, guaranteeing complete runtime state separation across users and sessions.
- Credential isolation: Long-lived API keys and refresh tokens remain completely hidden from session pods, which rely solely on short-lived access tokens injected at the proxy layer. LLMs have no access to raw credentials, and tool permissions are strictly limited to the minimal scope necessary for each subagent.
- Stateless compute: System state is persisted in PostgreSQL, enabling session pods to be terminated or redeployed without data loss. To mitigate container cold-start and scheduling delays, a warm pool of pre-provisioned pods is maintained. Inactive sessions are pruned, and returning users are reconnected to a fresh pool instance hydrated from the database.
These principles shape the core system architecture:
- Web UI: The standard presentation layer, routing requests exclusively through the Gateway service to display user- and session-scoped content.
- Gateway service: The central entrance point responsible for session lifecycle orchestration, static config distribution, and proxying real-time data streams.
- Session pod: An ephemeral runtime environment allocated per active session, containing 2 isolated containers:
- Session container: The main interactive workspace where deep research workflows are executed.
- Auth proxy: A lightweight HTTP reverse proxy deployed as a native Kubernetes sidecar. It intercepts incoming and outgoing traffic—including LLM API calls—stripping inbound credentials and retrieving short-lived tokens from the Token service for authorized outbound requests.
- Token service: A centralized credential store that exclusively handles token refresh operations, OAuth routines, and key storage, preventing all other components from touching persistent secrets.
Figure 5 illustrates the system architecture and security isolation boundaries.
By combining container isolation with proxy-managed credentials, this design ensures that compromised agents or malicious actors cannot access external resources beyond their explicit, per-session permissions.
Requirement-driven development as an experimental path to reproducible aSDLC
Because our corporate innovation pipeline depends on automated prototyping and development, we built IdeaBot using an aligned approach. We adopted the Easy Approach to Requirements Syntax (EARS) to underpin our behavior-driven development (BDD) methodology. These requirements fully define the system, establishing a baseline for automated unit and integration tests that allow the entire application to be re-created seamlessly without manual intervention.
The workflow follows 3 straightforward steps, as shown in Figure 6:
- Human review of each requirement or set of requirements, written in EARS syntax using Gherkin feature files.
- Automated generation of the test infrastructure to implement the Gherkin features.
- Feature development to satisfy and pass the generated test suite.
Here is an example of an EARS requirement from our code base:
Rule: If 3 consecutive heartbeat pings fail, then the frontend shall display an inline warning indicating the connection is lost.
Scenario: Warning appears after 3 failures
Given the SessionDetail page is mounted
And heartbeat pings will fail with status 404
When 180 seconds elapse
Then the heartbeat warning is visible
Scenario: Fewer than 3 failures do not show warning
When 120 seconds elapse
Then no heartbeat warning is visibleBy putting this methodology into practice, we established a dependable and consistent AI-driven development pipeline. Because thorough test suites and feature specifications safeguard all existing functionality, the code base remains resilient against induced regressions and technical degradation.
Looking ahead, we aim to build upon this foundation to develop fully autonomous, reproducible agentic SDLC pipelines. By using factory patterns, we intend to streamline automated prototyping—so stay tuned as we continue sharing our progress and insights along the way.
