DEV Community: Ramanpreet Singh

The CRM is a product of the past

Ramanpreet Singh — Wed, 21 Oct 2026 09:43:10 +0000

Every company still pays its best sellers to maintain a database that should maintain itself. The agentic CRM flips that. The AI SDR is the version that pays rent first.

The CRM was a great product for 2005. A shared database of records, forms to fill, and a pipeline report your manager reads on Monday morning. It solved a real problem of its era: sales knowledge living in one rep's head and leaving with him.

Two decades later, the people meant to maintain it have better things to do, so they don't. Updates arrive late, sanitized, or never. Meanwhile the relationships the records describe keep moving: people change jobs, companies reorganize, signals appear and expire. The database falls behind the market every single day, and everyone quietly agrees to pretend the pipeline view is reality.

The CRM didn't fail because it was badly built. It failed because it asked humans to do the machine's job.

The agentic CRM, defined

The fix is not a nicer form or another dashboard. It is inversion. Put an agent layer on top of the system of record and let the layer do the work the records used to demand: research accounts, watch public signals, remember every conversation, draft the follow-up. The CRM keeps the job it was always good at, being the ledger. The agent becomes the employee.

This is a build, not a purchase. Vendors are already shipping an agentic CRM checkbox, but a rented agent working someone else's model over your data with their guardrails is a lease with a clause you have not read. The teams that win will run the agent layer on their own data, with their own governance, and they will start now.

Why sales development goes first

If you are building the layer, give it the job where leverage shows up fastest: sales development. SDR work is mostly reading, remembering, and drafting, which is exactly what the layer is good at. An AI SDR is an agentic CRM that started paying rent. It earns the right to touch the rest of the funnel.

One thing kills these projects before they start: giving the agent the last mile. An AI that can message your customers can embarrass you at scale, and the category's bad reputation is entirely made of that mistake. The design rule I recommend to every GTM leader: the AI watches and recommends, the human sends. Autonomy is granted in budgeted increments, never assumed.

The governance stack, briefly

My own implementation runs daily, and every layer in it exists because a board would ask for it. Write the agent a constitution and pin it with a hash so tampering is detectable. Cap actions, messages, and spend in code, and fail closed when the budget runs out. Let the agent propose standing rules, have a judge model score them, disclose them, and keep them revocable by one line. Tripwire the drift with a scheduled self-audit. Keep one emergency stop that outranks everything, and log receipts for every action with its reasoning and cost.

In build order: constitution first, proposals-only second, budgets third, ratified learning fourth, drift tripwire fifth, emergency stop sixth. The full six-layer pattern, with the production details, is in the Alfred case study.

What it changed in the field

Running this daily rewired how I think about pipeline, and the lessons are not what the category's marketing says.

The bottleneck is decisions, not volume. A morning brief turned outreach into a ten-minute decision session. The multiplier is the speed of the human decision.
Personalization at depth beats personalization at surface. First-line flattery is dead; relationship context, the right moment, and the right ask still land.
Timing is the personalization nobody can fake. Knowing who moved and what changed beats any sequence cadence ever written.
Small budgets force intelligence. When the system cannot spray, it must choose. The cap improved quality more than any prompt did.

If you are building one

Start smaller than you think and stricter than feels necessary. One job, one constitution, one budget, one human approver. The agent earns scope the way an employee does, on probation, with receipts. The companies that get this right will not have bought an agentic CRM. They will have built the layer their data always needed, and their competitors will be reading about it.

Originally published at builder-singh.com

GraphRAG vs. Vector RAG: The Economics of Enterprise Multi-Hop Reasoning

Ramanpreet Singh — Wed, 21 Oct 2026 09:41:44 +0000

Pure vector search is cheap at index time but fails when business logic spans hundreds of interlinked filings. Knowledge Graph RAG costs multiples more upfront in extraction tokens, but pays for itself when single-chunk retrieval failures carry multi-million dollar compliance or investment risks. Here is the architectural decision matrix for budget holders.

