Deepbridge

Goal of the Project

The project was initiated as part of an accelerator program, where I aimed to explore opportunities to start a company. My primary interest was in leveraging AI agents to assist solution engineers, a need I had observed during my time at Confluent, where the tooling available to solution engineers was notably lacking.

After conducting initial research, I identified RFPs (Requests for Proposals) as a compelling starting point. RFPs not only represent a critical and time-intensive part of the sales engineering workflow but also provide a structured entry point for creating a centralized knowledge base. This knowledge base would form the foundation for developing agentic workflows to address broader solution engineering challenges, enabling smarter, more efficient, and contextually aware automation.

Research

Primary Research: Discovering the Problem

To deeply understand the challenges faced by Solution Engineers (SEs), I conducted primary research by interviewing dozens of SEs and SE leaders from companies such as SAP, Bloomberg, Databricks, and various startups. These conversations provided a broad perspective on their workflows and the pain points they encounter.

One particularly insightful experience was shadowing a solution engineer from SAP for an entire day. This firsthand observation revealed that while SEs are crucial in meetings and high-value client interactions, they spend a disproportionate amount of their time on repetitive, asynchronous tasks. Among these, the RFP (Request for Proposal) workflow stood out as especially time-consuming and inefficient.

When I inquired about existing tools to support RFP workflows, the SE demonstrated Loopio but quickly dismissed it as ineffective due to poor accuracy and a cumbersome workflow. He also emphasized that answering RFPs required unwritten knowledge and expertise that only experienced SEs possessed, making it difficult to delegate this work effectively.

This realization led to the idea of starting with RFPs as the initial focus. By addressing this workflow, I envisioned building a knowledge base that could later power other agentic workflows, creating smarter and more scalable solutions for solution engineers.

Understanding the Gap: Why Tooling for SEs is Missing

In our extensive conversations with solution engineers and their leaders, it became evident why the tooling landscape for SEs is so underdeveloped. The reasons boiled down to two primary factors:

1. Complexity of the Problems: Many tasks in the SE space are highly complex, requiring deep domain expertise and contextual understanding. Traditional tools often fall short in handling this complexity, leading to suboptimal solutions. However, advancements in AI presented a unique opportunity to bridge this gap by automating these nuanced workflows with higher accuracy and adaptability.

2. Resistance to New Tools: A recurring theme in our discussions was that sales teams, including SEs, generally dislike adopting new tools. Instead, they gravitate toward solutions that integrate seamlessly into their existing workflows. They prefer tools that are "invisible"—working natively within familiar environments like email, Excel, and other commonly used platforms. The resistance to learning or adapting to standalone tools was a significant barrier to adoption.

These insights reinforced our approach to start with RFPs, a process already central to the SE workflow, and to design solutions that felt native to their daily routines. By embedding AI into familiar interfaces, we aimed to create tools that were not only powerful but also intuitive and easy to adopt, addressing both the complexity of their work and their preference for seamless workflows.

Competitive Research

In evaluating the competitive landscape, two distinct categories of products emerged: established enterprise solutions and AI-native startups. Each presented significant limitations and opportunities for improvement.

Enterprise Solutions

Established products like RFPIO and Loopio represented the traditional approach to RFP workflows. However, these tools struggled with:

• Poor RAG (Retrieval-Augmented Generation): Their ability to retrieve and use relevant knowledge effectively was limited, making them less reliable for complex RFPs.

• Cumbersome Workflows: The user experience was often described as clunky and outdated, requiring significant manual effort to navigate through processes.

AI-Native Startups

AI-native solutions such as Arphie, AutoRFP, and Quilt showed promise but also had notable drawbacks:

• Immature Solutions: These startups were mostly at an early stage, still iterating on their product-market fit. For example, Quilt had not yet released its product and lacked a clear value proposition.

• High Costs: Many charged exorbitant fees, making them less accessible. AutoRFP, for instance, priced its service at $350 per RFP, a cost that SEs and companies considered excessive.

• Outdated Workflow Design: Despite being AI-driven, their interfaces and workflows felt reminiscent of legacy SaaS tools. None seemed to grasp the critical importance of designing tools that seamlessly integrate into native workflows like email and Excel.

UX Design

Through research, we uncovered critical insights into the existing RFP workflows of solution engineers:

1. RFPs Are Email-Centric: RFPs typically arrive via email and are also responded to through email, making it a central channel in the SE workflow.

2. Excel as a Standard Format: While the data format of RFPs can vary, Excel was identified as the most commonly used format, making it a priority for our solution.

Leveraging these findings, we designed a native workflow that integrates seamlessly with the tools SEs already use:

• Email-Based Workflow: SEs could forward RFPs via email to a designated inbox, eliminating the need to navigate through a separate interface.

• Automated Response and Scoring: The system would respond with completed RFPs and cosine similarity scores, providing SEs with a measure of answer accuracy and relevance.

• RAG-Based Architecture: Responses were generated based on the documents users uploaded during a simple onboarding process, leveraging a Retrieval-Augmented Generation (RAG) architecture to ensure reliability.

This approach prioritized simplicity and familiarity, making adoption easier for users.

Technical Architecture

The system is designed with a streamlined and efficient architecture to support seamless email-based workflows:

1. Email Polling: We used the IMAP protocol to poll emails from the designated agent email inbox.

2. Processing Pipeline: We implemented a classic RAG (Retrieval-Augmented Generation) architecture for accurate and contextually relevant responses.

3. Vector Database: Leverages pgvector for storing and querying embeddings, with OpenAI embeddings and O1 as the underlying model. This was done only for the MVP and we would have switched to a more robust solution if we had proceeded.

4. Deployment: We choseRailway for deployment as this was simple and it was only used by a few people. Our plans were to switch to a managed Kubenetes solution once we got a bit more mature. 

5. Document Management: We supported adding new documents dynamically through API calls or by placing them in a designated folder, allowing for continuous updates to the knowledge base. Our plans were to add integrations to places like Google Drive to make the onboarding more seemless.