See Minolith in action
A real workflow showing how Claude Code uses Minolith to remember, plan, and ship — across sessions and devices.
Setup
Getting connected takes three steps and about 60 seconds.
Create a project
Sign up at app.minolith.io, name your project, and copy the API key from the dashboard. No card required during the 14-day trial.
// Your project API key (from the dashboard) "api_key": "mlth_af4bba39d145416be4d831fcf4eda648" // This single key authenticates across all services: // Context, Changelog, Feedback, Runbooks, Agents, Tasks, Bootstrap
Add the MCP server
One command connects your AI coding tool to Minolith. No npm packages, no Docker, no local server. HTTP transport over HTTPS.
$ cd /your/project $ claude mcp add --transport http minolith https://mcp.minolith.io \ --header "Authorization: Bearer mlth_af4b...eda648" \ --header "X-Minolith-Agent: orchestrator" Added minolith (http transport) to your MCP servers.
Create your agent definition
Define who your agent is, what tools it can use, and what context it should load at startup. This definition is stored on Minolith and loaded via bootstrap at every session start.
> Create an orchestrator agent for this project ⏺ minolith - create_agent (MCP) (name: "orchestrator", role: "Senior developer and project orchestrator", tools_allowed: ["file_read", "file_write", "bash", "mcp:minolith"], context_requirements: [{"priority": "high"}]) Agent agt_7f3a9b2c4d1e created successfully. ⏺ Done. Your orchestrator agent is set up. It will load high-priority context automatically at session start via bootstrap.
Session Start
Bootstrap loads everything your agent needs in a single call.
One API call at session start loads your agent's identity, project rules, recent deployments, active runbook runs, and suggested follow-ups. The agent starts every session with full project awareness.
> Let's work on the project ⏺ minolith - bootstrap (MCP) Agent: orchestrator Role: Senior developer and project orchestrator Session instructions (3): • Deploy immediately after completing changes • Session start workflow — mandatory steps before any work • Communication style: concise, direct, technical High-priority context (5 entries): • [rule] All CSS must be in external files • [rule] Zero code duplication — platform code is shared • [warning] CSP header requires updating when adding external resources • [decision] Documentation system — database-driven with dual output • [pattern] form_field() helper prevents variable bleed Assigned tasks (2 open): • [normal] Fix pricing calculator on website • [high] Update MCP example with agent header Active runbook runs: 0 Open feedback: 9 items (0 high priority) Recent events: • Dark mode deployed — 2 hours ago • Security audit remediation — 5 hours ago Subagents: code-reviewer, docs-updater, security-auditor, ui-designer ⏺ I've loaded the project context. 5 high-priority entries, no active runbooks, 9 open feedback items. What would you like to work on?
The agent now knows its role, the project's rules and warnings, its assigned tasks, that there are 9 open feedback items, and what was deployed recently. All from one call.
During Work
Storing knowledge as you go.
While working on a CSS change, the agent discovers a project pattern. It stores the knowledge so every future session — and every other agent on the project — knows the rule.
> Remember that we always use the form_field() helper, never call the partial directly ⏺ minolith - store_context (MCP) (type: "rule", title: "Use form_field() helper for all form fields", body: "Never call view('partials/form_field') directly. Always use the form_field() helper to prevent CI4 variable bleed between consecutive view calls.", tags: ["forms", "helpers", "ci4"], priority: "high") Context entry ctx_2f27a262768e created successfully. ⏺ Stored as a high-priority rule. This will be loaded in every future session.
Three weeks later, a different agent starts a new session and needs to work on the frontend. It queries for CSS rules.
> What are the rules for form fields in this project? ⏺ minolith - get_context (MCP) (type: ["rule"], tags: ["forms"]) 1 entry found: • [rule, high] Use form_field() helper for all form fields "Never call view('partials/form_field') directly. Always use the form_field() helper to prevent CI4 variable bleed..." ⏺ There's one rule: always use the form_field() helper function instead of calling the partial directly. This prevents CI4's variable bleed issue between consecutive view() calls.
Knowledge stored in one session is available in every future session. Rules, patterns, decisions, and warnings accumulate into a living knowledge base that every agent on the project can access.
Shipping a Feature
Changelog entries and event logs, written by the agent as it ships.
The agent finishes implementing dark mode. Before moving on, it logs the change for users and records the deployment for future sessions.
> Log this dark mode feature in the changelog ⏺ minolith - create_changelog_entry (MCP) (title: "Dark mode support", body: "Users can now toggle between light and dark themes in dashboard Settings. Persists across sessions.", category: "feature") Changelog entry ent_7f3a9b2c4d1e created (draft). 3 credits. ⏺ minolith - log_event (MCP) (title: "Dark mode deployed to production", body: "Theme toggle in Settings, CSS custom properties for both themes, preference stored in account.", tags: ["deployment", "frontend", "dark-mode"]) Event ctx_5650551e6b81 logged. ⏺ Done — changelog entry created as a draft and deployment event logged. You can publish the changelog entry when you're ready to make it visible to users.
Your agent documents what it ships as it ships it. The changelog entry is published to a hosted page your users can see at changelog.minolith.io. The event is logged on the project timeline for future sessions to reference.
Following a Procedure
Runbooks ensure every deployment follows the same steps, every time.
The agent is mid-deployment. It checks the current step, completes it, and advances to the next one. If the session ends unexpectedly, the next session picks up from exactly this point.
> Start the production deployment runbook ⏺ minolith - start_run (MCP) (runbook_id: "rnb_8c4e2a1b6f3d", variables: {version: "1.4.0", environment: "production"}) Run run_3f9a7b2c4d1e started. Step 1 of 5. ⏺ minolith - get_current_step (MCP) Step 1/5: "Run test suite" (type: check) Instruction: Run the full test suite and verify all tests pass before proceeding with deployment. ⏺ Running the test suite now... [tests pass] ⏺ minolith - advance_step (MCP) (outcome: "pass", notes: "All 47 tests passed in 12.3s") Step 1 completed. Moving to step 2/5: "Deploy to staging" ⏺ Tests passed. Moving on to staging deployment.
Runbooks ensure every deployment follows the same procedure. If the agent is interrupted mid-runbook, it calls get_current_step at the next session start and picks up exactly where it left off.
Collecting User Feedback
Users submit feedback. Your agent reads it and acts on it.
Users submit feedback through the embeddable widget on your site — bug reports, feature requests, questions. Your agent queries the inbox via MCP and triages it without any human relay.
> Are there any new bug reports from users? ⏺ minolith - list_feedback (MCP) (status: "new", type: "bug") 2 items found: • [fbk_9a3b7c2d4e1f] "Search is slow on large datasets" by Alice Chen — 3 hours ago — normal priority • [fbk_2c4d6e8f0a1b] "Dark mode flickers on page load" by James Park — 1 hour ago — normal priority ⏺ Two new bug reports. The dark mode flicker sounds related to our recent deployment. Want me to look into that one first? > Yes, and mark it as planned ⏺ minolith - update_feedback_status (MCP) (id: "fbk_2c4d6e8f0a1b", status: "planned", priority: "high") Feedback item updated: planned, high priority. ⏺ Marked as planned with high priority. Let me investigate the flicker issue...
Users submit feedback through the widget on your site. Your agent reads it via MCP and factors it into its work — no human relay needed.
Task Management
Assign work to agents and track progress across sessions.
Create tasks from the dashboard or API and assign them to agents or team members. Agents pick up their assigned tasks at session start via bootstrap, work through them, and update status as they go.
> What tasks are assigned to you? ⏺ minolith - get_my_tasks (MCP) 2 open tasks: • [tsk_b04700be2d53] "Fix about page service cards" — normal • [tsk_00a41cb007e6] "Add Tasks to pricing calculator" — normal Workflow: open → review → done ⏺ I have 2 open tasks. Let me work through them. [agent completes both tasks] ⏺ minolith - bulk_add_notes (MCP) (notes: [ {task_id: "tsk_b04700be2d53", body: "Fixed grid layout, moved Tasks card inside grid"}, {task_id: "tsk_00a41cb007e6", body: "Added Tasks slider to pricing calculator"} ]) 2 notes created. ⏺ minolith - bulk_update_status (MCP) (updates: [ {task_id: "tsk_b04700be2d53", status: "review"}, {task_id: "tsk_00a41cb007e6", status: "review"} ]) 2 tasks updated to review. ⏺ Both tasks completed and moved to review. Notes added with what was done.
The developer reviews the work in the dashboard, approves both, and drags them to Done. Next session, the agent's bootstrap shows no open tasks — the board is clear.
What happens next?
Your agents build a compounding knowledge base. Every session makes the next one better.
Ready to give your agents a memory?
14-day free trial with 500 credits. No card required.