The Infrastructure Nobody Wants to Build

[[divider]]

‍

What We've Seen Fail

We've watched three waves of companies try to solve this problem. Each one got something wrong.

The Universal Connector Trap. Companies like Merge, Finch, and Workato built universal API connectors. "Connect to any app!" The problem: they normalize to the lowest common denominator. Salesforce's rich data model becomes "contact" with a handful of fields. You lose the nuance.

We avoid this by not trying to be a universal connector. We build for our specific ontology. When we ingest from Salesforce, we map to OUR entity model with OUR relationships. It's opinionated. That's the point.

The "AI Will Figure It Out" Trap. So many AI startups threw everything at embeddings and hoped the model would sort it out. "Just RAG it." They got demos that looked impressive but production systems that hallucinated, missed critical context, and gave inconsistent answers.

We avoid this by not relying on semantic search for critical context. We use structured queries. The AI is for reasoning over context, not for finding context.

The "Build Everything" Trap. Some companies tried to replace Salesforce, Slack, Notion, everything. They built mediocre versions of everything and got adoption from nobody.

We thread the needle: build internal tools for what agents touch, ingest from what humans primarily use externally. We're not building a Salesforce replacement. We're building a context layer that ingests FROM Salesforce.

The Single-Tenant First Trap. Lots of startups built single-tenant, then tried to retrofit multi-tenancy. It's painful. You end up with migrations, security audits, architectural rewrites.

We built multi-tenant from day one. Row-level security, tenant context on every query. It costs nothing extra to do it right from the start.

‍

[[divider]]

‍

The Real Architecture

Here's what actually matters:

Build Internal Tools for What Agents Touch. If an agent is going to send messages, you need to own the messaging system. If an agent is going to update tasks, you need to own the task system. If an agent is going to write documents, you need to own the document system.

This isn't about replacing Slack or Notion for humans. It's about having systems where you control the data model, where every action is captured with full context, where the AI can reason about what happened.

Team Comms, Docs, Tasks, Missions, Content, Approvals. We build these internally. Not because they're better products than Slack or Notion. Because we capture 100% of the context when an agent uses them.

Ingest From Systems You Can't Replace. Gmail. Outlook. Google Calendar. LinkedIn. These are systems humans will never leave. You have to meet them where they are.

But you don't just store the email text. You parse it: sender, recipients, subject, body, attachments, thread. You do entity resolution: map email addresses to Person entities. You create relationships: SENT_BY, SENT_TO, PART_OF_THREAD. You extract context with Claude: intent, action items, topics, sentiment.

The email becomes structured data the moment it enters your system.

Per-Tenant Integrations Are Not Core Dependencies. When a customer uses Salesforce, we ingest from their Salesforce. When they use HubSpot, we ingest from their HubSpot. But these are tenant-specific integrations, not platform requirements.

Customer doesn't use Salesforce? We don't call Salesforce. The platform works either way.

‍

[[divider]]

‍

The Honest Risks

This architecture is solid. But there are real risks.

Graph Sync Complexity. We're running PostgreSQL as the primary database and Neo4j for graph queries. That's two sources of truth that need to stay in sync. This is a real operational burden.

The mitigation is event sourcing. Every change goes through an event log. PostgreSQL is updated, then an event fires, then Neo4j is updated. If Neo4j falls behind, you can replay events.

For V1, we're actually considering PostgreSQL-only with recursive CTEs for graph queries. Less powerful, but much simpler operations.

Entity Resolution is Hard. When data comes in from external sources, figuring out "is this the same John Smith we already have?" is a genuinely hard problem. We can match on email, match on domain, use fuzzy matching, even use Claude to disambiguate. But we'll get it wrong sometimes.

Wrong entity resolution means polluted context. If we think two Johns are the same person when they're not, agents get confused. If we think one John is two different people, we lose context.

We do deterministic matching first (email, domain) and only fall back to fuzzy matching with high thresholds.

Context Budget Management. Even with structured context, we still have token limits. Claude Opus has 200K context, but if an entity has thousands of facts attached, we can't include them all.

The architecture handles this with weighted context assembly. Prioritize primary entities, then constraints, then history, then related entities. But the prioritization logic matters a lot and we'll need to tune it based on what actually helps agents make good decisions.

‍

[[divider]]

‍

Why This Matters

The companies that win the AI agent race won't be the ones with the best models. The models are commoditizing.

The winners will be the ones with the best context infrastructure. The ones where agents actually understand the business they're operating in. The ones where agent #10,000 deploys with the same context quality as agent #1.

That's what we're building. Not a better chatbot. Not a better RAG system. The infrastructure that makes AI agents actually work at enterprise scale.

Most companies don't want to build this. It's not glamorous. It's not a demo that wows investors.

But it's the thing that actually matters.

‍

[[divider]]