Jedify raises $24M to give enterprise AI agents the context they’re missing

Jedify has raised a $24 million Series A for one of the more stubborn problems in enterprise AI: agents don’t know how a company actually works.

The New York startup builds what it calls a context graph, a layer that connects to enterprise systems and maps relationships between data, people, permissions, workflows, terminology, and business rules. Norwest led the round, with participation from returning investors S Capital VC and Cerca Partners, new investor Oceans Ventures, and strategic investor Snowflake.

Snowflake’s role matters. It is integrating Jedify’s technology with products including Cortex AI, Semantic Views, and CoWork. That puts Jedify near one of the main places enterprise AI projects already start: the data warehouse.

Jedify has now raised about $33 million in total.

Enterprise agents need company-specific context

Most enterprise AI demos assume a clean operating environment. Data is structured. Names are consistent. Permissions are obvious. Business definitions are shared.

Actual companies are messier.

One team’s “revenue” might mean booked revenue. Another might mean recognized revenue. A sales dashboard might exclude renewals while finance includes them. Customer health might be split across Salesforce, Zendesk, product telemetry, and a Notion page maintained by a customer success lead who left six months ago.

An AI agent dropped into that setup can retrieve documents and query databases, but retrieval alone doesn’t give it judgment. It needs to know which source is authoritative, which fields map to which concepts, which users can see which records, and which workflows are allowed to trigger downstream actions.

That’s the gap Jedify is going after.

The platform connects through APIs to structured systems such as databases, data warehouses, data lakes, SaaS applications, and BI tools. It also ingests unstructured sources including reports, documentation, codebases, Slack channels, internal playbooks, meeting recordings, screenshots, and other operational knowledge that rarely fits neatly into a table.

From there, Jedify builds a graph that agents can use to narrow their attention to the information relevant to a given task.

That narrowing matters. A common failure mode in enterprise AI is broad retrieval with shallow ranking. The agent sees too much, trusts the wrong thing, or burns through tokens searching across half the company. A decent context layer can reduce hallucination risk and inference cost by giving the model a smaller, better-scoped working set.

Where the context graph fits

Jedify CEO Assaf Henkin says the company’s context graph differs from semantic layers, metadata catalogs, and traditional knowledge graphs because it captures relationships across multiple dimensions: data, entities, customers, people, permissions, workflows, and domain assumptions.

The distinction is worth taking seriously, with some caution.

Semantic layers have been around for years. They define metrics, business terms, joins, and data models so users don’t have to reinvent logic in every dashboard or query. Tools like Looker, dbt’s semantic layer, Cube, AtScale, and newer warehouse-native features all sit somewhere in this category.

Metadata catalogs help teams understand lineage, ownership, schema changes, and usage. Knowledge graphs model entities and relationships. This is familiar territory.

Agents raise the bar.

A human analyst can resolve ambiguity by asking around, checking a dashboard owner, or reading a definition page. An autonomous workflow needs machine-readable guidance in real time. If an agent is deciding whether to summarize a customer account, draft a renewal plan, or open a support escalation, it needs context that spans systems and access controls.

A useful context graph for agents has to answer questions like:

• Which customer entity in Snowflake maps to the account in Salesforce?
• Which Slack channel contains the current escalation thread?
• Is this user allowed to see support ticket contents for this region?
• Which metric definition applies to this business unit?
• Which internal playbook should govern the next step?
• Has the relevant data changed since the agent last planned its action?

That’s harder than defining ARR once in a metrics layer.

Henkin’s pitch is that Jedify updates as information flows through connected systems and remains model-agnostic. The second point is important. Enterprises don’t want to hardwire their internal context layer to one model provider while teams are still comparing OpenAI, Anthropic, Google, Mistral, Meta, and private deployments.

If Jedify works as described, it becomes a control plane for context rather than another model wrapper.

Permissions are the hard part

Any tool that gives agents access to enterprise knowledge runs straight into authorization. The obvious nightmare is an agent surfacing CFO projections to an intern or summarizing legal documents for an employee who shouldn’t know they exist.

Jedify says it handles this by inheriting permissions from identity systems, file systems, SaaS apps, and databases. That includes row-, column-, and table-level access rules. Customers can also create extra groups that define what specific agents or workflows can access.

That’s the right direction, but it also creates an operational burden.

Enterprise permissions are messy. They drift. They conflict. They’re often overbroad because teams grant access to get work done and rarely clean it up. If an AI system faithfully inherits bad permissions, it can still leak sensitive information, just with better UX.

Derived access is another problem. An agent might not show a restricted document directly, but it could summarize enough from permitted and semi-permitted sources to reveal something sensitive. Governance tools and observability help. They don’t replace careful policy design.

