A Client Mentioned Obsidian, and OFM Changed Direction

This week, a client we are helping with an ERP project said something that sounded casual at first: “I use Obsidian with Visual Studio Code.”

The sentence described much more than a pair of tools. It described where this person already thinks, plans, stores context, and returns when a project becomes complicated. The ERP work was happening in one place, the code in another, and the long-term notes somewhere they had chosen deliberately.

That was the moment the question changed for us. It was no longer, “Should OFM have its own memory?” It became, “How can OFM fit into a workflow that already has a trusted memory?”

The wrong answer would have been to ask for a fresh start

New software often arrives with an invisible request: move your knowledge here, change your habits, and trust that the new place will eventually become home.

That request is especially expensive when the knowledge is connected to real work. Notes are not just documents. They contain decisions, unfinished thoughts, references, and the small pieces of context that make a project understandable weeks later.

Our client was not asking for another place to write notes. They were showing us the system they already used to make the work manageable.

We could have treated that as an edge case. Instead, it exposed a more important principle: an AI workspace should not become useful by making the rest of someone's workflow disposable.

The decision to connect instead of copy

So we integrated Obsidian into OFM. The goal was not to absorb the vault or create a second, competing version of it. The goal was to let an agent work with the live knowledge the person had already decided to keep.

That distinction matters. Copying knowledge can create doubt about which version is current. Connecting to the source keeps ownership and responsibility clearer. The person can continue using Obsidian as the place where their knowledge lives, while OFM gives the active AI work a way to reach the relevant context.

The feature came from a very practical conversation, not from an abstract roadmap exercise. Someone showed us how their work actually fit together, and the product had to respond to the reality in front of us.

Why this is bigger than one integration

The lesson is not that every tool should be connected to every other tool. That creates its own kind of noise. The lesson is that product decisions become better when they begin with the user's existing habits instead of a blank screen.

People have already built ways to think. They have folders, notes, references, and rituals that carry meaning. An AI product that respects that work can become part of the system. An AI product that ignores it asks the person to pay the migration cost before they can feel any benefit.

The question we are taking forward

The Obsidian connection is now part of OFM's story, but the larger work is still ahead: making connected knowledge feel clear, intentional, and safe in everyday use.

The client gave us the trigger. The product still has to earn the trust that comes with touching someone's working memory. That is a much better problem to have than designing in isolation.

The sentence was short, the context was not

The client did not arrive with a feature request written in product language. There was no roadmap label, no formal specification, and no demand to recreate an existing tool inside OFM.

There was simply a description of how the work already happened: an ERP project, Visual Studio Code, and Obsidian as part of the everyday system around it.

That kind of sentence is easy to underestimate. It can sound like background information, something to acknowledge before returning to the “real” requirements. In practice, it can reveal more than a list of requested features. It shows what a person already trusts enough to include in the workday.

For us, the important part was not the brand name of the note-taking application. It was the role it played. Obsidian was already part of the client's way of making the project understandable.

Every project has a memory before software arrives

When a project becomes complicated, people create ways to hold it together. They write notes. They keep links. They record decisions. They collect questions that are not ready to become tasks. They return to older explanations when the current problem turns out to be connected to something that happened earlier.

This memory can be informal, but it is not unimportant. It is often where the difference between “we discussed this” and “we decided this” is preserved.

The client had already made a choice about where that memory should live. That choice was part of the project, even if it did not appear in the ERP requirements.

An AI workspace that ignored it would have been asking the client to split the project into two versions: the version that existed in their trusted notes and the version that existed in the new product.

That is a high price for an integration to impose.

The temptation to rebuild the familiar

When a product team sees a useful external workflow, the natural temptation is to reproduce it. Build a similar note area. Add a new memory panel. Give the user a place to import everything. Make the experience feel complete without leaving the product.

There is a logic to that approach. A self-contained product can appear easier to support. It can offer one visual language and one set of controls. It can avoid depending on another tool's habits.

But completeness is not always the same as usefulness. A person may not need another place to store knowledge. They may need the tools they already use to stop being isolated from the work they are doing with AI.

