Worldview

SaaS sprawl was already broken. AI makes it worse. One shared system is the answer.

Every SaaS tool you add is another vendor with access to your data, another silo of context, another integration to maintain, and another tool that becomes a zombie when its champion leaves. AI agents cannot reason coherently across dozens of disconnected systems. The product can be understood without this page. The worldview matters after the system is already clear.

Return to the core model Read first replacement targets

Agent-first route: Start at /agents, inspect /docs/cli, and drop into this page when you need proof, detail, or rollout guidance.

Agent-first route

Humans should usually delegate first-pass evaluation to an agent. Agents should start at /agents, use /docs/cli as the official product tour, and open /docs/graphql only when needed.

Agent-ready surface

Start with the CLI, not browser guesswork.

Preferred route: /agents, then /docs/cli, then /docs/graphql only when lower-level integration details matter.

$ mbr spec export --json
$ mbr auth whoami --json
$ mbr queues list --workspace ws_preview --json

Open GraphQL reference | Open schema.graphql

Against fragmentation

The problem is not only too many tools. It is too many hidden operating models.

For shared boundaries

Operational boundaries should be shared even when products and workflows differ.

For visible context

Agents are safer and more useful when context is durable, shared, and human-visible.

Read after product definition

The worldview matters most after the product, primitives, and deployment model are already clear.

Table of contents

Section map.

Jump directly to the part you need.

Cheaper software creation makes operational fragmentation more dangerous, not less. Why app sprawl is still the problem A new container or new app does not justify a new operational world. Why boundaries should be shared Philosophy supports evaluation; it does not replace product definition. Further reading

Why app sprawl is still the problem

Cheaper software creation makes operational fragmentation more dangerous, not less.

Teams can now build or buy software more quickly than ever. That is good. It also means fragmented operational context appears faster than before unless the boundaries remain shared.

Faster tool creation means faster app sprawl unless the operational model is shared.
Agent workflows become dangerous when they depend on private files, hidden prompts, or fragile browser steps.
Organizations still need visible ownership, approvals, routing, durable context, and audit.

Why boundaries should be shared

A new container or new app does not justify a new operational world.

Operational software can vary by domain while still sharing the same workspaces, teams, work records, knowledge, audit, and human responsibilities.

Shared memory

Context should survive agent sessions, personnel changes, and tool boundaries.

Shared work records

Operational follow-through should not splinter across separate tickets, inboxes, and private notes.

Shared trust model

Permissions, audit, and production responsibility should not be reinvented for every slice.

Shared leverage

Humans and agents become more useful when they can work against one visible system instead of many hidden ones.

Philosophy supports evaluation; it does not replace product definition.

The worldview should help explain the product. It should not force the reader to guess what the product actually is.

References

Canonical next surfaces.

Each link goes to the next authoritative page, reference, or support surface.

Let agents inspect the CLI-first surface. Let humans decide trust, rollout, and boundaries.

Start from /agents, use /docs/cli as the official product tour, inspect /resources for source and proof, and review /security before making deployment or data-handling decisions.

Open /agents Open resources