Most teams take the summer off. We took ours apart.

While the rest of Norway was at the cabin, the four of us spent June, July and the first week of August pulling our own platform to pieces. We built a playground you can actually touch. We pointed coding agents at our own plumbing. And we found out, repeatedly and a little uncomfortably, that the thing standing between us and a great industrial data platform was very often us.

Here is the behind the scenes version: the discoveries, the lessons, the things that broke. No highlight reel. We kept the bruises in.

1. The playground

Our category has an abstraction problem. “A shared model of your assets, processes and business context, with lineage on every derived value” is a sentence people nod at. Nobody feels it. So this summer we finished building something you touch instead.

It’s a guided build your own graph tour inside the console. It includes 49 steps split across five main chapters: Datasets, Resources, Timeseries, Events, Build a network. Pick your industry and the examples reshape around it. For instance, if you choose oil and gas, you will practice modeling valve pressure sensors by creating Valve A, connecting it directly to Valve B, and attaching a pressure measurement series to it.

Then you actually do it. You create a dataset, a labelled resource, a second one connected by a named relationship, and a timeseries with a specific unit and a value type.

The guided tour pushes two days of hourly readings in and charts them, logs a threshold alarm and a completed inspection against your asset, then grows nine more nodes around it.

These form a clear branching tree, while the rest of the network fades into the background to highlight this specific area. When you finish, you can choose to save the network or delete it.

The readings are synthetic, but everything else is completely real.The data flows to the actual ingestion endpoint with a real bearer token, over the same path a developer would use. No demo mode, no server code written just for the tutorial. You are using the actual product directly through the main interface.

What building it taught us

Watching someone build teaches nothing after the first node. To end the tour on a network big enough to feel like a graph, the obvious move was to have the visitor build it , five to ten nodes by hand. We didn’t. Making users build repetitive nodes by hand is boring and doesn't teach anything new after the first node.

Instead, the tour creates the cluster for you automatically. That way, you can spend your time learning how it works. When using a tool built around structure, the real payoff is seeing that structure, not doing manual data entry.

Every safety restriction we added trapped somebody. To keep users from wandering off during a step, we disabled everything on the screen except the highlighted button. That caused big problems. For example, users could not close drop down menus, leaving them stuck with a disabled Confirm button and no way out.

We disabled keyboard shortcuts too. Early testers could not refresh the page, search for text, or open developer tools.

Finally, the last step called Your Turn released as a total dead end where nothing was clickable. It stayed broken like that for nine days.

Confident-looking UI is worse than none. One step asked users to find a specific item in a list and click it; in a tenant filled with similar looking rows, the app confidently spotlighted the wrong one. To fix this, we removed the manual selection step and replaced it with an automatic load.

The uncomfortable finding

To glue a tooltip to a node in the graph, the tour has to wait for that node to exist first. A resource you just created is still propagating from Postgres to Neo4j through Pulsar. So the playground carries a polling loop with a 30-second timeout, re-fetching the network while it’s still empty, waiting for our own eventual consistency to catch up.

We originally built that check just for the tutorial. However, it revealed a real delay for our customers that we had never noticed before. No other part of our app asks "is it ready yet?" the way a step-by-step tour does. The tour's first real discovery was actually a hidden problem in our own product.

2. Agents doing the plumbing

Roughly 44% of this summer’s commits list Claude as an author. The split isn’t “agents write, humans review”. Instead, it is closer to “agents do the plumbing, we do the thinking”.

In practice, writing down detailed project specs became a core part of the job. When we changed external-ID validation to accept real industrial tag formats, the work started as two documents, one arguing why and one specifying how. The second records the alternatives we rejected, lists acceptance criteria you can falsify, and warns that the raw hash call it replaces appears in about 53 places. Then once the plan is completely laid the agent builds it.

Agents also got a front door: an MCP server with 36 tools, on the same OAuth2 chain and access rules as everything else. Setting it up all summer was almost never about capability. It was about context. Results now strip out and empty collections, list tools return lean projections with an explicit truncated flag instead of silently hiding extra data, and the event tool has two modes on purpose: counts grouped by type first, individual events second. As the developer who built that filter put it:

“MCP doesn't like large api bodies with explicit nulls etc, it's mostly for quick lookups and doesn't want to cluster context too much.”

3. What we didn’t expect

Directing AI agents at our own platform found things our own UI had been hiding.

The clearest: creating a new resource failed with a 409 error whenever you reuse a label that already existed. Labels are stored in uppercase and the lookup was case sensitive on the raw input. Since every resource needs a label, this made the core "model your assets as a graph" flow basically unusable through the API, and invisible in our console, because the console never lets you type a label. It makes you pick one. Every SDK, MCP and curl caller hit it immediately. We had not, for the better part of three years.

Then the one that stings. Our MCP tool docs, and our own agent instructions, stated that a role check guarded the data path. No such check existed anywhere in the codebase. Method security was switched on with nothing to enforce, so a token missing the role that was supposed to gate everything could still create, mutate and delete. It had been that way for nearly three years, and the confident documentation is exactly what stopped anyone from checking.

That is the lesson we keep coming back to. Agents do not fix bad data, or bad docs. They act on both, faster. An agent reads your documentation as ground truth and drives your API as written. Every gap between what you claim and what you enforce becomes a live action instead of a stale sentence.

So, this summer we found housekeeping jobs that would have deleted actual live tenant file storage, saved only by a dry-run default and a shared cache that let one tenant read another tenant's value. That was pure luck, not design.

Which brings us to the point.“Agent-ready” isn’t a feature you bolt on. There is no MCP layer you can add to a system that doesn’t already know what its data means. What makes a platform agent-ready is exactly what makes it good anyway: one model over assets, time-series and events; lineage on every derived value; standard components underneath; and enforcement that lives where the work happens. Ours moved into the services rather than the controllers, because the MCP tools call the services directly. As the code comment now reads: a governance rule enforced at one of several doors is not enforced.

We didn’t set out to prove our own thesis this summer. We built a playground so other people could feel it, and pointed agents at our own plumbing so three engineers could keep up. Both turned around and tested us instead.

---

The platform is AGPL-3.0. Self-host it for free. All source, all features, no gates. The tour ships with the console, so the first thing you build in DataHub can be a graph of your own operation rather than a diagram of ours.