We had to resist the idea that OFM would become more valuable by making Obsidian unnecessary.

The decision was to connect, not compete

The decision that followed was straightforward to state: OFM should connect with the knowledge the client already trusts instead of asking them to migrate it into a second system.

That decision preserves something important. The client remains the owner of the vault and of the way it is organised. OFM can become part of the active workflow without claiming that it should replace the place where the knowledge was built.

This is a different relationship from importing. Importing suggests that the source is temporary and the new product is the destination. Connecting suggests that the source remains meaningful and the new product knows how to work alongside it.

The difference is not only technical. It changes the feeling of adoption. The person is not starting over. They are extending a workflow they already understand.

What the client was really teaching us

The client was teaching us that product boundaries are visible from the user's side. We may think of OFM as a command centre for AI work, but the client experiences it in relation to everything else that makes the work possible.

The notes are part of the work. The editor is part of the work. The conversations with an agent are part of the work. The ERP is part of the work. None of these pieces become irrelevant because a new tool has been introduced.

This is a useful correction for any product team. The product is rarely the whole environment. It is a participant in an environment that already exists.

The best integration is often the one that respects that fact.

The boundaries mattered as much as the feature

Connecting to an external knowledge source can sound exciting until the questions become practical. What can be read? What can be changed? Who decides? What happens if the source and the active project disagree? How does a person know which information came from where?

We do not need to reveal the internal mechanics to take these questions seriously. They are part of the user experience.

The client should not have to wonder whether the connection has silently copied an entire vault somewhere else. They should not have to guess whether a note was changed by an agent. They should be able to understand that the external knowledge remains distinct from OFM's own project memory.

That separation gives the integration a clearer promise. OFM can work with the context, while the client remains able to see where the context lives.

Clarity is a feature here.

Why this matters for an ERP project

An ERP project is not just a collection of screens and workflows. It carries business rules, decisions, exceptions, and conversations about how the organisation actually works.

That kind of project creates knowledge faster than a formal specification can capture it. A decision may begin in a meeting, become a note, influence a design, and return later as a question from an agent. The project needs a way to preserve the connection between those moments.

The client did not need OFM to become the owner of all that knowledge. They needed the active work to be able to reach the knowledge when it mattered.

That is why the anecdote feels bigger than a single integration. It shows the kind of environment in which AI will actually be used: not a blank workspace, but a living project with history.

The moment a roadmap becomes a conversation

Roadmaps are usually written in categories. Memory. Integrations. Sessions. Knowledge. A real conversation does not arrive in categories. It arrives as a person explaining how they got through their day.

That explanation can rearrange the categories.

Before the conversation, it would have been possible to think about Obsidian as an optional addition. After the conversation, it became evidence that the product's understanding of work was incomplete. The question was no longer whether the feature looked attractive in a list. The question was whether OFM could meet a user inside the workflow they already relied on.

This is one of the reasons we want to build in public. A product history written only as releases hides the moments that changed the questions. The meaningful turning points are often ordinary sentences from real work.

What we did not build in that moment

We did not decide to copy every note into OFM. We did not decide that the client's existing system should disappear. We did not claim that one integration solves the whole problem of project knowledge.

Those non-decisions are part of the story. They define the relationship we want with users and with the tools they have chosen.

A product can grow by adding capabilities while still becoming smaller in its assumptions. It can say, “We can work with your way of doing things,” instead of, “Your way of doing things must now become ours.”

That is the kind of growth we want to encourage.

The connection changes the starting point of a session

Without connected knowledge, a new session begins with a request for context. The person has to decide what to paste, what to summarise, and what to leave out. That preparation is sometimes necessary, but it can also become a repeated tax on every conversation.

With a trusted source available, the starting point can be different. The agent can work from the project's existing context, while the person remains able to decide what is relevant to the current task.

This does not mean that every session should read everything. It means that the person no longer has to act as the only bridge between the project and the tool. The knowledge can remain where it belongs and still become useful when the work calls for it.

That is a modest description, but modesty is important here. The value is not magic access. The value is less repeated explanation and a clearer relationship with the source.

What trust asks from us next

