One day with Obsidian MCP — coordinating my agents and experimenting with papers

Today my Obsidian vault was not just a notebook. It was the shared desk for a collection of Cursor agents working across my projects—and the filing system that finally made my paper work manageable.

I used obsidian-mcp throughout the day. Agents opened project context, selected bounded work, recorded decisions, updated status, and left session handoffs for the next agent. At the same time, research agents used the same vault to turn a loose experiment in documenting my projects as papers into seven organized manuscript tracks with evidence, references, metadata, and publication boundaries.

The result was not one giant chat. It was many focused sessions sharing durable Markdown.

The vault was the common layer

Each project has a small set of files that both I and the agents can read:

Project State.md          objective, current state, active work, next steps
Sessions/2026-09-11.md    what each agent changed and where it stopped
Decisions/2026-09-11-*.md why an engineering choice should survive the chat
TODO/*.md                 work that can be selected and tracked

Before substantial work, an agent calls get_project_context. That returns the current brief plus recent sessions and decisions. It does not require loading the whole vault or finding the right old chat.

After meaningful work, capture_work_session appends a summary with the repository, branch, commit, changed-file summary, decisions, and next steps. When an engineering choice needs to stick, record_decision gives it a separate note. When I need to understand why a boundary exists, search_memory finds the earlier reasoning.

The task tools make the vault operational. Agents can list_open_tasks, claim_task, complete_task, block_task, and unblock_task. A task moves through the workflow without reconstructing the entire Project State file. Ambiguous matches fail instead of moving the wrong item.

What the agents worked on today

The session notes show how broad the day was. Different agents worked on different repositories, but they used the same memory pattern.

• SDLC-SPDD orchestrator: agents tightened verification receipts, review scope, installer behavior, CI evidence, and quality-gate honesty. The vault preserved why a real validation receipt counts and why a skipped live graph cannot be reported as proof.
• Uberorchbot: agents added plugin and CI guardrails around the Obsidian work queue, skill catalogs, the archived control plane, and repository allowlists. The durable state kept the product on its Cursor plugin and Automations path instead of reviving an abandoned Spring control plane.
• obsidian-mcp: the memory system improved from its own usage. Agents hardened task claiming, queue synchronization, cross-source matching, read-path redaction, and CI. Problems discovered while coordinating agents became focused improvements to the coordinator.
• slm-setup: agents worked through local-model runtime safety, token-cap behavior, CI checks, official model tags, and harder evaluation jobs. Decisions recorded which conditions fail, warn, or require a live operator run.
• documentation-generator: agents closed gaps in visual-sync validation, timestamps, scene specs, audio and LFS checks, scene compilation, and composition. The notes kept each fail-closed change separate instead of turning the work into one unbounded repair session.
• memory-os and embabel-v1-learning: agents strengthened evaluation, timeline handling, dependency-pin checks, Pages validation, and publishing safeguards without rebuilding media that was outside the task.
• chatbot: agents worked on structural citation checks, channel CI, GraphRAG testing, opt-in smoke assertions, and the boundary with the commerce product.
• open-commerce-platform: agents recorded checkout, reservation, payment reconciliation, runtime topology, ratings-goal, and playbook-rematching decisions so later sessions do not re-argue the same product contracts.
• cdk-cost-killer: agents kept infrastructure cleanup safe by preserving dry-run defaults, skipped bootstrap resources, stack-name boundaries, and the rule that CI never performs a live apply.
• Guide-related work: agents preserved fork-local rules, pin and tag discipline, and CI checks without turning the work into an upstream contribution path.
• Fleet review: the vault recorded the selected inspection tools and their roles instead of leaving that choice buried in an evaluation chat.

This is what using Obsidian MCP across agents looked like in practice: retrieve a narrow brief, do one bounded piece of work, record the durable choice, and leave the repository in a state the next session can understand.

Then there was the paper work

The paper organization was not a side note. It was one of the largest uses of the vault today.

I had a broad set of repositories that might become technical papers. Without a durable structure, every research session could generate another outline, another reference list, or another publication idea without agreeing on what the actual papers were.

The vault turned that into an organized documentation experiment. I am exploring whether a paper-style structure can explain the purpose, design, evidence, and limitations of my work more rigorously than ordinary project notes. I am not claiming that these are finished academic papers or committing to publish them.

The experiment currently has seven applicable tracks: P01–P05, P07, and P08. They cover the SDLC-SPDD orchestrator, Uberorchbot, the local coding SLM, memoryOS, documentation-generator, open-commerce-platform, and chatbot.

Eight other candidates—P06 and P09–P15—were explicitly removed because they were not appropriate paper projects. That decision is as important as creating the seven remaining tracks. It prevents a future agent from seeing an old idea and rebuilding an inapplicable manuscript pack.

Each active paper track now has a repeatable set of artifacts:

• a repository purpose and architecture baseline taken from committed code;
• an outline and working manuscript draft;
• an evidence pack tied to exact repository snapshots;
• a prior-art review and structured bibliography;
• results and claim-support records;
• normalized metadata;
• a deposit sheet that remains preparation, not permission to publish.

Shared research tasks handled the administrative questions once for all seven tracks: the intersection of Zenodo and TechRxiv rules, manuscript scope, PDF format, metadata fields, DOI ordering, AI disclosure, authorship, and the boundary between a software record and a preprint.

One normalized manuscript guide now says that the abstract must agree everywhere—the draft, metadata, and deposit sheet. A shared YAML schema maps fields to both venues. References use stable IDs before print numbers are assigned. Research notes distinguish official sources from open questions.

This is documentation research, not a publication commitment. The agents organize evidence and draft paper-style artifacts. Creator identity, ORCID, technical claim approval, final prose review, PDF approval, DOI creation, and any deposit remain human-controlled. Today’s work was an experiment in documenting the projects; it was not an automated submission run.

That distinction would be easy to lose in chat. In the vault it is part of the project state and decision history. Every agent sees the same boundary.

How this helped me use my plan

Organizing the work also helped me use the model capacity already included in my Cursor plan. Instead of leaving quota unused because I could not keep enough work straight, I had a queue of legitimate, scoped tasks that different agents could execute.

Standard and Auto capacity could take bounded documentation, testing, and guardrail work. Premium capacity could take harder implementation, architecture, review, and research synthesis. The vault made it possible to keep those sessions moving and use the plan productively without relying on one chat to remember the entire lab.

Obsidian also kept the token burn from becoming busywork. If a task was inapplicable, I removed it. If a decision required a human, the agent stopped at the boundary. If the queue was empty, the correct action was to stop—not invent another project merely to consume quota.

What changed for me

Before this workflow, chats were where work happened and where context disappeared. Today, chats were workers. The vault was the durable system.

I could move between software hardening, agent tooling, local models, commerce, documentation video, infrastructure safety, and research because every project had a current brief and every meaningful session left a handoff. I could also open Obsidian and see the paper experiment as a set of linked documentation artifacts instead of a pile of manuscript ideas.

That is the practical value of Obsidian MCP for me: it helped many agents work as part of one day, helped me use the AI capacity I was already paying for, and organized both engineering work and literal paper work in files I can still read after every chat is gone.

Source: github.com/jmjava/obsidian-mcp
Related: Uberorchbot · SDLC-SPDD orchestrator · local coding SLM setup