The standard vector database stack (chunks, embeddings, cosine similarity) works for isolated document lookups like vacation policy details or contract clauses. However, nearest-neighbor vector similarity measures vocabulary and semantic proximity, not relational truth. When analyzing complex portfolio risk, 500-token chunking severs entity relationships and cross-document guarantees across document boundaries.

Vector search retrieves fragments that look relevant while remaining blind to hidden relational dependencies like cross-default clauses, debt covenants, and executive overlap in footnotes. Two chunks can share key relationships while sharing no vocabulary, causing vector engines to drop critical facts below the threshold.

Vector search finds similar text chunks. Knowledge Graph RAG structures entities and relationships so agents can reason across the entire corpus with verifiable provenance.

Why top-k similarity breaks at enterprise scale

When you chunk a 100-page document into 500-token blocks, you sever entity relationships across boundaries. If company ownership, supplier dependencies, or revenue commitments span multiple sections or separate filings, those facts get scattered into isolated vectors.

When a query arrives, top-k retrieval pulls the nearest vector neighbors in embedding space. But semantic similarity is not relational logic. Two chunks might share identical language about supply chain risk while referring to completely different entities, years, or business units. The result is a context window filled with surface-level matches that lack the connective tissue required for genuine synthesis.

How GraphRAG turns disconnected text into structured intelligence

Knowledge Graph RAG fixes this failure mode by replacing raw text proximity with explicit entity-relationship structures and hierarchical community summaries:

Entity and relationship extraction: Mines structured nodes and edges (companies, executives, products, metrics) from unstructured text.
Hierarchical community detection: Graph algorithms cluster tightly connected nodes into macro-summaries at local, regional, and global levels.
Dual retrieval paths: Runs local retrieval via specific graph edges for precise node queries, and global retrieval via community summaries for macro aggregation.
Verifiable provenance: Traces every node, relationship, and community summary back to exact relational paths in source filings.

Lessons from the lab: FundHouse and Alfred

The lab's FundHouse engine makes the failure concrete. It runs an evidence pipeline over 250 Nifty-listed companies, and the hardest class of question is exactly the one vector chunking handles worst: a covenant or restriction sitting dozens of pages from the main credit agreement it modifies. An evidence-grounded architecture that preserves entity relationships and lineage across multi-page filings is what turns those audit checks into verifiable, source-linked verification runs. That is the same property GraphRAG formalizes with explicit entity-relationship structure, and it is the reason graph-style retrieval belongs in regulated document workloads.

A similar pattern runs in Alfred, the governed SDR agent layer I run, with a constitution, budgets in code, and a human veto on every send. Instead of treating news feeds and market notes as isolated text streams, Alfred maps executive changes, institutional holdings, and strategic partnerships directly onto an entity model. When an account signal triggers, the agent walks the graph to determine which ongoing engagements and historical conversations are impacted, producing grounded morning briefs with clear evidence trails.

Vector search finds similar text. GraphRAG walks proven edges. Same query, different question.

When to use GraphRAG vs vector RAG: the unit economics

Indexing cost: GraphRAG's initial extraction pass costs multiples of a standard embedding index, in both tokens and time.
Refresh cost, the budget killer: filings re-arrive quarterly and news arrives daily, so graph extraction is recurring OPEX, not a one-time capex line. Budget the refresh before the pilot.
Query efficiency: Global community summaries reduce context-window stuffing and substantially cut per-query synthesis costs.
Executive rule of thumb: Use Vector RAG for isolated document Q&A where accuracy errors carry low cost. Upgrade to GraphRAG or Hybrid models when query logic requires multi-document synthesis spanning 3 or more hops, or when a false negative carries significant operational or regulatory risk.

GraphRAG vs vector RAG: a decision framework

Before picking your retrieval architecture, evaluate your workload across query complexity, ingestion cost, context efficiency, and risk tolerance:

Query complexity: Vector RAG handles single-doc lookups; GraphRAG handles multi-hop reasoning across corpus boundaries.
Ingestion cost: Vector RAG is the cheap baseline; GraphRAG's pre-computation pass costs multiples of that in extraction tokens.
Context efficiency: Vector RAG context is low (raw chunks); GraphRAG is high (compact community summaries).
Risk tolerance: Vector RAG suits high error tolerance; GraphRAG suits zero-hallucination compliance and financial audit trails.

