LaserData combines context storage, event streaming, and agent-focused queries in one backend. Marcus and I spent six months building infrastructure before realizing it was the project. We had started with a different product, but the backend for connecting an agent to live data did not exist. We built it, then spent three months maintaining it instead of shipping what we planned.
That experience, echoed by engineers we spoke with, led us to build LaserData. We are opening early access today. This post covers the system we built, the architectural tradeoffs behind it, and the workloads it is and is not meant to serve.
The actual problem
AI agents have data-access needs that general-purpose backends were not built to handle. They need on-demand reads at decision time, often under 10ms, because execution waits on the result. They need state changes streamed as they occur rather than polled, since polling adds latency and consumes resources on every agent tick. They run concurrent sessions, sometimes dozens at once, sharing some state while keeping session contexts separate. They also often retrieve semantically similar prior context, a query pattern unlike a primary-key lookup.
The usual answer is a collection of familiar tools: a vector database for semantic retrieval, Redis for fast session state, a message queue for events, and a relational database for structured history. Each handles its own task well. The cost is stitching them together: four APIs, four authentication setups, four failure-mode sets, and four operational burdens in production for one agent's data layer.
We are not saying those tools are wrong. We are saying that four systems for one agent backend create organizational and operational costs teams often miss at first, and those costs increase with the agent system.
What we built
LaserData integrates three capabilities: a context store, a streaming event layer, and a query engine. They all use one API and one session model.
The context store manages working memory and durable session state. It saves structured records written during execution, indexed by session ID and type for selective retrieval at each step. Writes acknowledge quickly. Reads use snapshot isolation, so concurrent sessions do not expose partial state.
The streaming event layer sends state changes to subscribed agents as they occur. Agents subscribe to conditions such as session events, shared-state mutations, and external data triggers, then receive updates over the same connection used for queries. There is no polling or separate subscription client. Because events and queries share a session context, agents can match incoming events to current query results without managing two connections.
The query engine serves structured reads from stored context and shared state. It targets agent decision-loop patterns: session-scoped context ordered by recency, small results returned quickly, and repeated query shapes with changing parameters. Query template recognition avoids reparsing and replanning familiar queries, reducing overhead in tight agent loops.
Our design choices
Several early decisions define LaserData today. I want to make them explicit because they also identify workloads where LaserData may not be the right choice.
We optimized for latency rather than throughput. The query engine targets reads under 10ms at moderate scale, not bulk analytical scans across millions of records. If an agent must run a complex aggregation over its full history to find a trend, LaserData is not the right engine. Send that workload to a data warehouse built for it.
We expose one consistency model, per-key linearizability with snapshot-isolated reads, instead of configurable consistency per operation. Predictable behavior generally serves agent workloads better than per-operation tuning. Teams needing highly granular consistency settings will find this less flexible than systems offering full MVCC tuning controls.
We built the context store, event layer, and query engine as one integrated system, not independent services. The event layer cannot be used without the context store. That tradeoff lets one session model span all three capabilities and removes synchronization work between separate systems. It also means LaserData is not a drop-in replacement for one component of a stitched stack. It replaces the stack or it does not.
Early access details
Early access includes a LaserData API key, Python and TypeScript SDK access, and full documentation with a quickstart and API reference. The free tier allows up to 1 million queries monthly, 5GB of context storage, and 100 concurrent connections. That is enough to run a meaningful production agent and test real load before choosing a paid plan.
We want early-access users building with LaserData, not only reading about it. If something fails or behaves unexpectedly, contact us at [email protected]. We are a small team, and we read everything that comes in.
Our current position
Marcus and I have built data infrastructure for a long time. LaserData addresses a problem we encountered directly: getting the data layer right for agent workloads. Enough other engineers have described the same gap that we believe it is real, not an artifact of our own project history.
LaserData is not complete. The event layer has limited routing logic, which we plan to expand. The query engine does not yet natively store vector embeddings or perform semantic search, though that is on our roadmap for the coming months. Our SDKs support Python and TypeScript, while Go is in progress.
We believe the core architecture is the right foundation for agent backends: one session model with integrated storage, streaming, and query capabilities. Features will expand. Our confidence is highest in the foundation, because we arrived at it after learning where the stitched-together version failed.
Use the link above to get your API key. The quickstart gets your first agent reading and writing context in under five minutes.