Distribution

A memory folder can be used by several applications, agents, and tasks at once. A task might save campaign results that an analyst reads in Claude, or a developer might leave investigation notes for the next Claude Code session. Each works with the documents stored in qbash, rather than a separate copy for each application.

MCP and AI applications

Add the folder to an MCP server to use it from Claude, ChatGPT, Grok Bot, Claude Code, Codex, Cursor, or another MCP client. Choose which memory tools to include: a reference library might need only reading and search, while a shared working folder also needs tools to create and update documents. The same server can include tasks and connector tools.

The MCP server guide covers adding a folder, selecting its tools, and connecting your applications. You do not need RAG enabled to retrieve known documents or save notes. Enable it when you want agents to search the folder by meaning.

Using memories with agents

An agent can use memories as shared reference material and as a record of its work. Connecting the folder makes its tools available; the agent still needs to know when to read or update a document. It does not automatically synchronize conversation transcripts or load every document into each session.

Session handoffs

Give ongoing work a stable document name, such as Checkout incident investigation. Ask the agent to read it before continuing and update it at useful checkpoints. For example, include this in the agent's instructions:

Before investigating checkout errors, read "Checkout incident investigation"
from the Engineering memory tools. Check the date, affected release, and
evidence before relying on earlier findings.

After a test run or a useful finding, update the same document with the
current conclusion, evidence, unresolved questions, and next action.
Preserve relevant findings from other contributors. If the write needs
review, report that it is pending rather than saying it is published.

A short handoff document is often enough:

# Checkout incident investigation

Updated: <date and time>
Release or commit: <version examined>

## Current finding
<What the evidence supports, and what remains uncertain.>

## Evidence
<Tests, results, relevant logs, and links to source material.>

## Next action
<The next check, its purpose, and any constraints.>

## Changes since the last update
<New findings and any earlier conclusion they replace.>

The agent can use find_memory for a known name or ID, or list_records to browse. Before editing, it should retrieve the latest document and incorporate its new findings. update_memory with operation: "replace" replaces the supplied content; "append" adds to the end. The record ID keeps updates attached to the same document even if its name changes.

For related runbooks or past incidents, enable RAG and include vector_search on the server. The same handoff documents become searchable after indexing.

If a document requires review, a write opens a pull request instead of publishing immediately. The result identifies the pending request, and readers continue receiving accepted content until it is accepted. See Reviewing PRs.

Using memories in tasks

In the task editor, open Resources → Memory and attach a folder. Enable Read-only for reference material, or allow writes when the task needs to save results. Save the task to keep the attachment.

Use the attached folder's name in folder=. For example, create a Reporting folder containing a Metric definitions document, then attach it to a task with figures and week inputs. The task can read the definitions and earlier reports, write this week's report, and save it for future runs:

main.py

definitions = qbash.memories.get("Metric definitions", folder="Reporting")
previous_reports = qbash.memories.query(
    metadata={"report_type": "weekly"},
    folder="Reporting",
)

report = qbash.ai.raw(
    f"Write this week's report using these metric definitions:\n"
    f"{definitions['content']}\n\n"
    f"Previous reports:\n{previous_reports}\n\n"
    f"This week's figures:\n{qbash.inputs.get('figures')}"
)

result = qbash.memories.store(
    name=f"Weekly report - {qbash.inputs.get('week')}",
    content=report,
    metadata={"report_type": "weekly"},
    folder="Reporting",
)

if result.get("status") == "pending_review":
    print("Report submitted for review:", result["pull_request_id"])

store creates a document; update changes an existing one by ID. Use update when maintaining the same document between runs. store(file=...) accepts a qbash file reference instead of Markdown content.

A memory-folder input can supply folder_id= at runtime when each person running the task should choose their own folder. Use either folder or folder_id, not both. Full signatures and response fields are in the SDK reference.

The task's bundled Markdown files are separate from shared memory folders. Omitting the folder from a read targets those files; writes require an explicit folder.

Reading and searching

Use the method that matches what you know about the document:

What you know	Task SDK	Result
Its exact name	qbash.memories.get(name, folder=...)	One document and its content
Its metadata	qbash.memories.query(metadata={...}, folder=...)	Documents matching every supplied field
A word or phrase	qbash.memories.search(query, folder=...)	Whole documents matching the keyword
The subject or question	qbash.memories.vector_search(query, folder=...)	Relevant chunks with similarity scores

Exact lookup, metadata filters, listing, and keyword search work without RAG enabled. Metadata filters compare exact values and types. Keyword search covers names, metadata, attached filenames, and Markdown bodies; use semantic search to find passages in uploaded files.

For example, attach Support knowledge with Searchable by AI enabled, then retrieve passages to supply to a prompt:

context = qbash.memories.vector_search(
    query="How do we handle duplicate billing?",
    folder="Support knowledge",
    limit=5,
)

Semantic search returns chunks, so several matches may come from the same document. Start with the default similarity threshold and retrieve the source document when a passage needs more context.

Memory tools

These are the memory operations available through MCP. A server may prefix or rename them, or present read and write operations as grouped tools. Use the names and argument schemas shown in the connected client's tool list.

Operation	Arguments and result
find_memory	Supply recordId or exact name to read one document. Use the ID if a name is ambiguous.
list_records	Browse IDs, names, and creation times without loading full content. Optional metadata filters narrow the list.
query_memories	Filter by exact name or metadata, returning matching documents. Metadata filters are an array such as [{"key": "account", "value": "acme"}]; every condition must match.
search_memories	Supply a keyword query and optional limit. Searches names, metadata, attached filenames, and Markdown bodies without embeddings.
vector_search	Supply a natural-language query, optional limit, and optional similarity_threshold. Returns relevant chunks and scores from a folder with AI search enabled.
get_propositions	Supply recordId to inspect the facts extracted during indexing.
create_memory	Supply name and Markdown content, with optional metadata and vector_description search summary. Creates a document or submits it for review.
update_memory	Supply recordId, with content, metadata, or vector_description. operation is replace by default or append. Publishes the update or submits it for review.

Search reads accepted content. Keyword search does not match the extracted body text of uploaded files; semantic search uses their indexed content. Updated semantic results may lag behind a published edit while indexing runs.