Essays · Published · Stefan Hamann

The End of Software as We Know It

What if standard software could learn how a particular business works? Stefan Hamann explains the idea behind Holodeck and what the first Shopware experiment has demonstrated.

Creative AIMerchant operationsShopware

Holodeck illustration showing one deck projecting a storefront, checkout and new business models.
The software takes the shape of the work.

From Apps to Holos

I’ve spent most of my working life building standard software. You build it once, thousands of businesses use it, and everyone benefits when it gets better. The awkward bit is that those businesses all work a little differently. At some point someone starts a spreadsheet. Then someone starts a spreadsheet to explain the first spreadsheet.

That spreadsheet usually knows something the application doesn’t. It knows how the business actually works. I want to put that knowledge where the whole business can use it.

What I mean by a deck

A deck is an AI model that embodies a specific piece of software in full. It carries the processes, views and executable rules of, say, a commerce or accounting system. It can take in a request, understand what it means for the business and decide which of its capabilities to use. Today a copilot sits beside an application and helps people use it. With a deck, that understanding lives in the application itself.

The name comes from the Star Trek Holodeck. One room takes different shapes depending on what people need to do. I call those working projections holos. One might be a single approval, another a complete workspace a team opens every morning. Both come from the same deck. The prototype has learned and transferred a small commerce rule. A whole application is what we’re working toward. Holodeck on GitHub

A normal Tuesday gets better

A business should be able to buy standard software without having to become a standard business. That’s the everyday reason I want this. A request can come in as a photo, a voice note or a PDF. Its context follows the work. The deck can handle routine steps, wait for a decision and pick up when it comes in. Change an approval rule and the change follows the work across the storefront, the service desk and the tools the warehouse uses.

One return seen from three roles. The buyer starts it, customer service checks eligibility, and the warehouse inspects the parcel.
The buyer starts a return, service checks the policy, and the warehouse inspects the parcel. Each sees the step they need.

The same applies to personalisation. A new customer might need help choosing. A trade buyer might want one button to reorder. Both get the prices the merchant’s policy calls for. Your A/B test is going to need a bigger alphabet. Good views can also be saved and reopened with fresh data. The warehouse has enough to do before breakfast without asking a large model to reinvent the stock screen.

The Holodeck had Safety Protocols. I’d like tax calculation to have a very boring day. The business sets the rules and who can approve what. The deck applies them. On a return it works out what policy applies and what the next step is. The runtime knows how to subtract two numbers. The deck knows when that subtraction is a refund. The interface can disappear. The agreement stays.

The Agent Is the Shop

I want Shopware to become a deck for commerce. The storefront, checkout and admin are already different views of the same business. More than two decades of how merchants work are written into Shopware. I’ve started to see that as a curriculum. We can run different merchant configurations, observe what happens and teach a deck how to get the same outcomes. The idea applies just as well to accounting, procurement or service. Commerce is where I know the work best. Shopware’s agentic commerce direction

Once the software understands the ordinary work, things get interesting. Say a furniture merchant wants to try renting the chairs it already sells. In an afternoon it could have a customer view, monthly billing rules and a return inspection queue ready to rehearse. The deck can put the logic and the views together, then deliver them where people need them. The merchant can try the idea before deciding what to keep. Amazon has the engineering organisation to build experiences like this for itself. I want a merchant with twelve people to get them from the architecture.

The same chair supports two businesses. A sale is paid once and ships out of stock. A rental bills monthly and schedules a return and inspection.
The new rules reach all the way from monthly billing to the return inspection.

What runs today

In Shopware’s Agentic Commerce Lab, Shopware × Claude searches a catalog, builds a cart and hands it to Shopware checkout. The merchant side previews proposed changes before applying them. Experience Studio is our research preview for building working storefronts from a description. Shopware × Claude

At Veyndo, my own lab for commerce experiments, Nord Atelier builds the parts of the shop you need as you browse. Ask what to wear to dinner and it puts together a collection. Ask “Coat or blazer?” and you get a comparison with prices. That’s OpenUI from Rabi Shanker Guha and the Thesys team. OpenUI assembles a view from known components. MCP Apps gives tools a way to put interactive views in the apps people already use. Watch the demo · OpenUI · MCP Apps

For Nerds

How we teach it. Run Shopware with different merchant policies. Record what went in, which actions were allowed and what changed, including the cases where the answer was no. A multimodal foundation model helps connect a request to business objects. Small trainable parts learn which facts to read, which exact operations to run and when the process should continue. Together they form a readable executable graph. Test it on merchants and policy combinations it hasn’t seen. Learning design

How it runs. Give the deck an event and current records. The same graph supplies the proposed changes, the allowed next actions and the controls the holo can show. Exact operations do the maths. A small commit core checks who is allowed to act, whether the records are still current and whether the changes can be saved together. A useful holo can be reopened against current data. Architecture

Target design. An intent or event and live business state enter one deck with multimodal understanding and an executable business graph. It projects a shopper storefront, a trade checkout or a returns workspace. A generic runtime checks and records proposed effects.
Target architecture. The same business rules determine what happens and what each holo lets someone do.

What we’ve actually shown. Holoshop learned a capped service credit from three examples and matched all twelve test journeys at a second merchant. The native implementation matched 168 recorded transitions. Direct rule generation with Qwen matched the adapted model on the additional arithmetic cases. The current host still decides parts of cart eligibility and order formation. The next test is an ordinary order through payment, fulfilment and a partial return. Change a rule in the deck, keep the host fixed and see if the outcome, next action and interface change together. Published experiments and replay · Research roadmap

Let the people doing the work shape the software

I want the people who know why the spreadsheet exists to have a say in how the software works. They should be able to describe the job, try the change against real cases and keep it when it works. Over time the business gets software that knows more about how it works, because the people doing the work helped teach it.

Which spreadsheet in your company is secretly software? Tell me what it decides and what happens next. If you have a case that would make a deck earn its keep, bring it to Holodeck on GitHub. I’d love to see what we can learn from it. Read Agentic Commerce

Source and further reading

Original article on LinkedIn ↗

Holodeck in the project directory ↗

The Agentic Commerce handbook ↗

Save and share