In practice, the most robust enterprise architectures use a hybrid approach: vector indexes for rapid semantic entry points, and knowledge graphs for structured traversal and global reasoning.

Originally published at builder-singh.com

Your AI agents don't need more integrations. They need an ontology.

Ramanpreet Singh — Wed, 21 Oct 2026 09:41:33 +0000

Every new tool adds another silo, and your agents inherit the mess. The missing piece is older and cheaper than any integration: a shared vocabulary the machine can compute.

In March, a stakeholder I'd worked with for two quarters changed companies. For eleven days, two of my systems disagreed about where he worked. My CRM said the old employer. My agent layer said the new one. The outreach draft my agent prepared that morning congratulated him on a move he had announced himself, then referenced a role he had already left. Nothing crashed. Nothing alerted. The system simply answered wrongly, confidently, in my name. Multiply that by every tool in your company and you have the quiet failure of enterprise AI: it isn't hallucination, it's disagreement between systems that were never taught the same vocabulary.

The pilot works, the agents are impressive, then someone asks a question that crosses two systems and the whole thing shrugs. Which company does this contact belong to after the acquisition? Who can approve a partnership at an account where the decision-maker moved last quarter? The stack shrugs, because a pile of integrations isn't a world model.

Tools give an agent hands. An ontology gives it a world model.

The vocabulary and the map

The distinction is older than the hype: Tom Gruber defined it in 1993, in the field's canonical reference. An ontology is an explicit specification of a conceptualization: the vocabulary, what things are, what evidence counts. The knowledge graph is the map you draw with it: the actual nodes and edges, this person, this company, this history. One is the rules, the other is the territory. The lineage runs back to the Semantic Web vision of 2001; the reasoning engines only arrived now, and the meaning layer is still what most teams are missing. In practice the vocabulary lives as a property graph (the Neo4j family) or RDF triples; the choice matters far less than having one at all.

Without them, every integration is a new dialect: your email tool says contacts, your CRM says leads, and your agent can't tell that three of those are the same human being. If you have a master data management team, slow down before calling any of this new. MDM has fought identity resolution across silos for two decades and your MDM people already own half the answer. What agents change is the exposure: the vocabulary used to sit in governance wikis nobody read at query time, and now a machine reasons over it live, every morning, and every answer walks your ontology in public.

What it looks like when it works

I run a small version of this for real. My agent layer maintains a living map of my professional market, and the core structure is one line: Person works_at Account, with a start date and a source on the edge. The production graph behind my systems carries 46 knowledge cards, 154 nodes, and 170 edges today. Small numbers, on purpose: every node earned its place through a source I could check. When someone changes jobs, that isn't a stale CRM row. It's one node changing state, and every recommendation that touches him updates with it.

The rules draw the map, and a query walks verified edges with its sources attached.

The demonstration is one query: 'who at Helios Retail can approve a data partnership?' The answer names the node it walked (Ananya Verma), the edge that proved employment (works_at Helios Retail, since March 2024), and the source that landed it (her announcement). Without the structure, the same question gets a confident paragraph with a footnoted feeling and no footnotes.

The field saw this coming. The practice didn't.

Gartner predicted back in 2021 that graph technologies would sit under 80 percent of data and analytics innovations by 2025, up from 10 percent in 2021, and analysts at MarketsandMarkets size the knowledge graph market at roughly 1.9 billion dollars in 2026, growing toward 9.88 billion by 2032. The honest read: adoption lagged the prediction, because most teams waiting for a platform to make graphs easy are still waiting. The ones that actually run them started smaller, with schemas they already had. Microsoft reached the same conclusion from the retrieval side: its GraphRAG research (arXiv:2404.16130) showed agents reason dramatically better over documents when a graph organizes the corpus first. And the strongest commercial proof has a name: Palantir sells its Foundry Ontology as the centerpiece of enterprise AI.

The objection worth engaging: just buy it

