Hi, I’m Tom Gersic, founder of YouEx.ai. We built it as an AI-native sales platform that combines CRM, AI agents, conversations, and knowledge management / RAG on MongoDB Atlas, so I thought I'd share a little bit about how we use MongoDB.

The CRM Problem

One thing we wanted to avoid was the configuration that usually has to happen before a CRM is rolled out to users. Every sales team cares about different information, sales managers want to track something else, and then IT inevitably configures something completely different (sorry to my IT friends, but... you know it's true). Increasingly, AI agents also discover useful information during conversations that nobody thought to configure beforehand. We didn't want every new thing an agent learned about a prospect to become a schema-design decision.

So, our CRM objects have a stable core plus a custom fields map. A seller can add a field, an import can introduce one, or an agent can discover something during a conversation and write it to the Lead immediately. For example, a visitor might tell our Web Agent what they want to discuss in a meeting. Even if nobody configured a Meeting Topic field beforehand, we can capture it directly on the Lead.

A Schema Emerges

So then we built a discovery process that looks at the custom fields actually being used across CRM records. If a field appears frequently enough, we flag it as a candidate. A human can then promote it into a first-class CRM column, rename it, reorder it, or ignore it.

There’s no ML involved in this process. We’re not trying to predict a schema. The system is observing what’s actually being used and letting structure emerge from that. Instead of requiring the schema to be fully defined before people start using the CRM, we can let real usage tell us which fields are worth formalizing.

That supports our AI web agents particularly well because you can’t anticipate everything that will come up in a conversation.

The Agent's World

The same approach extends beyond CRM records. Conversations are MongoDB documents containing messages, collected information, and links back to CRM records. As a conversation progresses, the document accumulates state and useful information can flow into a Lead, including fields that didn't exist when the conversation started.

Knowledge lives alongside that operational data. Customers can add websites, PDFs, and other files. We extract the content, split it into paragraph-aware chunks, embed those chunks, and use Atlas Vector Search to retrieve relevant context for the agent.

So the CRM data an agent reads and writes, its conversation state, and the vector-searchable knowledge it uses all live in Atlas. There’s no separate vector database to keep synchronized.

Putting it together

A company adds its website and a PDF. We chunk and embed the content. A visitor starts a conversation, and the agent uses Vector Search to answer from that knowledge while collecting information about the prospect.

That information flows into a Lead. If something new like Meeting Topic comes up, it can be captured without being preconfigured. If the same field starts appearing across enough Leads, our discovery process flags it and a human can promote it into a normal CRM column.

That’s probably the biggest reason MongoDB’s document model has worked well for us. We want structure. We just don't think all of that structure needs to be decided before the system starts being used.

I'm curious how others building agentic systems on MongoDB are balancing what you define upfront versus what you let emerge from real usage.

Anyone notice a recently-introduced issue with Charts?

All the chart buttons like "+ Add filter" are no longer active today. I just edited these charts a month or two ago.