Core shared base

One shared operational model that replaces dozens of disconnected SaaS tools.

Move Big Rocks core gives teams and agents one shared base for workspaces, teams, forms, queues, conversations, cases, knowledge, automation, and audit. It also turns private Markdown, concepts structured by specs, prompts, and operating context into controlled workspace surfaces that people and agents can use without exposing the source artifacts by default. Out of the box, that is already enough to replace a surprising amount of SaaS sprawl, including many approval flows, purchase requisitions, and spreadsheety internal workflows through workspace configuration alone before custom extensions enter the picture.

See the agent bootstrap See 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

Shared boundaries

Identity, ownership, permissions, and audit stay shared across the system.

Shared work model

Forms, queues, conversations, and cases handle intake, routing, interaction, and durable follow-through.

Configured workflows before code

Many approvals, requisitions, and spreadsheet-like internal processes can be implemented with forms, cases, queues, teams, and automation without building a custom extension first.

Shared memory

Knowledge keeps policies, context, structured Markdown, and concept-aware operating memory available to the same humans and agents doing the work without defaulting to raw file sharing.

Shared automation surface

Automation works on explicit records and event flows instead of hidden side channels.

Table of contents

Section map.

Jump directly to the part you need.

The core defines the shared operational model reused across workflows and extensions. System model Each primitive exists to remove a specific failure mode in fragmented operations. Why these primitives exist Each primitive exists because it connects to the others. Primitives and relationships The shared base is already enough to replace a lot of fragmented operational tooling. Examples A deployment boundary is not the same thing as an operational boundary. Why a shared base matters

System model

The core defines the shared operational model reused across workflows and extensions.

The core exists so each new workflow does not need its own separate permissions model, queue model, knowledge silo, or private operating context. Many internal processes are configuration problems on the shared base, not extension problems.

Workspaces and teams

Use workspaces and teams to define durable ownership and security boundaries across workflows.

Forms and intake

Use forms to collect what must be known before work becomes real, routable, and reviewable.

Queues, conversations, and cases

Use queues for work in motion, conversations for live interaction, and cases for durable follow-through.

Knowledge and automation

Keep policy, guidance, and automation close to the work they govern instead of scattering them across separate systems.

Why these primitives exist

Each primitive exists to remove a specific failure mode in fragmented operations.

The primitives are not arbitrary nouns. They are the smallest stable set that keeps security, ownership, intake, execution, knowledge, and follow-through legible to both humans and agents.

Proof bundle

Definition README.md Enumerates workspaces, teams, forms, queues, conversations, cases, knowledge, automation, and agent access.
Definition START_WITH_AN_AGENT.md Lists the public primitive set agents should use before inventing new abstractions.
Implementation docs/ARCHITECTURE.md Defines the core domains and relationships between queues, conversations, cases, knowledge, and automation.
Implementation migrations/postgres/README.md Shows the durable core database layout and ownership-aligned migration baseline behind the shared model.

Workspaces

A workspace exists because a real system needs a durable security and tenancy boundary, not just a loose tag.

Teams

A team exists because operational ownership, SLAs, routing, and approvals need a first-class boundary inside a workspace.

Forms

A form exists because intake should be a structured contract before work becomes real, not a half-parsed email or chat message.

Queues

A queue exists because teams need one visible work bucket for routing and triage, even when the underlying item is a conversation or a case.

Conversations and cases

The model keeps live interaction and durable work separate on purpose, so one does not collapse the other into a shallow ticket.

Knowledge

Knowledge exists because policy, runbooks, prompts, templates, and concept-driven context should live in the same system as the work they govern, with explicit audience control instead of loose folder sharing.

Automation and events

Automation exists because follow-through should act on explicit records and typed events instead of hidden scripts and side channels.

Primitives and relationships

Each primitive exists because it connects to the others.

The value is not any single primitive in isolation. The value is the way they reinforce each other under one model.

Forms connect to queues

Structured intake makes routing deliberate instead of leaving humans and agents to guess.

Queues connect to conversations and cases

Work can begin as live interaction, durable casework, or both without collapsing into one shallow record type.

Knowledge connects to work

Runbooks, policies, templates, and shared context remain available at the point of execution.

Automation connects to explicit records

Automations act on visible state and produce visible follow-through.

Audit connects to everything important

Approvals, routing changes, and production operations remain visible instead of being buried in scripts.

Examples

The shared base is already enough to replace a lot of fragmented operational tooling.

Even before custom extensions, the core is strong enough to replace many disconnected combinations of service desks, forms, inboxes, docs, lightweight tickets, glue automation, and spreadsheet-driven internal workflows.

Service desks and internal requests

Out of the box, forms, queues, conversations, and cases are already strong enough to replace a surprising amount of what teams otherwise spread across Zendesk, ServiceNow, email, and spreadsheets.

Form and intake systems

Structured forms and downstream routing can replace Formstack-style intake without leaving follow-through in a different tool.

Approvals and requisitions

Many approval flows, purchase requisitions, and spreadsheety operational processes can be handled with workspace configuration on forms, cases, queues, teams, and automation rather than a new extension.

Operational knowledge hubs

Keep team knowledge, policies, templates, and runbooks connected to the work they drive instead of splitting them across docs and tickets.

Internal portals and agent surfaces

Create internal portals and controlled agent-facing surfaces without standing up a separate app stack.

Private knowledge, usable safely

Turn proprietary Markdown, concept instances, prompts, and operating context into controlled workspace surfaces that people and agents can use without exposing the whole source tree by default.

Why a shared base matters

A deployment boundary is not the same thing as an operational boundary.

Move Big Rocks preserves the brand's anti-fragmentation thesis, but makes it concrete: the core exists because you should not rebuild auth, routing, audit, work records, and shared memory around every new tool or extension.

Shared boundaries are the prerequisite for safe agent leverage.
Shared knowledge and durable records are what make handoffs and approvals legible.
Many internal workflows should be configured on the shared base before anyone reaches for extension code.
Bounded extensions matter because the core is already strong and shared.

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