Because the ontology your agents reason over is your competitive memory. Palantir's version models your business inside their platform, on their terms, at their price. Owning the vocabulary, on infrastructure you already run, keeps your memory yours; the pattern is proven at the highest stakes, and the discipline to build the small version is what a mid-size team should take from it. The second objection comes from inside the building: we already resolve identities, the MDM team has run matching for years. True, and vector search plus entity matching still answers retrieval questions, not reasoning questions. An ontology doesn't replace your MDM. It gives your agents the map your MDM never built.

When you should NOT build one

A decision rule, because advocacy without an exit is selling. Don't build if you have one system of record and no cross-silo questions: a well-kept database already is your world model. Don't build if no agent will reason over the vocabulary; a graph nobody queries fails expensively. And don't build until you can name the questions that crossed systems and went unanswered: the ontology exists to answer those.

How to start, small and honest

Write down the 20 nouns your business actually runs on. Roles, accounts, commitments, signals.
Define 5 relations between them and what evidence creates or changes each: a job change needs a source.
Build the graph for one workflow only, agents maintain it under rules, corrections logged.
Require every answer to name its nodes. No citation, no answer.
Expand when the first workflow feels boring. Boring is the sound of a world model working.

Now the part the demos skip: the graph itself can rot. Somebody owns the vocabulary, or in eighteen months you have three words for customer and a fight. Evidence conflicts sometimes, so precedence gets written down before the first conflict arrives. Growth needs a stop condition: a graph that absorbs every noun anyone mentions is a junk drawer with a schema. Healthy graphs are run like products, with an owner, a changelog, and a reason to say no.

Grounding is the enterprise word for it. NIST's AI Risk Management Framework asks for exactly this under explainability and traceability. What fewer people say out loud: grounding is not a prompt trick. You can't ask a model to show its work across a sprawl of silos. The structure has to exist first. The model can only walk a path someone built.

Originally published at builder-singh.com

I built a tiny CI tool to keep AI agent configs from drifting in my repo

Ramanpreet Singh — Tue, 05 May 2026 20:11:46 +0000

If your team uses AI coding agents on real code, you've probably hit this:

The rules your agents are supposed to follow — what tools they're allowed to use, who can call who, when something should escalate — live in scattered prompts, READMEs, and Notion docs. Nothing in your CI pipeline fails when reality drifts from those documents.

So I made a small thing.

What it does

It turns the rules into YAML that lives in your repo:

# .agent-ops/registry/tool-acl.yaml
backend-builder:
  tools:
    - repo_read
    - repo_write_backend
    - run_backend_tests

security-reviewer:
  tools:
    - repo_read
    - dependency_scan

blocked_tools:
  - direct_email_send
  - production_delete

A Python validator fails CI when:

An agent declares a tool the ACL doesn't grant
An agent calls another agent not in the call graph
A sensitive action (email send, deploy, external post) is missing required evidence fields

There's also a ~100-line Python module you can import into your own agent runner to enforce the same rules at runtime, before tools execute:

from agent_ops_guard import AgentOpsGuard

guard = AgentOpsGuard(".")
guard.assert_tool_allowed("backend-builder", "repo_read")
guard.assert_call_allowed("orchestrator", "backend-builder")

If a check fails it raises PolicyDenied and your runner blocks the action before it happens.

Try it in 5 minutes

git clone https://github.com/RPSingh1990/agent-contract-tests
cd agent-contract-tests
python3 scripts/agent_ops_validate.py --strict

That runs the validator against the included example. Pure Python, no dependencies.

To drop the starter files into your own repo:

python3 scripts/agent_ops_init.py --target /path/to/your-repo

What this isn't

Being honest about scope:

Not an agent framework — AutoGen, CrewAI, and LangGraph already do orchestration
Not a sandbox — these are repo-level contracts, not process isolation
Not an LLM eval suite — Promptfoo, DeepEval, and Inspect already do that

It's a small contract-test layer, narrow on purpose.

What I'm looking for

Single author, MIT, days old. The questions I actually have:

Does the YAML shape match how teams structure agent rules in practice, or is the abstraction wrong?
Are any of the checks process-for-process's-sake?
What drift have you seen that this wouldn't catch?

Repo: https://github.com/RPSingh1990/agent-contract-tests

Issues and PRs welcome. So is "this is wrong because..."