The extensible operations platform for humans and agents
Free core, source-available, and built for teams and agents
Too many tools. Too much SaaS spend. Too much Slack churn, handoff friction, and lost context.
Move Big Rocks gives your organisation one place for service catalog, forms, conversations, queues, cases, Markdown knowledge, milestone goals, workstreams, automation, and extensions. It is built for teams that are tired of paying for disconnected SaaS tools while their people and agents quietly accumulate critical context in local files, chat threads, one-off scripts, and giant ticket backlogs that still do not explain the real work.
The problem
Support, forms, docs, analytics, recruiting, internal requests, and operational glue end up split across SaaS tools that each charge real money, model work differently, and do not compose cleanly. The spend is annoying, but the fragmentation is worse.
The real operating memory is often stuck in Markdown files on hard drives, local prompt folders, ad hoc templates, and personal checklists. That helps individuals move, but it creates chaos for the team.
Claude Code, Codex, and other agents need stable interfaces, explicit permissions, and shared context. Most SaaS stacks were not designed for that. They force agents into brittle browser flows or disconnected side channels.
Product and delivery teams often explode meaningful goals into dozens of low-context tickets because the surrounding strategy, constraints, and relationships do not live in the same system as the work.
Why now
Teams do not need another layer of software theatre. They need a system that helps them move faster, gives agents real leverage, makes context legible, and turns operational discipline into a repeatable advantage.
When routing, forms, knowledge, and execution live in one system, teams spend less time translating work across tools and more time moving it forward.
Agents become dramatically more useful when they can operate against one deliberate contract instead of reverse-engineering five products and three hidden local folders.
Service catalog, concept-aware Markdown, milestone goals, and workstreams make it easier for humans and agents to understand what matters and why.
Queues, cases, conversations, review flows, and explicit ownership turn good intentions into dependable execution across teams.
The core
The free core is already a useful product. It gives your teams one place to classify work, collect what matters, handle live interactions, preserve durable follow-through, and maintain shared operational memory.
Define what work exists in the organisation so requests, conversations, knowledge, and ownership all line up around the same taxonomy.
Capture what must be known before work is accepted, approved, or escalated instead of letting every request arrive as an unstructured blob.
Handle live interactions in queues, keep conversations conversational when possible, and create durable cases only when real follow-through exists.
Store private, selectively shared, and workspace-visible knowledge with review, provenance, and explicit audience control.
Coordinate delivery around richer concepts with context, constraints, and linked work instead of pretending every meaningful step must be another ticket.
Trigger actions when operational events happen without building the whole product around hidden automations and opaque glue.
Let humans and agents operate the same system through one explicit CLI and GraphQL contract instead of parallel shadow workflows.
What it helps teams do
Keep campaign briefs, brand constraints, launch checklists, templates, prompts, and requests in one team-owned system instead of scattered docs.
Work conversations and cases with the right knowledge, form requirements, and routing context already attached.
Store runbooks, postmortems, constraints, change proposals, and internal services in the same system that tracks the work itself.
Use the same core for ATS-style workflows, interview kits, role application forms, and hiring operations rather than creating another disconnected stack.
Define milestone goals, workstreams, constraints, and strategic context in one place so agents and humans can execute without drowning in backlog ceremony.
Publish only the guidance other teams should rely on, keep drafts private, and preserve deliberate boundaries instead of flattening everything into one wiki.
Promote the right concepts into shared standards, templates, RFCs, and operating policies without losing their version history.
How the model works
A workspace is the logical and security boundary inside an instance. Teams own operational responsibility inside that boundary. Service catalog and topics classify work. Forms define what must be known before work is accepted, routed, or acted on. Under the hood, Move Big Rocks models that structured contract explicitly, but the user-facing concept is simple: better forms create better work. Queues hold queue items. Conversations handle live interactions. Cases exist when durable follow-through, ownership, approval, or SLA management is needed.
Operators should be able to triage conversations and cases together without collapsing them into the same object.
Work is classified deliberately so the right knowledge, form rules, and teams apply instead of relying on loose tags alone.
Structured form specs define what must be known before a team accepts or escalates work, which makes both humans and agents more reliable.
Escalating from conversation to case should preserve the source context, transcript, and audit trail.
Knowledge with structure
Move Big Rocks knowledge is Markdown-first, but not just a loose pile of docs. Versioned concept specs define the structure, workflow, and allowed audience for concept instances. Knowledge resources pin to an exact concept version and carry the actual access policy, review state, and revision history. The same system can hold purpose, goals, strategies, bets, OKRs, KPIs, milestone goals, and workstreams in agent-ready Markdown without turning the product into a disconnected planning suite.
Teams can keep private drafts, selectively share approved guidance with named teams, and publish workspace-wide standards.
Concept specs set default and maximum audience rules; each knowledge instance stores the actual audience and share targets.
Markdown, concept specs, templates, and publishable content can all use managed version history without forcing every user into raw Git workflows.
Humans and agents can check knowledge out locally, edit real files, diff changes, and sync them back through the same deliberate contract.
Goals, strategies, bets, OKRs, KPIs, milestone goals, and workstreams can live in the same concept system and link directly to queues, catalog nodes, forms, and work.
The Strategic Context Stack
Purpose, vision, mission, goals, strategy, bets, OKRs, and KPIs should not be interchangeable planning words. Move Big Rocks should help teams keep The Strategic Context Stack and the delivery layer in the same concept system as the work itself. That means milestone goals, workstreams, bets, constraints, RFCs, forms, queues, and cases can all relate to one another directly instead of living across separate tools.
Purpose, vision, mission, goals, strategy, bets, OKRs, and KPIs create the governing frame so milestone delivery is nested inside something coherent.
Milestone goals can define intended outcome, scope boundary, constraints, assumptions, and success signals instead of collapsing all of that into one vague epic.
Workstreams can group the concepts, queues, extensions, and owned work needed to reach an outcome without losing the thread across teams.
Cases and queue items still matter for interruptions, approvals, and durable ownership, but execution should be judged by net directional gain, state of proof, and whether drift is being introduced.
Markdown can link concepts and work with references like @milestone/agent-ergonomics-m1, @workstream/knowledge-runtime, @goal/customer-onboarding-quality, and @queue/support-inbox.
What it replaces
Ticketing without service catalog, forms, or team knowledge leaves operators guessing what kind of work they are really handling.
Forms that are not tied to classification, ownership, and follow-through create submissions, not better operations.
Backlogs full of shallow tickets still fail when the strategy, milestone goals, and constraints live somewhere else and agents cannot see the whole picture.
Docs and work tracking without explicit audience, review state, typed structure, or links back to real operations turn into fragmented Confluence and Jira sprawl.
Personal notes and prompts help one person today while making the team more dependent on hidden context tomorrow.
Teams keep building one-off tools because there is no shared extension runtime, knowledge layer, or queueing model to build on.
When agents operate outside the system of record, the organisation loses auditability, consistency, and trust.
Extension model
Move Big Rocks core gives you teams, queues, conversations, cases, concept-aware Markdown knowledge, forms, automation, and agent access. Extensions add product depth without forcing every customer into the same stack.
Extensions can own their own PostgreSQL schema for workflow state without polluting core.
Extensions can also use managed artifacts for websites, docs, templates, prompts, and publishable content.
Teams can author their own private extensions, register concept specs and commands, and test the pack in a sandbox before rolling it out.
Extensions publish pages and APIs through declared routes while Move Big Rocks keeps auth, audit, and trust boundaries.
Available now
The point of the packs is not to fragment the stack again. Each one should reuse the same teams, queues, knowledge, forms, artifacts, and extension runtime so the organisation stays legible as it grows.
Run hiring on the same operational base with role application forms, candidate workflows, interview kits, and careers-site publishing.
Capture site and product analytics without pushing the surrounding operational context into another separate tool first.
Bring runtime issues and engineering follow-through into the same queues, cases, knowledge, and extension system.
Add stronger identity and access patterns without inventing a disconnected admin universe around the product.
Build capability slices that are unique to your organisation, from internal service portals to public microsites and team workflow packs.
Build and deploy safely
A Move Big Rocks extension is a bounded product slice, not an ad hoc plugin.
It can own structured state in an ext_* schema, use managed
Git-backed artifacts for websites and templates, register skills and concept
specs, and move through a clean sandbox-first lifecycle.
Private extensions use the same model as first-party packs, so the build path and the trust model do not split apart.
Humans should be able to describe the operational slice they need and let an agent scaffold the manifest, assets, concepts, and runtime wiring.
Use mbr extensions deploy, validation, health, and monitored activation in a sandbox before you touch production.
Promote the proven pack into a self-hosted instance instead of improvising a second deployment path at the last minute.
Why CLI
The CLI is not there to be flashy. It is there so your team, your automations, and your agent hosts all have one stable, auditable, scriptable way to act.
Tell an agent “create me a Move Big Rocks sandbox” and it should be able to do the rest through mbr.
Check out team knowledge onto a filesystem when needed, edit Markdown, diff changes, and push deliberate updates back.
Agents should be able to read milestone goals, workstreams, constraints, and linked work directly from the same CLI and API instead of reconstructing them from scattered tickets.
CLI and GraphQL stay aligned, return machine-readable data, and avoid hidden browser-only semantics.
Agents that want a simpler public documentation surface can start with /site.md or /llms.txt before moving into the CLI and bootstrap flow.
Context, permissions, approvals, and audit stay in Move Big Rocks rather than vanishing into local scripts and chat logs.
Agentic ergonomics
Move Big Rocks is built so an external agent can install the CLI, create a sandbox, authenticate, import Markdown, review RFCs, understand milestone goals and workstreams, operate queues, and develop extensions through one explicit contract.
mbr from machine-readable release metadata.Sandbox in minutes
Spin up a disposable sandbox with seeded demo data and use the same CLI and GraphQL model as a real deployment.
Trial web analytics, ATS, error tracking, and enterprise access in sandbox mode before committing to production.
Keep the evaluation going for another 30 days without turning the product into a generic hosted SaaS.
Take your data, Markdown knowledge, and configuration with you when you move into a real instance.
One instruction to your agent. One CLI flow. One URL when it’s ready.
mbr sandboxes create --email you@company.com --jsonSelf-host when it matters
The sandbox is for evaluation. Production is self-hosted, team-aware, and designed around a customer-controlled instance repo, clear trust boundaries, and a runtime that does not depend on hidden vendor magic. The point is not to trap you in a hosted trial. It is to let you learn quickly, export cleanly, and move into a real deployment when you are ready.
Bring conversations, knowledge, forms, strategic context, and durable work into the same system.
Support private team knowledge and deliberate sharing without flattening everything into one noisy wiki.
Let agents help where they’re useful while keeping approvals, policy, and system-of-record data under control.
Give teams richer milestone and workstream context so they can execute with fewer throwaway tickets and less translation overhead.
Commercial shape
Self-host the platform, operate with teams and agents, and use the base primitives without paying for empty categories.
Buy focused first-party extensions when you need ATS, web analytics, error tracking, enterprise access, or other depth.
Use Move Big Rocks services for sandbox onboarding, production setup, team knowledge migration, and custom extension work.
Move Big Rocks
If your organisation already has work in inboxes, Markdown on laptops, prompts in chat, and agents doing useful but invisible things, this is the moment to give that energy one deliberate home.