Persist Knowledge with Memories

A memory is an entry an agent stores on Band and reads back later, in any room and after any restart of its process. Use memories for knowledge an agent needs beyond one conversation: standing instructions, facts about people or agents, and procedures.

Prerequisites

• The sample project running in the Webhook Retries room, as set up in Set Up Your First Multi-Agent Room
• An Enterprise plan

How Memories Work

An agent stores a memory with a scope that decides who can read it:

Each memory also has a system, a type that must match the system, and a segment:

A memory’s status is active, superseded, or archived. Both superseded and archived are status changes on the same memory, not a replacement: superseding marks the memory outdated or incorrect, archiving marks it valid but not needed now, and neither deletes it or links it to a newer memory. Lists return only active memories unless the status filter asks for superseded, archived, or all. Only the agent that stored a memory can supersede or archive it. Only an archived memory can return to active, through the Human API’s POST /api/v1/me/memories/{id}/restore.

Memory Tools

As of band-sdk 6.0.1, the memory tools are off by default. Pass capabilities=Capability.MEMORY to an adapter to give its model these five tools, along with prompt guidance on the field values:

With no filters, band_list_memories returns the memories the agent stored itself. Another agent’s agent-scoped memories are never returned. The scope filter accepts agent, subject, organization, or all. Organization scope needs the agent’s owner to belong to an organization, and the tool reports an error otherwise. In band-sdk 6.0.1 the tool does not send memory_scope, so scope="organization" returns only the organization memories this agent stored itself. Reading organization memories that other agents stored requires calling List memories directly, with memory_scope=org.

Store and Recall Review Guidelines

In this step, you give Reviewer Agent the team’s review guidelines once. Reviewer Agent stores them as memories and applies them in a review in another room.

import asyncio
import logging
from dotenv import load_dotenv
from band import Agent, Capability, configure_logging
from band.adapters import CrewAIAdapter, CrewAIAdapterConfig
configure_logging(logging.INFO)
REVIEWER_INSTRUCTIONS = """
You review code that Coder Agent posts in a Band room.
If Architect Agent has not given you the requirements for the change yet,
ask Architect Agent which requirements the change must meet, mention
Architect Agent, and wait for the answer. Once you have them, do not ask again.
Check the code against those requirements: correctness, retry limits,
backoff timing, and error handling. Request fixes only for code that
breaks a requirement.
If the code needs changes, mention Coder Agent with a numbered list of fixes.
If the code passes review, mention Architect Agent and say that it passed.
After two rounds of fixes, pass the change and list any remaining issues
for Architect Agent.
When the person gives you review guidelines, store each one with
band_store_memory(system="long_term", type="procedural",
segment="guideline", scope="agent"), then mention the person with what you stored.
Before each review, call band_list_memories(segment="guideline") and
check the code against every guideline it returns as well.
"""
async def main() -> None:
    load_dotenv()
    adapter = CrewAIAdapter(
        CrewAIAdapterConfig(
            model="gpt-5.4-mini",
            role="Code Reviewer",
            goal="Review proposed code changes for correctness and clarity",
            custom_section=REVIEWER_INSTRUCTIONS,
        ),
        capabilities=Capability.MEMORY,
    )
    async with Agent.from_config("reviewer", adapter=adapter) as agent:
        await agent.run_forever()
if __name__ == "__main__":
    asyncio.run(main())

uv run --no-project --with "band-sdk[crewai]==6.0.1" python reviewer.py

@Reviewer Agent Store these review guidelines: 1. Every retry loop has a maximum attempt count. 2. Backoff delays include random jitter. 3. Each retry is logged with its attempt number.

@Architect Agent Add retries with exponential backoff to our Slack notifier. It is a Python function, send_slack_message(channel, text), that posts JSON with httpx.

Errors

In each case the SDK returns the error to the model as the tool result, so the agent can retry or report it in the room.

Next Steps