What is Mesa?

Mesa is building GitHub for all knowledge work, starting with a programmatic storage layer designed for a world of massively parallel agent collaboration.

Mesa is a bet on the future of work

Our private beta leaves us with one unmistakable insight: a new way of work is emerging, powered by agents. Across all disciplines — legal, healthcare, insurance, business operations, sales, marketing, code, and others — the conversations with those building and using agents is the same.

• “How can we surface the right context at the right time?”
• “How can we enable multiplayer experiences between agents and humans, agents and agents?”
• “How can we enable agent parallelization, draft states, rewindable and forkable agent sessions?”

The signal is clear: agents will be doing all knowledge work very soon and the best teams and products will rely on a certain set of capabilities to manage these agents effectively.

Git was popular for many years because it was a new technology that unlocked a new type of work – open source, decentralized development at scale – but it took the introduction of GitHub to make Git the standard. GitHub took a powerful but messy piece of technology in Git and layered on a set of opinionated workflows for how to build with it.

Mesa as a product and a company is fundamentally a bet that we can do for AI agents what GitHub did for Git. The opportunity is not to be just some cloud filesystem (those have existed for a long time), nor even a high-performance VCS (faster Git isn’t the missing piece for the future) but that the higher-level APIs and workflows built on top of these primitives can unlock a new type of productivity for teams building and using agents.

We’re in the early days of knowing how to work with agents effectively: how you manage context, debug and evaluate agent runs, create robust human-in-the-loop flows, operate multi-agent systems, collaborate in realtime, review changes, fix mistakes, and ultimately create self-improving systems. Whoever can define and codify these best practices will become the most important control plane for how every team works – those building agents, those using agents, from the technical to non-technical alike.

We’re already starting to see common patterns forming amongst our early beta users and we expect our understanding of these patterns to accelerate as time goes on.

All knowledge work will be done by agents

This work will require the production, iteration, and collaboration of long-lived artifacts that exist beyond a single agent’s session.

Examples of such artifacts include:

• Memories for agents that are unique to users, projects, and organizations
• Skills shared by a marketing team inside of a GTM agent platform
• Code generated for personalized UIs and Applets
• A .csv or .excel file produced by accounting or FP&A agents

These artifacts will be created at a very high velocity, edited by both humans & agents, and this work will be supported by a set of capabilities to manage these changes effectively.

Draft states will be a fundamental primitive for managing agent-driven changes, and parallel agent execution on isolated branches will make it easy to rapidly explore the trade-offs to different approaches.

Critical changes to documents – e.g. updating memories – will need a ledger of historical changes and it'll be common to use a combination of humans and agents to audit this ledger for evaluation, debugging, and context for current tasks.

In essence, these artifacts will need to be managed in a manner similar to the way code has traditionally been managed - with Git-like primitives, conflict resolution, and high performance remote storage being critical features.

The filesystem is just an implementation, change control is the feature

Our thesis for solving this problem can be boiled down to one deeply held belief: change control is the most important primitive required for the new world of agentic work. At the scale and speed that agents do work, the bottleneck quickly becomes how fast you can manage and control the changes to these artifacts.

Take the simple example of an independent real-estate lawyer who redlines contracts and emails drafts to relevant parties. They work at human speed and can afford to have their limited set of files scattered across email, GDrive, and their computer — with names like lease_final_final_v4.docx. In a few years this same independent lawyer will instead have specialized agents investigating each section of the lease, redlining, highlighting risks, and doing deep research to identify relevant precedents.

The lawyer's agents will read and write to the files instead of the lawyer and they will need a source of truth to do so, their changes will need to be staged for approval and comment from the lawyer, and their changes will need to be tracked, potentially rolled back, or forked throughout the course of a deal.

It’s not obvious at first that change control matters so much. Filesystems are the hot topic right now but there’s a million products that let you store and retrieve documents. A POSIX-compatible interface in front of S3 won’t be the product that becomes key to the next era of knowledge work. The filesystem matters as an interface because that’s what models have come to expect but it’s the versioning, access policies, and workflows that will unlock this new way of working.

Git and GitHub are the wrong technology for the coming world

If versioning matters so much why is GitHub not fit to solve this problem? Because Git isn’t the right VCS for a world of agents. It’s asynchronous, designed for the access patterns of slow human edits, and doesn’t easily support larger files nor non-text filetypes. It also doesn’t have the metadata and storage capabilities needed for most agent use cases.

Mesa is built on top of Jujutsu instead of Git. JJ is a meta-vcs that provides a data model and versioning semantics very similar to Git but allows us to bring our own implementation for how the underlying objects are stored and retrieved. This modular design allows us to extend JJ with some very difficult, but very critical features for a truly agent-first version control system.

Agent Context

The world doesn’t revolve around branches and commits anymore, it revolves around sessions, turns, and steps. With Mesa’s VCS we can capture and store agent traces tied to the version tree itself. You can rewind not just how your files changed from point A to point B, but also record the logic and context that led to those changes.

Realtime

Agents need realtime updates so that swarms can co-ordinate, UIs can be updated for users, and subagents or deterministic workflows can be triggered while listening to the event stream of certain files and repositories. Git was designed for async, decentralized development. With Mesa we’re breaking free from this constraint and every single part of our filesystem and version control server works in realtime enabling powerful multiplayer experiences.

Context Retrieval

It’s critical for agents to find the context they need across files and across the history of changes to those files. With our custom storage backend we can enable efficient embeddings built into our version history and provide powerful semantic search as well as graph traversal APIs. This makes agents more efficient and makes the historical record more easily auditable.

Conflicts

Whenever you have multiple entities updating files, you’ll have to resolve conflicts between their changes. In Git, conflicts block the current operation. An operation to sync data from an external source, refreshing your agent’s branch, or merging changes can lead to a conflict that requires immediate resolution or the operation needs to be aborted.

In Mesa and JJ conflicts are modeled as a fundamental primitive of the version history. You can let your agents auto-resolve the conflict, block the agent and render a UI for a human to resolve, or even accept the conflict and let the agent keep executing, allowing a human or specialized subagent to come later and resolve it. Regardless of how it’s resolved, a conflict is always preserved in the historical record so you can revisit and even revise how a conflict was resolved if necessary.

Resolving conflicts is a highly semantic activity! You can’t just say “last write wins” every time because that’s not appropriate for a lot of use cases. Git doesn’t give you the flexibility needed to deal with conflicts in all the ways that they will appear in a world of massively parallel agentic work, and Git doesn’t preserve a history of conflicts so these critical decisions are un-auditable. In Mesa you can handle resolutions however your use case demands and you can always re-visit and even amend how a conflict was handled in the past.

Scaling

GitHub is literally melting down and the biggest companies in the world have long-since abandoned Git in favor of more scalable homegrown version control systems. With our custom backend we can take advantage of modern techniques for distributed, highly scalable storage with performance tuned to our needs.

~~~

Agents are a new technology enabling a new way of working for all knowledge work disciplines. Similar to how GitHub codified the best practices for Git, Mesa will codify and enable the best practices for building and working with agents effectively. The core market insight for how to do this lies in the importance of change control and the technological insight lies in recognizing that Git itself is not capable of serving the version control needs for agents. By building a novel programmatic storage layer for agents we’re laying the foundation for all change control in a world of agents and setting ourselves up to build the canonical workflows that every team will use in the future.