The most dangerous number in an AI system may be the one everyone recognizes and nobody has defined. Revenue. Churn. Active user. Each sounds solid enough to survive a board meeting. Inside a data warehouse, each can split into a thicket of refunds, time zones, exceptions, legacy columns and local customs. Give that thicket to a fast agent and it will move quickly. Whether it moves in the right direction is another matter.
Ido Bronstein has built his young company around this awkward fact. Upriver, which he co-founded with Omri Lifshitz in 2024, connects across the enterprise data stack so AI agents can inspect pipelines, schemas, orchestration, lineage, code and documentation together. When a pipeline fails or a metric drifts, the aim is to reconstruct the change, identify the cause and propose a repair that a human can review. It is less like asking a chatbot for SQL and more like giving an investigator the keys to every relevant room.
Bronstein’s phrase for the missing ingredient is context. Not the handful of files pasted into a prompt, but the living map of how an organization turns raw signals into decisions. The map includes technical dependencies, certainly. It also includes the peculiar meanings a business has negotiated over time. A customer can be an account, a household, a contract or an email address. The database will accept all four without complaint. The company cannot.
A problem with an old address
This obsession did not begin in a SaaS brainstorm. Bronstein and Lifshitz met in Talpiot, the Israeli military program that combines advanced academic training with technical service. Bronstein later spent six years in Unit 8200, working in cyber operations management and data-platform development. He built software that turned raw information from multiple sources into intelligence people could use, then managed engineers scaling that infrastructure.
The corporate version is quieter, but structurally familiar. A large business gathers information through many products, moves it through transformation and orchestration tools, stores it in warehouses, and displays it in dashboards. Every layer creates another chance for meaning to blur. When something breaks, an engineer becomes the institution’s reluctant detective, moving between alert screens, query histories, code commits and the memories of whoever happens to be online.
Bronstein and Lifshitz had spent years building internal tools around such fragmentation. Their official account of Upriver’s origin is almost anti-mythological: data teams were burning time on investigations and repairs because no single tool understood enough of the environment to do the work. So they began packaging the environment for AI.
The machine needs a map
Application code is unusually hospitable to agents. The files are present. Dependencies can be traced. Builds fail loudly. Tests offer a crisp answer. Data systems are more theatrical. The code may be correct while the output is wrong. A metric can pass every type check and still violate the agreement finance made last Tuesday. The business definition lives somewhere else, perhaps in a dashboard label, a ticket, a document or one person’s head.
This is why Bronstein treats validation as infrastructure rather than etiquette. In his writing, tests, schema contracts and reconciliation checks form the signal an agent uses to correct itself. Where those checks are dense, the system can iterate toward a defensible result. Where they are sparse, the agent can only converge on plausibility. A more capable model does not remove the need for verification. It can produce a persuasive mistake sooner.
That framing produces a useful, mildly uncomfortable metric: test coverage is now a map of what a company can safely delegate. The well-specified parts of the data estate are candidates for automation. The ambiguous parts still require judgment. The limiting factor is not how eagerly a team buys AI. It is how precisely the team has expressed what correct means.
Upriver’s architecture follows the same logic. Rather than replacing Snowflake, Databricks, Airflow, dbt or the rest of the modern stack, it works across them. Its context engine maps the environment; agents investigate failures and perform data tasks; validation keeps the output reviewable. Early named customers include Unity, DMGT and Nimble. The company has also developed relationships with Databricks and Snowflake, the very platforms a narrower product might have treated as territory to seize.
From tables to meaning
There is a larger professional argument hiding beneath the product. Bronstein believes the data engineer is returning to an older identity: the knowledge engineer. Over years of expanding infrastructure, data work became dominated by ingestion, storage, transformations, pipelines and tools. The original purpose - representing how an organization understands itself - receded behind the machinery.
Agents change the allocation. If software can trace failures, write transformations and maintain routine workflows, the human moves up a level. Someone still has to settle whether the European refund policy belongs inside the revenue metric. Someone has to notice that sales and product use the word customer differently. Someone has to capture that agreement before it evaporates into another meeting.
This role is technical, but not exclusively so. It rewards diplomacy, editorial judgment and a tolerance for definitions that arrive carrying political baggage. Databases dislike ambiguity. Organizations manufacture it daily. The knowledge engineer stands between them, converting argument into a rule a machine can use.
Bronstein reached that line during a Data Splash conversation with Abe Gong, co-founder of the data-quality project Great Expectations. Midway through, Gong turned the interview around and began questioning his host. The exchange became less promotional Q&A than two practitioners sketching the same landscape. They landed on the idea that shared knowledge is cultural infrastructure: the definitions an organization agrees to preserve reveal how it collaborates and what it values.
The anecdote suits Bronstein’s public mode. Alongside running Upriver, he writes frequently about the industry and hosts conversations with data leaders. His essays range from source-level quality and real-time data to semantic layers and benchmarks for AI agents. There is a recurring move in them: begin with a familiar technical complaint, then locate the organizational decision hiding inside it.
The founder’s constraint
Bronstein’s research background adds an intriguing rhyme. His published academic work examined the inductive bias of neural networks learning a class of Boolean functions. Inductive bias is, broadly, the set of assumptions that helps a learner generalize beyond the examples it has seen. Upriver addresses a commercial cousin of that question. What structure must surround an agent so it can act correctly inside a specific company?
The answer is not merely more historical data. Bronstein distinguishes between mining context from the past and authoring it in the present. Query logs can reveal how analysts once calculated a metric. Transformation code can expose an existing dependency. Neither can decide whether the company should change its definition tomorrow. The context that matters most is sometimes born at the moment an owner makes a decision.
This is also where the human remains stubbornly useful. An agent can surface seven definitions of daily active user. It cannot grant one definition organizational legitimacy by force of syntax. A person with authority has to choose, explain and maintain it. Automation can make disagreement visible. Governance turns the disagreement into a durable instruction.
An invisible ambition
In June 2026, Upriver announced a $10 million financing led by Valley Capital Partners, with participation from existing investor Hetz Ventures and angels including Lew Cirne, Abe Gong, and Cyera founders Yotam Segev and Tamar Bar-Ilan. Together with an earlier round, the announcement put total funding at $14 million. Bronstein said the capital would go toward two ordinary founder verbs: scale and build.
The aspiration behind them is more unusual. He wants data infrastructure to become invisible. Not absent, and certainly not unimportant, but quiet enough that teams can focus on what the business is trying to learn and decide. In this future, an agent chases the alerts, gathers the context and prepares the repair. The engineer judges the meaning and the consequences.
There is a fine comic justice to it. Companies spent years constructing ever more elaborate machinery to make data usable, then discovered that the machinery had consumed the people meant to use it. Bronstein’s wager is that AI can give those people their attention back. The prize is not a warehouse with no humans. It is a room where the humans finally have time to agree on the number.