OGAD

An Obsidian vault is a folder on disk, and is a separate concept from OGAD's internally encrypted password Vault; selecting an Obsidian folder will not move it into the password database.

Using OGAD's Obsidian integration requires the desktop version of OGAD and a version that includes the Obsidian integration code; notes must be real local files, and cloud storage placeholders must first be downloaded before they can be used by the local reader.

OGAD supports connecting multiple folders via Add vault, so work and personal note vaults can remain separate; when asking questions you can specify the vault name to narrow the search scope; after moving a vault you can restore access again, and removing a connection stops subsequent reads but does not delete the original notes or the text already copied in saved conversations.

OGAD's Obsidian integration does not promise to understand all plugins, canvases, attachments or graph relationships; its area of strength is ordinary Markdown text.

After connecting to the Obsidian folder, OGAD gives the selected model a set of tools: list notes, search file names and contents, and read specified notes; the model reads as needed rather than loading all notes into context at once.

OGAD's connection to the Obsidian folder is read-only, and will not write, delete or rename notes, with editing still done by Obsidian.

The operation path for configuring the Obsidian integration in OGAD is: open Integrations, find Obsidian, select the folder containing Markdown notes, confirm the card shows it is connected, then select a local text model that supports tool calling, and open the conversation.

When using OGAD's Obsidian integration, if the answer just repeats the question or cannot access the notes, you should first check whether the integration is enabled for that conversation, then confirm whether the model actually supports tool calling; a model that can chat may not be able to correctly use the search and read tools.

OGAD's search tool searches text, and it does not guarantee that a broad phrase will hit all related concepts; the results of a partial search cannot be taken as evidence that a certain decision never existed; large vaults and extremely long notes have read and search limits.

OGAD's privacy boundary depends on the chosen model: a remote model may receive the note text needed to answer, while a local model keeps inference on the local machine; but even if OGAD itself does not upload anything, if the user syncs the vault via iCloud, OneDrive or Obsidian Sync, those cloud services still hold a copy of the notes.

Using OGAD's Obsidian integration does not require an Obsidian cloud account or API key; the App and model download stage requires an internet connection, after which the downloaded local model reads the downloaded notes, so it can work offline.

OGAD (Off Grid AI Desktop) allows a local model to directly read the Obsidian folder on the user's computer, with note data never leaving the machine, while also enabling question answering.

This guide is based on the routines and account implementation of OGAD beta 122.

In the task instructions, the summary should distinguish the sender's original request from the model's suggested next step, quote dates exactly as written, and mark unconfirmed dates as "unconfirmed".

If push-level real-time behavior is needed, it should instead be driven by the provider's Webhook or push notifications, but this usually requires additional server-side configuration.

Connecting the mail reading tool does not automatically provide a mail sending tool; sending email through other already enabled tools or browser tasks is an independent operation with its own permissions and approval requirements. A routine that only prepares drafts still has value without automatic sending and minimizes permissions.

The From field in OGAD is a text filter on the event details, not a precise sender identity rule; filling in the customer's full email address reduces broad matching, and keeping sender verification in the task instructions makes the expected scope clearer.

When letting the model send email on its own, any summary deviation or misjudged tone goes straight into the customer's inbox and is hard to retract afterwards; the safer approach is to have the assistant always leave the prepared reply in draft state, with a human deciding whether to adopt and send it.

Tool Calling is a key capability for whether a local model can handle email summarization; a model that supports tool calling can proactively call external functions (such as reading mailbox emails) according to instructions, while one that does not can only answer out of thin air or rely on already injected context, potentially producing summaries that do not match the real emails.

The first successful check establishes a baseline point, and existing mail in the inbox will not be treated as newly arrived mail; if a summary of earlier mail is needed, the app requests it separately with a date range.