Memory and Persistence Patterns

Kindo agents use run-scoped memory by default, and agent owners can enable a per-user, per-agent persistent sandbox when files and state should carry across that user’s runs. This guide covers the built-in persistence options and patterns for extending memory with external systems.

Overview

Kindo scopes agent memory to individual runs by default. The platform also offers an opt-in per-user, per-agent persistent sandbox for agents whose owners turn it on, and the patterns below extend memory further using integrations and external systems:

Pattern	Scope	Read	Write	Durability	Complexity
Knowledge Store	Org-wide	✅	❌ (manual upload)	High	Low
Sandbox	Single run	✅	✅	None (ephemeral)	Low
Persistent Sandbox	Per-user, per-agent	✅	✅	Across runs	Low
External System	Cross-workflow	✅ via API/MCP	✅ via API/MCP	High	Medium
Git Repository	Team-wide	✅ (manual sync)	✅ (commits)	Very high	Medium

Pattern 1: Knowledge Store — Static Reference Data

When to Use

Agent needs access to policies, runbooks, compliance frameworks, threat intel feeds
Data changes infrequently (updated by humans, not agents)

How It Works

Upload files to Knowledge Store (PDF, markdown, CSV, etc.)
Attach Knowledge Store to agent(s) — multiple agents can share the same files
Agent references files via Library Search or direct attachment

Limitations

Read-only: Agents cannot update Knowledge Store files
Manual upload: No API for programmatic updates (currently)
File size limits: Apply to uploads

Example

Upload your organization’s incident response playbook as a PDF. Attach it to all SOC agents — they reference it when classifying incidents.

Pattern 2: Sandbox — Ephemeral Per-Run Memory

When to Use

Intermediate results within a multi-step workflow
Large data that needs filtering before LLM processing
Temporary files (scripts, extracted data, reports)

How It Works

API Action steps and tool outputs write to the sandbox automatically when large
LLM steps can read/write sandbox files using shell commands
Data persists for the duration of the workflow run, then is discarded

Cross-Reference

→ See Working with Large Context for detailed sandbox techniques

Limitations

Ephemeral: Gone after the run ends
Not shareable: Between agents or runs

Pattern 3: Persistent Sandbox — Per-User, Per-Agent Memory Across Runs

When to Use

Agent needs to keep files, scripts, or working state across runs (e.g., a long-running research agent that builds up notes, or a code agent that maintains a working checkout)
You want the durability of a sandbox without writing to an external system

How It Works

The agent owner opens the agent’s settings and turns on Persistent Workspace.
Each user who runs that agent gets their own isolated persistent sandbox — files and state created during a run are still there on that user’s next run of the same agent.
When the toggle is off, behavior is unchanged from Pattern 2 (single-run, ephemeral).

Per-User Isolation — Important

Persistent sandboxes are scoped to (user, agent), not just to the agent. If you and a teammate both run the same shared agent with persistent workspace enabled, you each get your own private sandbox. Files written during your runs are not visible to your teammate, and vice-versa.

This is intentional. It means:

Sharing the agent does not share its filesystem state. A user who runs a shared agent does not see anything other users wrote into that agent’s sandbox.
Concurrent runs by the same user share the same sandbox. Two simultaneous runs by you against the same persistent-sandbox agent will see and write to the same filesystem. Plan for that the same way you’d plan for two processes sharing a directory.
Team-level shared persistent sandboxes are not supported today. If multiple users genuinely need to share state across runs, use Pattern 4 (External Systems) so the read/write path is auditable and consent-based.

Limitations

Per-user, not per-team: see above.
Sharing an agent does not share its sandbox state. Recipients of a shared persistent-sandbox agent get a fresh sandbox keyed to their user identity on first run.
Availability: the feature is gated by an opt-in flag and requires a sandbox provider that supports persistence (e.g., Daytona). Orgs on providers without persistence will not see the persistent-workspace toggle. Talk to your Kindo contact if you want it enabled for your org.

Cross-Reference

→ See Working with Large Context for sandbox techniques that apply to both ephemeral and persistent sandboxes.

Pattern 4: External Systems — Persistent Cross-Workflow Memory

When to Use

Agent needs to remember findings from previous runs
Multiple agents need to share state (e.g., investigate → remediate pipeline)
Audit trail required for agent decisions

How It Works

Write: Use API Action steps to create/update records in external systems:

Create Jira tickets with structured findings
Post to Slack channels as a persistent log
Write to Notion/Confluence pages
Push to Google Sheets for tabular data

Read: Use API Action steps at the start of a workflow to load previous state:

Query Jira for tickets created by previous agent runs
Read from a designated Notion “agent memory” page
Fetch latest entries from a Google Sheet

Architecture

Agent run N writes structured JSON to Notion page
    ↓
Agent run N+1 reads that page as first step
    ↓
Processes new data
    ↓
Writes updated state back

Example: Vulnerability Tracking Over Time

Weekly scan agent writes top 10 findings to a Notion database
Each row: CVE, severity, first seen date, current status, remediation owner
Next week’s run reads the database → compares with new scan → updates statuses → adds new findings → flags regressions

Design Considerations

Choose familiar systems: Use tools your team already uses (don’t add new tools just for agent memory)
Use structured formats: JSON in Jira custom fields, database rows in Notion — so agents can parse reliably
Include provenance: Timestamps and run IDs so you can trace which agent run wrote what
Consider rate limits: Especially for high-frequency scheduled agents hitting external APIs

Pattern 5: Git Repository — Versioned Agent Configuration

When to Use

Managing production agents across a team
Need change history, rollback capability, peer review for prompt changes
Regulatory/compliance requirement for audit trail of agent behavior changes

How It Works

Maintain a Git repository with agent configurations:

agents/
  alert-triage/
    README.md          # Purpose, owner, version
    system-prompt.md   # The agent's system prompt
    steps.yaml         # Step definitions and configuration
    CHANGELOG.md       # Version history
  vuln-reporter/
    ...
knowledge-store/
  playbooks/
  compliance-frameworks/

When making changes: update in Git → review via PR → apply to Kindo manually.

→ See Prompt and Agent Configuration Management for full versioning and governance guidance.

Limitations

Manual sync: Currently no Git → Kindo auto-deploy pipeline
Recreation required: Agent configuration must be recreated in the Kindo UI after Git changes

Customer Evidence

A customer managing 6 production agents maintains a GitHub repository with versioned prompts, changelogs, and a meta-agent that updates the repo README — proving this pattern works at scale.

Choosing a Pattern

Question	Pattern
Agent needs static reference data?	Knowledge Store
Need intermediate results within one run?	Sandbox
Same user runs the agent repeatedly and needs files to stick?	Persistent Sandbox
Multiple users need to share state across runs?	External System
Need team-wide agent config management?	Git Repository
Multiple agents share state?	External System
Compliance requires audit trail?	Git Repository + External System

Limitations and Roadmap Context

Kindo’s built-in persistent memory is the per-user, per-agent Persistent Sandbox described above. It does not yet provide a team-shared persistent memory store that agents can write to and read from across users; the patterns above (External Systems, Git Repository) cover that case.

Kindo currently does not support programmatic Knowledge Store updates via API. File uploads are manual through the UI.

These are architectural constraints of the current platform, not fundamental design decisions.