The first part of the work was recognising the need and making the connection possible. The next part is earning the trust that comes with it.

People need to know what the connection can do. They need guidance that assumes they care about privacy and control, not only speed. They need language that distinguishes a live external vault from OFM's own local project memory.

They also need a way to recover when something feels unclear. If a note is missing, if a connection is unavailable, or if a result does not reflect the knowledge the person expected, the product should help explain the situation rather than leaving them to guess.

Trust grows through ordinary moments. A clear setting. An understandable error. A visible boundary. A workflow that does what it says without asking for more authority than necessary.

The lesson about listening

Listening to users is often described as a research activity. In this case, it was a product decision.

The client did not ask us to copy Obsidian. They gave us a clue about the system in which OFM would have to live. Taking that clue seriously changed the direction of the work.

This is why listening cannot mean collecting feature requests and counting them. It means noticing the assumptions inside a person's description. What do they already trust? What are they protecting? What would they refuse to rebuild? What part of the workflow is invisible until something interrupts it?

The answers may not arrive as a neat request. They may arrive in one sentence during a conversation about something else.

The product team has to be ready to recognise the sentence.

From one client to a broader principle

We should not generalise one client's workflow into a rule for everyone. Different people organise knowledge differently, and no single tool deserves to become mandatory for every project.

But we can take the principle seriously. People bring existing systems of thought to new AI tools. Those systems may include notes, files, conversations, bookmarks, documents, or habits that are not visible from the product's interface.

The more advanced the user, the more likely it is that a meaningful workflow already exists. An AI product that wants to serve those users has to respect the work that came before the login screen.

That does not mean connecting everything. It means beginning with curiosity instead of assuming the product is the user's first serious tool.

The story is still open

The Obsidian connection is a release, but the reason it exists is an ongoing conversation. A user showed us a workflow. We changed the product so that the workflow could remain intact. Now the product has to prove that the connection is useful in the daily reality that inspired it.

There will be more questions. How should people organise connected knowledge? When should an agent use it? How should a user keep boundaries between personal notes and project decisions? How do we make the experience approachable without hiding its implications?

We do not have to pretend that these questions are already solved. They are part of the next chapter.

What we are carrying forward

The most important part of the story is not that OFM added an Obsidian connection. It is that a real workflow changed the product's centre of attention.

The client did not need another place to begin. They needed the new tool to respect where the work already lived.

That is a useful standard for the rest of OFM. Build around the user's real environment. Treat existing knowledge as an asset, not an obstacle. Let a product become part of an adventure that has already started.

The next time someone tells us how they work, we will try to listen for the sentence that changes the question.

The value of the existing workflow

There is a practical reason to respect an existing workflow: people have already paid for it with attention. They know where things are. They know how to name a note, how to find a decision, and how to recognise the difference between an idea and a commitment.

That knowledge is not transferable just because another product has a cleaner onboarding screen. A new tool may be easier to understand in isolation while still being harder to use inside the person's real life.

The client's sentence reminded us that adoption is not only a question of whether a feature works. It is a question of whether the feature joins a system of habits without asking those habits to disappear.

The product is a guest in the project

Thinking of OFM as a guest is useful. A good guest pays attention to the rules of the house. It does not rearrange every room on arrival. It asks where it can be helpful and leaves the owner able to understand what happened.

That is the posture we want for connected knowledge. OFM should be useful inside a project without pretending to own the project's entire memory. It should make the active work easier while leaving the user's existing source visible and respected.

This principle will matter beyond Obsidian. Every future connection should begin with the same question: what does the user already trust, and how can we add value without taking that trust away?

One sentence can save a year of assumptions

The conversation happened in the middle of client work, which is exactly why it mattered. It was not a staged product interview designed to confirm an idea. It was a glimpse of the environment in which software has to be useful.

We want to keep noticing those glimpses. They are often more valuable than a polished request because they show the relationship between the product and the rest of the person's life. The best direction may begin with a sentence that was never intended to become a roadmap item.

That is why this episode belongs in the build story. It captures a product decision while the reason for it is still close enough to see. A release can tell people what changed; this conversation tells them why the change mattered.

The feature came from listening before designing.