Data

Data in MadMax

The three homes for data that outlives a run: stores for keyed rows with a schema, memory for an agent's conversation turns, knowledge bases for documents.

Workflows pass payloads step to step, but payloads die with the run. For data that outlives a run, MadMax has three purpose-built homes, all managed in Settings → data and all scoped to the workspace (a workflow can only reach the data of its own workspace):

	what it holds	written by	read by	reach for it when
Data stores	structured rows with a schema, keyed	save to store steps	get from store, the REST API	workflows produce/consume records: results, caches, work queues
AI memory	conversation turns, per session	the AI agent automatically	the same agent, next run	an agent should remember prior exchanges ("as I said yesterday…")
Knowledge bases	your documents, chunked + embedded	you, by uploading, or a knowledge write step	agents, by semantic retrieval	an agent should answer from your documents

The shorthand:

Stores are tables. Deterministic reads and writes, schema enforced, external API. If you'd reach for a spreadsheet or a database table, it's a store.
Memory is a chat log. The agent recalls the last N turns of a conversation, scoped by a session key. If the requirement sounds like "remember what this user said", it's memory.
Knowledge is a library. Documents in, relevant excerpts out at question time. If the requirement sounds like "answer based on our docs/policies/manuals", it's a knowledge base.

They compose: a support agent might retrieve the refund policy (knowledge), recall this customer's previous complaint (memory), and look up their order (store), all in one step.

Stores in a little more depth

A store has a name, a slug (the handle steps and the API use), an optional description and a schema that every row is checked against on write. Rows are keyed: a save-to-store step with the same key replaces the row, so a store doubles as a dedupe table or a cache without extra logic. Create and manage stores in Settings → data (create, import, export, edit the schema, browse rows, delete by typing the slug), or over the REST API. Each store has a row cap, 100,000 by default; a full store rejects new rows with a clear error instead of silently dropping old ones.

Memory in a little more depth

A memory belongs to the workspace and is attached to an agent step in the Inspector. On each run the step supplies a session key (a user id, a Slack thread, an order number) and the agent reads the last window turns for that session (10 by default) before answering, then appends the new exchange. Turns beyond the window aren't thrown away: they're folded into a rolling session summary the agent also sees, so a long thread keeps its gist. In Settings you can open a session transcript, clear one session, or clear all of them.

Knowledge in a little more depth

A knowledge base is fed two ways: upload documents in Settings (.txt, .md, .csv, .json, and PDFs, which are transcribed first so scanned documents work too), or let a workflow write into it with the knowledge write step (index a repo, a docs site, tickets, notes; the same source name replaces the document). Documents are chunked and embedded as they arrive, and the Settings page has a test search so you can see what a question would retrieve before an agent relies on it. Attach a base to an agent step and it retrieves the relevant chunks at question time.

A worked example

An inbox triage workflow: an email trigger receives a customer message, an agent step classifies it with a memory keyed on the sender's address (so a second message from the same person is read in context) and a knowledge base holding the support handbook, and a save-to-store step writes {ticket_id, sender, category, summary} keyed on the message id. A second, scheduled workflow reads that store every morning and emails the day's open tickets. Three homes, each doing the one job it's built for.

‹ Waits, approvals & resumes Data stores ›