We built for humans first – Agents felt right at home

After writing this article, I realize the core statement of “building for humans means building for agents” seems somewhat obvious. Yet a whole product category exists because most databases were never built this way.

Arriving at this conclusion in this day and age has been a very rewarding journey. Here’s how we got there.

We set out (and still are) building Mycorr as the data layer for humans who don’t necessarily know Python or SQL - for those who know what a “thing” in the physical world is, and need ways to model it in data. Without setting up IT projects, anyone should be able to create, edit, version and safely share data.

The pain we wanted to have a solution for was the gap between spreadsheets being misused as databases and databases being too rigid for end-users. One could argue there are tools like Airtable, but they have restrictive row limits and became a patchwork of features, which made them harder to use.

When we started about three years ago we knew our UX compromises would be defined by the end members of the gap we want to fill. How do you make cell editing simple in a columnar fixed datatype environment? How can we give columns free text names? What are foreign keys to users that don’t know databases? How do you collaboratively edit a database Figma-style?

We started pre-AI, hand coding, testing endless patterns, converging towards solutions we liked and found the next tension - always inching forward. This wouldn’t have been possible without the choices we made early on that made iterations quick: Rust backend and WASM frontend, DataFusion for AST analysis and execution, OpenFGA for tight control on who can do what, and ultimately an actor model.

Semantic Layers

Despite there being many products out there adding semantic information to databases that have cryptic column and table names, they felt somewhat far away from us. We needed to give the users the option to name their columns how they liked, add descriptions to any column or table. That was so natural that we only realized later that not having semantics part of a database is a massive limitation and why a billion dollar product category exists to fix it. But then again - we were not building for people writing YAML files, but the people plastering their spreadsheet full with annotations.

Databases were not really built to have semantics attached to them because their “users” were deterministic systems with fixed functionality. Later, with more flexible BI tooling came more questions, which needed more “documentation”. Now, with agents in the mix, cryptic naming is debt that needs to be paid.

The graph

Sharing data was another pain felt deeply in our previous jobs. Spreadsheets are a big “please don’t”, and databases are too complicated to share to another colleague.

Two things that are inherently linked to sharing are versioning and linking. If I share a version of the data, I don’t want anyone to see edits I’m in the middle of before I release the next version. This led us to checkpointing and releases of versions.

Linking is about not blindly duplicating data of others, but to link to theirs through common columns - similar to foreign keys, but federated and not constrained.

These two additional concepts bolted onto sharing naturally span a graph between users and let important concepts emerge - heavily linked tables become spines of an organization and need special governance. We believe data models should not be described top down as ontologies unless you want to burn lots of money, but emerge naturally from use.

Links are declared by the people who make them, not guessed from matching column names or statistical overlap, so every connection in the graph exists on purpose.

Hey, let’s try this MCP thing

We thought let’s just give an agent a couple of tools where they can search for tables, get the context we also give the users, and run SQL - and see what happens.

We were completely blown away. The agent quickly answered questions correctly spanning multiple shared tables without any custom tooling for it. The agent was doing exactly what a human would do: search, describe a table, look at what other tables the user linked it to, query some data, filter, sort, join.

When we added some charting we knew this is the future. Who wants to learn how to construct a pivot table or transposed bar chart in some tool if you can just ask for it?

We didn’t need to treat the agent differently than a human. Anything we built for the latter would serve the former. So we built proper units on columns, constraints, and much more.

Now, we use agents to work hand in hand with us on anything in terms of data - and we can inspect the same data and context they see while they work.

We built for humans first. That turned out to be exactly what made agents feel at home.

Thanks for reading - Stay tuned for more updates on mycorr.app