Our own Jay Kreps argued thatevery company is becoming software. He was right. Businesses no longer simply use software to help people do their jobs. Software has become the way the business actually runs.
AI is now doing to software what software did to the business. At first, generative AI helped us do our jobs faster and better. It has since moved from drafting and summarizing to writing code and carrying out complex tasks. Now we are telling AI agents what we want done and letting it figure out how, including making decisions that once required a person in the loop. We still set the direction and limits, but the decisions themselves can happen at machine speed.
Making decisions faster does not mean having the data and context necessary to get them right. Much of our enterprise data architecture was built to describe the past, whether minutes, hours, or months ago. Now we are asking that same architecture to help run the present.
Most of us have found ourselves asking AI some version of “Did you check the latest information?” or “Where on earth did you get that?” We can catch mistakes, ask again, or ignore the answer, as we have with reports and dashboards for years. But when AI agents act without someone checking their answers, the consequences change. Outdated data or an inaccurate understanding of the business no longer just produces the wrong answer. It leads to the wrong action.
To make accurate decisions at machine speed, we need to maintain the state of the business as it changes. That state needs to be always current, decentralized across the systems that already run the business, and dependable enough for software to act on it. Applications, agents, and analytical systems should be able to reuse that understanding rather than independently rebuilding it every time they need it. We call the architecture that makes this possible the Streamhouse.
A Streamhouse is a data architecture that continuously captures, processes, governs and serves current business state and context across distributed systems, making them available to applications, AI agents, and analytics.
The Streamhouse has three requirements:
- Always Current. Build from history, then maintain state as changes happen. Keep the ability to replay, correct, and recompute when the underlying facts or business rules change.
Always Current. Build from history, then maintain state as changes happen. Keep the ability to replay, correct, and recompute when the underlying facts or business rules change.
- Decentralized. Operational and analytical systems retain their own responsibilities. They can share and reuse state and its meaning in any shape or format without first consolidating onto one physical platform.
Decentralized. Operational and analytical systems retain their own responsibilities. They can share and reuse state and its meaning in any shape or format without first consolidating onto one physical platform.
- Mission Critical. The information driving production decisions must meet the appropriate requirements for correctness, availability, security, recovery, and traceability.
Mission Critical. The information driving production decisions must meet the appropriate requirements for correctness, availability, security, recovery, and traceability.
In this blog, we will explore each of these requirements in detail. Together, they represent a fundamental shift in what we maintain and share across the business.
Most data pipelines are built to move and transform information for a particular destination, leaving downstream applications, analytical systems, and AI agents to build their own understanding of the business. A Streamhouse changes that model. Instead of treating business state and context as the output of independently built pipelines, it makes the state, its meaning, and the computation behind it reusable across systems. The underlying technologies are familiar, but what the architecture is responsible for is fundamentally different.
A Streamhouse gives a name to an architectural category that was already forming, bringing together several established technologies to meet these requirements. Connectors capture operational changes and historical data. A durable event backbone makes those changes available for processing and replay. Stateful processing continuously maintains useful representations of business state. A shared semantic model connects business definitions and relationships across systems, while governance and lineage provide controls and traceability. Finally, serving systems make the maintained state and context available through streams, queries, APIs, and operational or analytical tables.
The Streamhouse architecture allows organizations to capture, transport, transform, govern, and serve the current state of their business continuously.
A Streamhouse does not prescribe a particular technology stack. Each approach involves different tradeoffs in latency, consistency, replay, cost, and operational complexity. Each capability can be implemented in different ways:
- Capture changes through Kafka Connect or managed data replication services.
Capture changes through Kafka Connect or managed data replication services.
- Transport changes through Apache Kafka or Apache Pulsar.
Transport changes through Apache Kafka or Apache Pulsar.
- Transform data incrementally or in batches using Apache Flink or database materialized views.
Transform data incrementally or in batches using Apache Flink or database materialized views.
- Govern schemas, definitions, and lineage using open-source or proprietary tools.
Govern schemas, definitions, and lineage using open-source or proprietary tools.
- Serve maintained state through PostgreSQL or publish it as open Apache Iceberg tables.
Serve maintained state through PostgreSQL or publish it as open Apache Iceberg tables.
The Streamhouse complements the operational and analytical systems that already run the business. It does so by providing these systems with continuously maintained business state and shared context, allowing each to build a common understanding of the business rather than independently reconstructing it. Operational applications and databases remain responsible for authorizing and committing transactions. Warehouses and lakehouses continue to support historical analysis, exploration, and model training.
Always current
A decision has a deadline.
A Streamhouse maintains and shares business state as the business changes, so software has the data it needs while there is still time to act. Getting data into a stream, lakehouse, or warehouse in seconds is not enough. Fast ingestion does not guarantee fast action. The information must be processed and served, together with its meaning and context, at the speed the decision requires.
A Streamhouse builds business state from history, then captures operational changes as they happen. Stateful processing continuously maintains reusable results as those changes arrive. Those results can be consumed as streams of changes, queried as current state, or materialized as a table. History remains available for corrections, changing business rules, and recomputation when necessary. But updating what changes becomes the default, rather than repeatedly rebuilding everything from scratch.
Freshness alone is not enough. Software needs the business semantics and context to understand what the data means and how to use it. Just as people make decisions with incomplete information, software can provide useful answers that are amended as new information arrives. Other decisions require complete information or confirmation from authoritative systems before software can act. A Streamhouse needs to support both, making the freshness, meaning, and completeness of its state available to the applications using it.
Maintaining business state from change fundamentally changes the economics of data processing.
Much of the data, context, and business logic we need already exists in the operational systems that run our businesses. Yet downstream applications, analytical pipelines, and AI agents repeatedly reconstruct that understanding. We are not just copying data. We are rebuilding its meaning and the computation behind it, paying for both the infrastructure and the people needed to maintain and reconcile those independent implementations. Even worse, each implementation can create its own version of “now.” Definitions and freshness vary across systems, and the same business question can produce conflicting answers.
A Streamhouse does not guarantee a perfectly synchronized global version of “now.” It does substantially reduce those conflicting interpretations by maintaining and sharing reusable business state, context, and computation. Different consumers may still need their own representations, but they should not have to independently rebuild the same understanding. The benefit grows as more applications and recurring decisions reuse that work.
The goal is not simply to process data faster. It is to maintain a shared understanding of the business as it changes, instead of making every consumer build its own version of “now.”
Decentralized
You cannot unify a business by consolidating its systems.
A Streamhouse unifies a distributed business by maintaining reusable business state and context across its existing systems. It does not require businesses to consolidate on one solution platform. Each system can retain its specialized role while still sharing a common understanding of the business.
Operational and analytical systems are different for good reasons. A payment database needs transactions and concurrency. A warehouse needs to analyze years of history without disrupting checkout. Specialization is not a defect to be eliminated.
Consolidation can bring real advantages but enterprises are and will remain distributed. ERP and CRM platforms bring substantial parts of the operational business together, while lakehouses unify analytical workloads around common storage, compute, and governance. Despite this, enterprises still need purpose-built solutions like specialized databases, mainframes, and third-party applications. No single platform can reasonably become the center of the entire business.
A shared platform can unify the workloads it serves. It cannot be a prerequisite for unifying the business.
The challenge goes beyond where the data lives. Much of its meaning is embedded in application logic, relationships, business rules, and exceptions. Modern platforms have become remarkably flexible about ingesting and storing changing data structures, but accommodating those changes is not the same as preserving their meaning. Moving an order record between systems does not automatically bring the rules for when it can be canceled or how its inventory is reserved.
And that meaning is not necessarily identical across the business. Different systems can legitimately represent the same business concepts differently. A Streamhouse connects those representations through shared definitions and continuously maintained state, without forcing every system into one universal model. Operational systems retain authority over their transactions, while consumers reuse the business understanding built across them.
The business remains distributed. Its data, context, and computation no longer need to be independently reconstructed everywhere they are used.
Mission critical
When software acts, its decisions become facts.
A Streamhouse must meet the reliability, availability, and recovery requirements of the operational infrastructure when applications depend on its state to run the business. There is a fundamental difference between using data to explain what happened and using it to decide what happens next. A wrong number in a report can be corrected. But if an AI agent issues a credit, promises a delivery, or releases a shipment based on incorrect information, correcting the data afterward may not undo the action.
Maintained state must survive failures, remain available under load, and recover within predictable timeframes. An unavailable analytical dashboard may delay a report. An unavailable Streamhouse supporting order fulfillment may stop orders from moving.
The Streamhouse must be able to evolve safely without breaking the systems that rely on it. A database schema change, for example, should be validated and propagated through processing and downstream tables without unexpectedly breaking the applications that depend on them.
Operational systems still authorize and commit transactions, but the Streamhouse must enforce security and permissions, and make failures visible so applications can respond safely.
A Streamhouse is not just responsible for keeping the business current. It must help keep the business running.
The category is already forming
The architectural patterns behind Streamhouse have existed in production long before they had a name.Companies have been combining change and historical data, incremental and batch processing, and different serving systems for years. The value is when they all come together in a seamless experience.
Let’s look at some examples that show how the industry has been approaching the same problem from different directions.
- Siemens Healthineers uses Apache Flink to process and enrich operational data before it reaches the warehouse, supporting multiple downstream consumers through a shared streaming backbone. They eliminated expensive, multi-hour batch reprocessing cycles ahead of Snowflake.
Siemens Healthineers uses Apache Flink to process and enrich operational data before it reaches the warehouse, supporting multiple downstream consumers through a shared streaming backbone. They eliminated expensive, multi-hour batch reprocessing cycles ahead of Snowflake.
- Neuron Systems uses durable event streams to coordinate AI agents providing live sports commentary. Hindi, Spanish, and English commentators react to the same play using the same underlying game state, preventing contradictory commentary across agents.
Neuron Systems uses durable event streams to coordinate AI agents providing live sports commentary. Hindi, Spanish, and English commentators react to the same play using the same underlying game state, preventing contradictory commentary across agents.
- Yelp independently describes its own streamhouse architecture using AWS services, Apache Flink, and Apache Paimon, without Confluent. It reduced analytics data latency from approximately 18 hours to minutes and storage costs by 80%.
independently describes its own streamhouse architecture using AWS services, Apache Flink, and Apache Paimon, without Confluent. It reduced analytics data latency from approximately 18 hours to minutes and storage costs by 80%.
In September 2026, Aiven, Confluent, Redpanda, StreamNative, and Ververica formed the Streamhouse Working Group to establish an open definition for the architecture. Ververica originally coined the term, and the founding members agreed to make it freely available for anyone to use.
The opportunity now is to take these patterns beyond individual implementations and make them reusable across the enterprise. These examples demonstrate different implementations of the same architecture. The underlying technologies already exist. The next challenge is bringing them together into an architecture as straightforward to use as a database.
Building a Streamhouse with Confluent
Confluent has spent years building the technologies that make a Streamhouse possible, alongside customers who have been using these technologies to run their businesses. Today, the Confluent Data Streaming Platform provides the most complete, performant, and open platform for building the Streamhouse. Confluent brings together the capabilities to capture, stream, process, govern, and serve the business state as it changes.
Apache Kafka provides the durable, replayable event backbone. Kafka Connect and change data capture integrate operational systems and make their changes available across the business. Apache Flink combines historical data with those changes, continuously maintaining useful business state through SQL, the Table API, and stateful processing. Stream Governance provides schemas, data contracts, cataloging, and lineage, with broader business semantics and cross-estate governance still to come.
Confluent also makes that state available in the form consumers need. Lightning Tables provides low-latency access through SQL, APIs, and MCP, while Tableflow publishes streaming data into open analytical formats such as Apache Iceberg and Delta Lake. The same underlying business state can support applications, AI agents, and analytical platforms without each independently rebuilding it.
The architecture is built on open technologies and designed to connect existing systems rather than replace them. Through IBM, we are extending its reach further into the operational estate, including mainframes, enterprise databases, and hybrid environments where much of the business already runs. That connection is critical to delivering a Streamhouse across the entire enterprise, not just the systems already using modern data platforms.
Confluent's advantage is bringing these capabilities together as one Data Streaming Platform. Customers should not have to assemble and operate a collection of independent technologies to maintain a current understanding of their business. We are making the Streamhouse a complete platform they can build on.
The Confluent Data Streaming Platform provides the most complete, performant, and open platform for building the Streamhouse.
What to Do Now
Start with the business entities that matter most to your operations: an order, a customer, an account, or an entitlement. The information needed to act on each may already be scattered across systems that were never designed to answer the same question together.
For each one, ask four questions:
- Who owns it? Which systems are authoritative for the facts, the changes, and the transactions?
Who owns it? Which systems are authoritative for the facts, the changes, and the transactions?
- What does it mean? Which definitions, relationships, policies, and exceptions determine how that information should be interpreted?
What does it mean? Which definitions, relationships, policies, and exceptions determine how that information should be interpreted?
- What are we rebuilding? How many applications, pipelines, transformations, caches, and analytical models independently reconstruct the same information or business rules?
What are we rebuilding? How many applications, pipelines, transformations, caches, and analytical models independently reconstruct the same information or business rules?
- What decisions depend on it? How current and correct must the information be, and which system actually has authority to act?
What decisions depend on it? How current and correct must the information be, and which system actually has authority to act?
As you ask those questions, you should pick the entities and the decision where maintaining a reusable understanding of the business makes the greatest impact. It will very likely align with where you are applying AI to change how you are running your business. This is eerily similar to the decisions you likely made when you were applying software to change how you were running your business. Going back to Jay’s blog, every company is software, and every company is becoming AI, after all.
Once you pick your problem, these are the broad strokes. Build the initial state from history. Capture changes. Maintain useful results. Connect the definitions and governance needed to trust them. And serve those results in the forms the consumers need.
The next generation of software will not wait for the business to catch up. Its data architecture should not have to either.
Your business, always current.
To begin implementing a Streamhouse architecture with Confluent:
- Attend the webinar:Streamhouse: The Data Architecture that Powers AI at Machine Speed
Attend the webinar:Streamhouse: The Data Architecture that Powers AI at Machine Speed
- Examine what it looks like when an organization uses Streamhouse:Download the solution brief
Examine what it looks like when an organization uses Streamhouse:Download the solution brief
- Review the eBook:Your Business Keeps Changing. Can Your AI Keep Up?
Review the eBook:Your Business Keeps Changing. Can Your AI Keep Up?
- Start real-time data streaming in minutes:Sign up for Confluent Cloud
Start real-time data streaming in minutes:Sign up for Confluent Cloud
The preceding outlines our general product direction and is not a commitment to deliver any material, code, or functionality. The development, release, timing, and pricing of any features or functionality described may change. Customers should make their purchase decisions based on services, features, and functions that are currently available.
Confluent and associated marks are trademarks or registered trademarks of Confluent, Inc.
Apache®, Apache Kafka®, Kafka®, Apache Flink®, Flink®, Apache IcebergTM , IcebergTM , Apache ParquetTM , and ParquetTM are either registered trademarks or trademarks of the Apache Software Foundation in the United States and/or other countries. No endorsement by the Apache Software Foundation is implied by using these marks. All other trademarks are the property of their respective owners.
