What I build when
I set myself
the brief

An announcement that could backfire. You describe your plan in one sentence and add a few of your own documents — market analyses, reactions to earlier decisions, feedback from retailers. From that, HiveWeaver builds the audience itself and plays the announcement through. The bundled example is a manufacturer who will no longer include a charger in the box: how does that land, and with whom does it land worst?

A vote before the vote. Five thousand citizens in different circumstances, plus a handful of voices with reach. The same policy is played through in three versions — in the example a four-day week, a congestion charge and school uniforms. In the end you see not only which version carries the most people, but also which argument sinks the others.

A campaign across several channels. The same content as a video, as an image campaign and as a professional post, each against the audience that actually spends time there. Or, a size up: ten thousand traders betting on an outcome — the likely price settles by itself, without anyone setting it.

What all of these have in common is that you end up not with a gut feeling but with a written result and its reasoning — plus the ability to read back every individual reaction that led to it.

Adding appointments, answering and sorting emails, sending a summary at six in the morning: HiveWeaver handles that too, and the matching flows ship as ready-made examples. It is simply not what sets the platform apart from other systems — plenty of tools solve those tasks by now.

The difference shows where many cases run at once and influence one another. Take a wholesaler's complaints handling: hundreds of cases a day, dragging on for weeks, with queries, partial deliveries and escalations. In HiveWeaver every case gets its own agent that accompanies it from beginning to end and remembers what has happened so far — no context that has to be reassembled on every call. Alongside them stand roles: a reviewer, the specialist department, the approver. They talk to each other instead of working through a rigid chain.

A case where nothing is happening right now costs nothing. That is why ten thousand of them can be open at the same time without the bill exploding. This is precisely the difference from an assistant you pay per call and that forgets what it was about after each one.

The real advantage, though, comes earlier. Before a single real customer is affected, you run that same process against invented customers — including the awkward kind who fill the form in wrongly, chase three times and cancel in the end. You see where it jams, improve it, and only then switch to live operation. It is the same process, not a test version of it. With an off-the-shelf assistant you go live and hope.

On top of that come the things such projects usually founder on inside a company: everything can stay in-house, language model included. Every step is provable after the fact — who, when, why, at what cost. And anything that costs money or cannot be undone waits for approval instead of simply happening.

In AI projects it is usually not the technology that becomes the problem but the invoice at the end of the month. That is why HiveWeaver settles up front which decision may consult a language model and which may not.

An example from the bundled scenarios: on a marketplace the market maker calculates by fixed rules — it needs no model to match supply and demand. Only the traders, who are meant to read a mood, actually ask. The bulk of operations therefore costs nothing.

The same distinction works within a single run: the few voices with reach get the expensive, careful model — the thousand listeners in the audience get a cheap one. The result stays meaningful, the bill stays manageable.

And because what every single step cost is recorded, after the first run you can see in black and white where the money goes — instead of finding out at the end of the month.

An empty distribution is already a complete workbench. A rail with the tools on the left, panes in the middle that split by dragging and pop out into their own window, tabs inside them with preview and pinning. On top of that, named workspaces that capture a whole way of working, a command palette, quick open, settings with permissions, and a catalogue from which users install extensions.

Everything a person does there by hand, your own code can do as well: every pane, every workspace, every switch is at the same time a service the product itself calls. Turn a built-in control off and offer the same action from your own toolbar. A switch removes the control, never the capability.

The user interface runs without a backend. Where there is one, it reaches it through three narrow ports: settings, working state and sign-in. Which technology sits behind them is of no concern to the platform.

A good tool sparks ideas, and some users would build them themselves if they could. They cannot, because there is no way in. Opening one means isolation, permissions, a catalogue, updates and an interface you promise not to break. That is not a feature, that is half a year of work.

LoomWeaver distinguishes three rungs. Your own extensions run composed into the product. Someone else's code runs isolated in its own frame with no reach into the page, written in whatever framework they like. And from a curated catalogue users install at runtime themselves, after a dialog that lists the capabilities requested. What the user has allowed, the user can also revoke, disable and remove.

All three rungs use the same contract behind the same broker, which denies every capability until it is explicitly granted. Moving an extension down a rung is a decision about trust, not a rewrite.

In LoomWeaver an action is registered exactly once. From that come the button, the shortcut, the context menu and the palette entry, without anyone maintaining four lists. With a single flag the same action additionally becomes a tool for an AI agent. There is no second list of tools beside the first, so it cannot drift apart.

For the link to the agent, LoomWeaver relies on AG-UI, an open protocol between an application and an agentic backend that is not mine. A backend that speaks it drives the product with nothing in between, and the other end can be swapped. Which model does the work, which transport, which key: that remains your decision.

Every call passes through the same seam a click does, so the agent inherits the capabilities and the access rules that already apply. A refusal reads the same whatever its reason, so nothing can be learned about what is installed by asking. If the person says no, the workbench is never asked.

An input is not processed on the spot — it is accepted and acknowledged. The interface gets its confirmation within milliseconds and does not wait for writing, checking and reporting to finish in the background. To the user the application feels responsive even when there is a lot to do behind the scenes.

The actual work is distributed by a message bus to workers that share the load between them. As demand grows you put more workers next to them, on the same machine or on additional servers. That is the difference between "we need a bigger machine" and "we start three more instances", and it decides your cloud bill later on.

So that multiple workers do not get in each other's way, the data streams are fixed across 4096 partitions. For any single business case exactly one worker writes — across different cases everything runs in parallel. Reporting is then actively notified rather than polling in a loop to ask whether anything is new. That is why read data is virtually up to date without a database being queried constantly for nothing.

In .NET methods are often invoked dynamically — convenient for the developer, but every single call costs something. On a business case with ten entries you will not notice. On one that has grown over years it adds up with every entry. Stratara therefore translates these call paths once into a fixed function and then calls it directly. What has been resolved once stays resolved.

The effect is measurable. A business case with a million entries is rebuilt completely in a good eleven milliseconds — and memory use stays constant at 64 bytes regardless of length. Put differently: no garbage is produced for the memory manager to clean up later, however long the history grows.

The numbers come from a fanless MacBook Air, not from a tuned server. They are conservative rather than flattering — and you can re-measure them yourself, the benchmark project is in the repository.

Every entry carries the fingerprint of the one before it. If an amount is later changed directly in the database — through a faulty migration, a restored backup, or deliberately — the recalculated fingerprint no longer matches the stored one. The next verification pass does not merely report that something is wrong, it names the exact position.

A chain like this on its own will not stop someone with full database access who simply recalculates every fingerprint. That is why a checkpoint can be anchored outside your own infrastructure at regular intervals. Stratara records that point; you connect the external source. I would rather say this plainly than promise more with the word "immutable" than the technology delivers.

Anyone wanting to truly remove one person's data would have to catch it everywhere at once: in the history, in every report derived from it, in intermediate states, in every copy and in every backup ever taken. Within the statutory 30-day window that is barely achievable in a provable way — one overlooked backup is enough.

Stratara turns the task around. Each data subject's information sits under its own key. A single call destroys that key, and with it every copy becomes unreadable in one go — including those nobody can technically reach any more. The history stays complete, but the person can no longer be reconstructed from it.

The same mechanism carries two further topics: it separates different customers' data cryptographically, and it provides the key management that auditors ask about under SOC 2 and ISO 27001.