For a data engineer building retrieval or analytics pipelines for agents, the practical question is where event history lives. Traditional databases flatten events into rows and precomputed aggregates, discarding the sequence and context an AI agent needs to reason about why something happened — leaving the agent to reconstruct that history from a warehouse or search index at query time.

Keewano has built a new type of database instead of adding a bolt-on capability to an existing one. The bet is to keep the full event sequence intact rather than letting it get discarded at write time. On Tuesday, the company made KeewanoDB generally available, alongside $12 million in seed funding led by Hetz Ventures. It runs as a fully managed service on Google Cloud, with other clouds and self-managed deployment planned for early 2027. An agent connects to KeewanoDB directly and reads the sequence where it already sits. Developers wire that connection through an SDK and the Model Context Protocol. A separate analytics layer sits on top for teams that want it, including a natural language query agent and a second agent, called Signal, that the company says runs anomaly detection and causal inference roughly once an hour.

"Agents and machines are becoming heavy data consumers, and they need different things than before," Mark Kardashov, co-founder and CEO of Keewano, told VentureBeat.

A different way to store events, not a table or a time series

For decades, databases have been able to store events in any number of different approaches including graphs, tables and time-series formats. None of those, however, fit the bill for Keewano co-founder and CTO Pavel Bibergal, who previously ran data infrastructure for cross-platform gaming vendor Plarium.

According to Kardashov, Bibergal's team started building with agents and large language models roughly two years ago. Even with a large budget and a full team of analysts, they could not get simple questions answered in real time. Standard data warehouses could show what had happened. Answering why, at a cost the business could sustain, was not something the existing infrastructure was built to do. Kardashov said that gap is what led Bibergal to leave and build KeewanoDB's first prototype on his own.

That origin shapes how Kardashov frames the product now. He pushes back on calling KeewanoDB a graph database, a document database, or a straightforward time series system, though he acknowledges it shares concepts with all three. Asked directly how it compares to a time series database like InfluxDB, he described it instead as an event series database. 

KeewanoDB does not time-order rows across many tables. Instead it treats each entity, a user, a device, an agent, as a primary key. Every event that happens to that entity attaches to it in sequence, producing what Kardashov called one large table per entity rather than a system built around joins across many.

How it works

Three pieces make up the architecture.

Storage format. According to the company, events are stored as four-byte units on disk, sequenced by entity rather than split across relational tables, with no joins used in queries.

Semantic layer. Kardashov described a layer built during ingestion, using large language models, that attaches additional context to each event as it lands. That context changes as an entity's behavior changes, and each change enters the event stream rather than replacing what came before. If a user goes from active, to inactive, to flagged for fraud, all three labels persist in sequence — an agent sees the current status without losing the earlier ones.

Query path. According to Kardashov, an acceleration engine lets agents run scripts directly inside the database through MCP. That removes a step most agent architectures still require, moving data out to an external process before it can be used.

Where it lands in a crowded database market

There is no shortage of database technologies that work with agentic AI, though in many cases the base of the technology predates the agentic AI era.

In March, Oracle updated its own database around a single transactional engine spanning vector, JSON, graph, relational and spatial data, arguing that keeping agent context synced across separate systems breaks down under production load. Couchbase made a similar case in June, positioning its caching and transaction database roots as a stronger foundation for persistent agent memory than tools built for search or analytics.

For Philip Russom, a distinguished analyst covering data and analytics at IronSpark Analysis, the key differentiator is that machine learning (ML) is native to Keewano.

"You see, most commercially available database management systems today include some kind of functionality for machine learning," Russom told VentureBeat. 

He noted that’s true of both older more established database vendors like Oracle and Microsoft as well as new ones such as Snowflake and Databricks. In his view, the ML functionality is too often retrofitted onto a relational DBMS, meaning that structured data must be transformed to make it suitable for ML operations. Additionally, he noted that retrofitted ML processing is usually run outside the DBMS, which causes data movement that takes time and burns up resources.

"To be honest, I can’t quite pigeonhole KeewanoDB yet," Russom said. "So far, it seems like a mashup of graph, neural net, time series, in-memory, and real-time DBMS types. It’s definitely not JARD [just another relational database] or YAPI [yet another Postgres iteration]."

What this means for enterprises

Getting data that connects properly for agentic AI context is a real challenge VentureBeat's own Pulse Research has documented. In a July 2026 survey of 101 enterprises with more than 100 employees, 68% said that in the past six months their AI agents had produced confident but wrong answers they traced to missing or inconsistent business context rather than to model error. The recurring case, at 37%, outweighed the one-off at 32%.

Whether the right structure is an event-series approach, a time series, or a retrofitted relational database depends on the workload. What a data engineer can check now: how do your agents get event history today? If it's reassembled from a warehouse or search index at query time, or read out of precomputed aggregates that dropped the sequence, that's the gap Keewano is describing.