Claude + Sybill: Why the best AI still needs sales context

We use Claude.

Our customers use Claude.

I think it’s one of the most impressive pieces of software being built right now.

So when someone asks me, “Why do I need Sybill if my sales team can just use Claude?” my answer is not that Sybill is better than Claude.

That’s the wrong comparison.

Claude and Sybill solve different problems.

Claude is an incredible reasoning engine.

Sybill gives it an understanding of your revenue organization to reason over.

And as companies start connecting Claude directly to more of their sales stack, I think that distinction is going to matter a lot.

Access to your data is not the same as understanding it

MCP has made it much easier for models like Claude to interact with the software your company already uses.

That is a big deal.

Connect Claude to your CRM, call recordings, Slack and other systems and suddenly you can ask questions that would have required hours of manual work a few years ago.

But there’s an important distinction here.

Claude having access to your revenue data doesn’t mean Claude understands your revenue data.

Say you ask Claude, “Are we on track to hit the quarter?”

It might pull pipeline from your CRM. It might read recent calls. It might search Slack. All of the information it needs could technically be available.

But does it know that nine of those opportunities haven’t had meaningful buyer engagement in three weeks?

Does it know that one of the largest deals lost its economic buyer?

Does it know that a competitor was mentioned on a call but never added to the CRM?

Does it know which CRM fields are current and which ones haven’t been touched in six weeks?

Giving Claude access to more systems doesn’t automatically resolve those contradictions or tell it which signals matter.

It gives Claude more information to reason over.

Someone still has to turn that information into an accurate understanding of your business.

That is the problem we built Sybill to solve.

A transcript isn’t context

This is where I think a lot of AI implementations go wrong.

You connect a model to your call recorder. Now it has transcripts.

You connect it to Salesforce. Now it has CRM data.

You connect it to Slack. Now it has internal conversations.

Great. But you still have a pile of information.

Imagine one customer.

Sarah Chen is listed as the champion in Salesforce. A transcript refers to “Sarah.” Another meeting mentions “our VP sponsor.” An email comes from Sarah’s personal address. An internal Slack thread says, “Sarah thinks legal is going to be a problem.”

Now add eight more stakeholders, three months of conversations, dozens of emails, multiple opportunities and a CRM that gets updated inconsistently.

That’s a normal enterprise deal.

Before an AI can answer a seemingly simple question like “What should we do next?”, it has to understand how all of those pieces fit together.

Who is who?

Which conversations belong to which deal?

What happened before this meeting?

What changed?

What is still unresolved?

Which signals actually matter?

A transcript is one piece of that story.

It isn’t the story.

Claude shouldn’t have to reconstruct your sales org every time you ask a question

This is probably the simplest way I can explain why we built Sybill.

Without a context layer, every question starts with some version of reconstruction.

Who is this person? Which deal does this conversation belong to? Which CRM fields are current? What happened three meetings ago? What information contradicts something we heard more recently?

You can solve more and more of this with prompts, retrieval, integrations and custom logic.

But eventually, you’re not just “connecting Claude to your sales stack” anymore.

You’re building the infrastructure required to understand your sales organization.

That’s what we’ve spent years building at Sybill.

It starts with something pretty unglamorous: entity resolution.

Sybill has to correctly resolve every call, email, meeting and other signal to the right people, accounts and deals. That means dealing with aliases, personal and work emails, duplicate recordings, speaker identification, internal meetings and all the other messiness that exists in real revenue data.

Then Sybill connects that information into a continuously updated context graph across your revenue organization.

So instead of starting with a pile of raw sales data, the AI can start with an understanding of what’s actually happening.

John isn’t just a contact who missed the last two meetings.

He’s the economic buyer who stopped attending after raising an ROI concern that still hasn’t been resolved.

Those are very different inputs to Claude.

Why not just build this yourself?

You can.

And I think a lot of companies are going to try.

Connect Claude to Salesforce. Connect Gong. Connect Slack. Build some retrieval. Write prompts that pull the right records together. Add logic for matching people and accounts.

You can get pretty far.

Then the edge cases start.

Which Mike Johnson is this?

Why did the same call get recorded twice?

Which opportunity should this email attach to?

Should an internal Slack conversation override what the rep entered in the CRM?

What happens when a buyer changes companies?

What information should a rep be allowed to see?

How do you make sure an answer is based on something the customer actually said?

How do you keep all of this updated as another thousand emails and meetings happen?

These sound like small data problems until you have to solve them across an entire revenue organization.

At that point, you are building a lot more than an MCP connection.

You’re building revenue infrastructure.

We’d rather let our customers spend their engineering time on the things that are actually unique to their business.

One sales brain, many ways to use it

There’s another reason we made this architectural choice.

Historically, software companies wanted you to live inside their interface.

I’m not convinced that’s how the next generation of software will work.

If a rep wants to work inside Sybill, great.

If a CRO wants to do their analysis in Claude, also great.

If your company builds an internal AI workflow six months from now, that should be able to benefit from the same context too.

The valuable asset isn’t necessarily the chat box.

It’s the understanding underneath it.

That’s why Sybill connects directly with Claude through MCP. Claude can use Sybill’s deal and pipeline context inside the workflows people are already building there.

You can analyze closed-lost deals. Build a business case. Prepare for a forecast call. Look across a pipeline. Draft highly specific outreach. Or combine what Sybill knows about your deals with completely different information and workflows inside Claude.

You don’t have to choose which product should own every workflow.

Sybill can provide the sales context.

Claude can reason with it.

Models will change. Your sales context shouldn’t disappear with them.

This is the bigger bet we’re making.

AI models are going to keep getting better.

The model you prefer today might not be the model you prefer two years from now. Models will get faster, cheaper and better at reasoning.

I think that’s great.

But there’s another asset being created inside your company that is much harder to replace.

Your understanding of your customers.

Your deal history.

The relationships between buyers.

The objections you hear.

The way your sales process actually works.

The context behind thousands of decisions your team makes every quarter.

That belongs to your company.

I don’t think it should be trapped inside a single model or disappear every time you adopt a new AI tool.

We want Sybill to be the place where that sales context lives, so the best AI available can use it.

What does Claude actually know when you ask it a question?

That’s the question I’d ask before connecting Claude to your sales stack.

Not, “Can Claude access our sales data?”

It probably can.

Ask what Claude actually knows when your CRO types:

“Why is this deal at risk?”

If the answer is that Claude can retrieve the CRM record, search the transcripts and find some emails, you’ve solved access.

You haven’t necessarily solved context.

I want Claude to know that this person is the economic buyer. That they raised an ROI concern three weeks ago. That the champion said they would handle it internally. That the concern still hasn’t been resolved. That the buyer hasn’t attended a meeting since.

Now Claude has something much better to reason over.

That’s why I don’t think the future is Claude or Sybill.

It’s Claude with Sybill.

Claude brings the reasoning.

Sybill brings the sales context.

And together, they’re a lot more useful than either one trying to do both.

‍