For engineering teams, the integration work can’t sit only with the AI team. Security, data engineering, platform, legal, and business owners all have to be involved. The context layer becomes part of the company’s access architecture.

That’s infrastructure, with all the maintenance that implies.

Snowflake’s investment cuts both ways

Snowflake joining the round as a strategic investor gives Jedify distribution and credibility. It also raises an obvious question: why wouldn’t Snowflake, Databricks, Microsoft, Google, or AWS build enough of this themselves?

They are already trying.

Snowflake has Cortex AI and Semantic Views. Databricks has Unity Catalog, Mosaic AI, and its own governance story. Microsoft has Fabric, Purview, Copilot Studio, and deep Office graph access. Google and AWS are wiring AI into their data and productivity stacks.

The big platforms have a strong claim over warehouse-resident data. They control the storage, query engine, metadata, governance primitives, and increasingly the model execution environment.

Jedify’s counterargument is fragmentation. Most companies don’t keep all useful knowledge inside one platform. Revenue data may sit in Snowflake, product events in another lakehouse, customer interactions in Salesforce and Zendesk, specs in Confluence, informal decisions in Slack, and code context in GitHub. The institutional memory of a company usually lives between systems.

That’s a fair argument. It’s also why this category is hard to defend. A vendor that sits across systems has broader visibility, but it also depends on brittle integrations, changing APIs, customer-specific schemas, and the politics of enterprise data ownership.

The best outcome for Jedify is becoming the neutral context layer across a company’s stack. The risk is getting squeezed as platforms deepen their own agent infrastructure and customers hesitate to introduce another governance-sensitive component.

Snowflake’s backing suggests at least one major platform sees value in partnering for now.

Kiteworks shows the product shape

Jedify points to compliance company Kiteworks as an early customer. Kiteworks connected Snowflake, Tableau, Notion, and internal playbooks, including documents and screenshots, then built agentic tools for customer-facing workflows.

Henkin described the result as a mix of dashboard and real-time conversational application for sellers and account teams. Before or during a customer conversation, the system can assemble relevant account context and surface specific details as needed.

That use case is practical. Sales and account teams already jump between CRM notes, BI dashboards, support tickets, product usage data, and docs before important calls. If an agent can reliably synthesize the right context without exposing the wrong information, the productivity gain is easy to understand.

It’s also a safer starting point than fully autonomous business operations. A human remains in the loop, the task is bounded, and the value is measurable: prep time, call quality, renewal support, and faster access to account facts.

The harder use cases come later, when agents start taking actions across CRM, support, finance, and operational systems. At that point, context quality affects business execution, not just answer quality.

Token costs make context engineering harder to ignore

Jedify’s timing lines up with another enterprise AI headache: token bills.

A brute-force agent that shoves large chunks of company data into a model context window is expensive and often ineffective. Bigger context windows help, but they don’t solve relevance, permissions, freshness, or source authority. They can also worsen latency and cost.

A context graph can act as a filter before the model call. Instead of asking the model to reason over everything, the system can retrieve a smaller set of authorized, task-specific facts and relationships.

That has three practical benefits:

1. Lower inference cost because prompts and retrieved context are smaller.
2. Better latency because the agent spends less time searching and processing.
3. Better reliability because the model receives cleaner context with fewer conflicting signals.

The graph has its own costs. It has to be built, updated, monitored, and secured. Real-time updates across SaaS apps, warehouses, Slack, BI tools, and document stores can create synchronization headaches. Stale context is dangerous because it looks authoritative while being wrong.

Data engineers will recognize the pattern. Every company wants a unified layer. Every unified layer eventually has to deal with freshness, lineage, schema drift, access control, and ownership.

AI doesn’t remove those problems. It puts them in front of end users.

What technical teams should watch

Jedify is targeting mid-market and large enterprises with mature data stacks and multiple warehouses or databases. The company says it has between 10 and 20 early customers, including The Weather Company, and is seeing interest from data-heavy industries such as gaming, industrials, and consumer packaged goods.

For technical decision-makers, the interesting questions are less about the funding round and more about implementation.

A few stand out:

• How does Jedify represent and update relationships across structured and unstructured sources?
• How does it resolve conflicting definitions from different systems?
• What happens when source permissions change?
• Can customers inspect why an agent retrieved or ignored a given source?
• How much latency does the context layer add to agent workflows?
• How portable is the graph if a company changes model providers or data platforms?
• Does governance apply consistently across retrieval, generation, and downstream actions?

Jedify is operating in a category that enterprises are going to need if agent projects move beyond demos. The hard part is that context is not a clean product surface. It is tangled up with data ownership, permissions, old workflows, and half-documented business logic.

That makes the opportunity real. It also makes the implementation painful.