Memories

Polylane keeps two layers of learned context. Memories record one finding at a time, written by agents or by you. Notes are written automatically from your workspace's daily activity. Both feed future agent runs.

Memories

A memory is a markdown document with a title and labels. Memories capture institutional knowledge: confirmed failure modes, recurring patterns, and operational facts backed by evidence.

Memories get created two ways:

• By agents. When an agent confirms a root cause or discovers a pattern during an investigation, it stores the finding as a memory through the memories API (POST /v1/memories, reachable from the agent's built-in Polylane MCP access). Each agent-written memory records its source: the investigation, automation, or observation that produced it, and the thread it came from.
• By you. Open Memories in the console and select New memory. Write the content in markdown, then add labels and an optional title. If you skip the title, Polylane generates one from the content.

Agents store only confirmed findings. Each one records what was learned, the evidence that confirmed it, and the affected resources. Agents do not store user preferences, speculative conclusions, or configuration already visible in the topology.

How memories reach future runs

When a memory is saved, Polylane splits the content into chunks and embeds each chunk for semantic search. In later threads, agents search memories by meaning and by keyword and pull in the matching chunks. The thread prompt instructs agents to search workspace memory whenever they investigate an issue. You can also attach a specific memory to a thread; its content is injected into the conversation directly.

Worked example: a known flaky dependency

Suppose integration tests for checkout-api fail intermittently because a payment vendor's sandbox times out under parallel load. Every re-investigation wastes time rediscovering this. Save it once, from a thread:

Save a memory: checkout-api integration tests fail intermittently because the
payment vendor's sandbox times out under parallel load. Retrying the test job
masks it. Confirmed on 2026-07-10 from pipeline logs showing 504 responses from
sandbox.vendor.example. Affected resource: checkout-api.

The next agent that investigates a checkout-api test failure finds this memory and rules out the known failure mode before digging further.

Write memories the same way: name the service, the failure mode, the evidence, and the affected resources. Edit, archive, or delete a memory from its page when reality changes.

Try it from your coding agent:

Use Polylane to save a memory: checkout-api is expected to spike every weekday at 09:00 UTC when the batch import runs, so elevated request volume at that time is normal.

Notes

Notes are auto-written. Find them under Settings → Notes.

• Daily notes. Once a day, Polylane summarizes the day's thread activity into one note per date. It captures day-level patterns and notable signals, not a play-by-play. Days with no thread activity produce no note.
• Workspace note. A single living document of durable facts: architecture, tooling, conventions, naming, ownership. Polylane updates it only when a day's activity reveals a fact that will still be true in a month. Most days it changes nothing.

Every new thread's briefing includes the workspace note and the three most recent daily notes, so agents start each conversation oriented.

You can edit, copy, download, or delete both kinds of note, but Polylane is the primary author.

Memories vs notes