The next infrastructure layer will not be owned by one company.

For thirty years the dominant pattern of scientific computing has been the same: a brilliant research group writes a tool, publishes a paper, and watches the tool die in a Docker container that no one can find six months later. The web gave us an internet of documents; we never built one for tools.

We are now at a moment when this changes. The reason is not, primarily, that AI agents have arrived (though they have). The reason is that agents force the question that was always there: where is the catalog? If a model can install and run any tool, the bottleneck is no longer the tool. It is the index of tools, the contracts between them, the lifecycle they share.

That catalog cannot be locked inside one company. The catalog of human scientific tooling does not belong on a single private server. It belongs in the substrate: Git-hosted, federated, owned by the communities that use it. The open core stays open. We make our money on the managed layer that sits on top: hosting, enterprise album-mcp, the SLA. Album was designed for this five years ago. Album-mcp wires it into the agentic AI era.

What follows are five axioms. They are how we think about this work, why we declined to build a centralised registry, and what we believe the next decade looks like for scientific computing.

Axiom I. The agent is the user.

A.I. The user of scientific software, in 2030, is no longer a graduate student reading documentation at 3am. It is a model dispatching tools on her behalf. All design surfaces orient to that user.

This is a small statement that follows through to nearly every decision. CLI flags and docstrings do not survive in a world where the caller is a model. Typed schemas do. RDF metadata does. Idempotent operations do. We are not designing for documentation we hope someone reads. We are designing for a tool list a model can call cold.

The corollary: discovery is no longer an interface concern. It is a contract concern. list_solutions and search_solutions are not menu items; they are the front door. Which is why album-mcp privileges them.

Axiom II. Catalogs are decentralised, or they are wrong.

A.II. Centralised registries become bottlenecks, gatekeepers, and finally extraction mechanisms. Scientific catalogs must be Git-hosted, federated, ownable by their communities, indexable by any agent.

We have already seen what a centralised package registry looks like as it grows up. It looks like extraction: ads, paywalls, deprecation, lock-in. PyPI is fine, for now. But scientific software is not pip-installable, and the communities that produce it cannot afford to be tenants of a future Docker-Hub-style ad layer.

Album catalogs live where Git does. GitHub, GitLab, your university's self-hosted instance, your enterprise's behind-firewall server. Album-mcp can index any of them. We are not the catalog; we are the protocol that lets an agent find your catalog.

Axiom III. The lifecycle, not the function.

A.III. A scientific tool is not a function. It is a lifecycle: install, prepare, run, finalise, validate, deploy. Treating it as a function is what made reproducibility hard.

The early MCP examples in the wild are function-shaped: an agent calls a tool that takes a string and returns a string. This works for chat-style assistants. It does not work for science. A scientific tool needs an environment, a prepare-step, persistent state between runs, validation, and a deploy path. Album was built around this lifecycle. Album-mcp exposes it.

The deepest reason album scales where Docker did not is that it is honest about lifecycle. A solution is not a binary; it is a contract over six lifecycle hooks. The contract is what makes things composable. The contract is what an agent can chain.

Axiom IV. Autonomy needs a brake.

A.IV. An agent that can install is interesting. An agent that can publish is dangerous. An agent that can publish behind 2FA is shippable. The brake is the product.

We have been sceptical of agent demos that claim to be autonomous and then turn out to delete files. This is not a hard problem to solve, but it is one we have solved deliberately: every destructive operation in album-mcp is gated behind a TOTP. install, run, uninstall, deploy, remove. The agent plans freely; it acts only with consent.

This is not security theatre. It is the precondition of enterprise adoption. It is also, we believe, the correct ethical default. Autonomy without a brake is not autonomy. It is just damage at speed.

Axiom V. Open source & a business, not one or the other.

A.V. Album is MIT and remains MIT. The company sells managed hosting, enterprise MCP, and the things organisations need that volunteer maintainers should not be asked to provide. The line is clear and we will hold it.

The framework is open source. The catalogs are open. The protocol is open. We sell hosted infrastructure (managed catalogs, enterprise album-mcp, audit logs, SSO, the SLA) to the organisations that want them. We do not sell the framework, and we will not.

This is not idealism; it is strategy. The catalog of scientific tooling is too important to depend on a single company's continued existence. By keeping the framework open, we make it impossible for our future selves to do the wrong thing. The brake is also pointed at us.

Closing. What we are building.

The next decade of scientific computing will be agentic. Agents will write the pipelines, run the analyses, file the results. The infrastructure layer that makes this possible (the layer of versioned, environment-isolated, MCP-callable scientific tools) will be either open and federated, or closed and owned. We are betting on the first.

Album is the framework. Album-mcp is the protocol. Fragmentum is the company that operates the seam between them. If you read this and recognise the world we are describing, write to us.

Filed in Berlin, 2026.
For investors, customers, and collaborators.
For anyone who reads this later. S. Proft & P. Albrecht