Reliable agent workflow memory is not model recall. It is a workflow design that stores the minimum useful state outside the model, retrieves that state with a stable business key, checks whether it is current and valid, and validates the agent’s structured result before changing a record or taking action.
Consider a support follow-up for case CASE-1042. The incoming event supplies the case ID and an immutable message ID. The scenario retrieves the case status and outstanding evidence, checks that the case is still active, and asks the agent only whether the new message claims that the requested logs arrived. The workflow then verifies the attachment in the source system and validates the agent’s response before updating the case or routing it to support staff.
An agent does not automatically remember earlier Make scenario runs. The scenario must explicitly provide conversation history, retrieved records, or other selected context.
Choose the right kind of memory for the job
Memory can mean several different things in an automation. Separate these categories before choosing where to store data:
- In-run context: the trigger data and context mapped into the agent during the current scenario execution. It is available to that run, not automatically to a future run.
- Persistent operational state: changing facts needed for the next decision, such as case status, assigned owner, opt-out flag, or outstanding document. Retrieve these from the system of record, such as a CRM or database.
- Event history: individual messages, approvals, or source events retained for duplicate detection, audit, or replay. Keep event identity separate from the current-state record.
- Reference knowledge: policies, product guidance, or manuals that help interpret a case but are not authoritative for its current status.
Make Data stores can provide basic structured storage across scenarios. Make’s integration catalog lists record actions including Get a record, Search records, Add/replace a record, Update a record, and Delete a record. These are storage capabilities, not automatic model memory. The scenario must explicitly retrieve, map, validate, and write state. See Make Data stores documentation and the Data store and Make AI Agent capability page.
Use an operational system for mutable customer facts. Make Knowledge files use retrieval over chunked, vectorized content and are better suited to relatively stable reference material. Make advises against using frequently changing client directories or sensitive customer information as general knowledge files. See Knowledge files for AI Agents.
A policy manual can be reference knowledge. A current opt-out flag or case status belongs in its operational source of truth. Retrieve live status from that source before acting rather than relying on an old indexed copy.
Choose storage based on record volume, concurrency, schema complexity, retention, access requirements, and transaction needs. Data stores can suit a basic state record, but the reviewed Make documentation does not establish transactional updates or cross-scenario locking. A CRM or dedicated database may be more appropriate where stronger controls are required. For help designing the scenario and system boundaries, see Make automation consulting.
Design the record: current state, event identity, and provenance
Define the data grain before selecting a key. Use one current-state record per case or customer, one event record per source event when deduplication or replay matters, and a separate run or decision record when audit requirements call for it. A customer ID is not a unique event key because one customer can generate many legitimate messages, approvals, and runs.
The following is an illustrative design, not a Make-prescribed schema. The current-state record represents one case. Event history, if required, is stored separately at one record per source event. A separate run record can store the state snapshot used by a decision and its outcome.
{
"state_key": "CASE-1042",
"state_version": 7,
"schema_version": 1,
"current_state": "awaiting_logs",
"required_attachment": "system_logs.zip",
"product_tier": "enterprise",
"last_meaningful_event_at": "2026-10-17T09:30:00Z",
"last_processed_event_id": "email-8472",
"source_system": "support_crm",
"source_record_id": "CASE-1042",
"provenance": ["CRM case 1042", "email-8472"],
"expires_at": "2027-04-17T00:00:00Z",
"updated_by_scenario": "support-follow-up"
}For the event-history grain, an illustrative event key could be email-8472:evidence_received. That key identifies one source event and one attempted action, not the whole customer or case. If a run produces multiple citations or evidence items, retain them as separate evidence records or references rather than collapsing them into one ambiguous latest value.
Keep only fields the next decision needs, and retain source IDs or evidence references so a reviewer can inspect the original. Set expiry and retention according to business and privacy requirements. If two scenarios can write the same record, assign ownership or define how updates are reconciled rather than allowing one scenario to silently replace another’s work.
A practical Make architecture: read, decide, validate, write
Build the scenario as a controlled chain. The AI step interprets unstructured input. The workflow owns identity, permissions, validation, allowed transitions, and persistence. Make’s AI Agent guidance covers defined inputs and outputs, structured response formats, filtering supplied data, testing, and human review. Guardrails are useful, but Make warns that an agent may still ignore or misinterpret them. See Make AI Agent best practices and our AI agent implementation service.
For a support message, the agent could return the following illustrative structure. The workflow must validate the allowed values and confirm the attachment in the source system before updating the case.
{
"decision": "evidence_received",
"reason_code": "attachment_claim",
"missing_fields": [],
"source_evidence_ids": ["email-8472"],
"requires_human_review": false
}Reject malformed output or a decision outside the allowlist. Use deterministic filters for opt-out, permissions, required fields, eligibility, and permitted state transitions. Use AI for ambiguous language classification, extraction, or summarization. An agent’s assertion that a file arrived is not proof that the file is present.
Three patterns for persistent agent workflows
These are hypothetical designs assembled from documented Make capabilities, not official or tested Make templates. Each makes the trigger, bounded AI task, validation, destination, and exception owner explicit.
| Trigger | AI responsibility | Validation | Action and fallback |
|---|---|---|---|
| New support email or webhook event | Classify whether the message claims requested evidence arrived | Unique case match, attachment verification, allowed output, unseen event ID | Update case state; support owner handles ambiguity or mismatched files |
| Later approval or document event | Summarize a document or classify an unstructured response | Expected state, authorized approver, unexpired request, unseen event | Advance workflow; workflow owner handles expired or unauthorized events |
| New Salesforce case message | Summarize selected context or classify routing intent | Single correct record, access, opt-out and status rules, valid output | Update approved fields; Salesforce administrator handles access or query errors |
Support case: lookup, classify, write
Input: case ID CASE-1042, source event email-8472, message text, and current case state. A Make scenario retrieves the case from a Data store or an appropriately configured CRM, maps only relevant fields into the agent, and validates the returned decision.
AI output: an allowlisted decision such as evidence_received, evidence_not_received, or ambiguous, plus a reason code, missing fields, evidence IDs, and a human-review flag.
Gate and destination: confirm the case is still awaiting logs, check that email-8472 has not already been accepted, and verify the requested attachment in the source system. If all checks pass, update the operational record with the new state, event ID, and provenance. If the message is ambiguous, the case ID matches multiple records, or the claimed file is missing, assign the case to support staff without changing its state.
Approval or document workflow: wait, resume, complete
At intake, save a workflow ID, expected next state, expiry, authorized approver, and original request reference. A later webhook or supported application trigger retrieves that record and checks the approval event ID, workflow state, approver, and expiry before continuing.
AI may extract a document reference or summarize an unstructured response, but it does not establish that the approver is authorized. A duplicate approval must not complete the workflow twice. An expired or unauthorized approval goes to the workflow owner. Make webhook processing and incomplete-execution features can support this pattern, but they do not provide transactional rollback or exactly-once completion.
Salesforce-backed support context
A scenario can use Make’s Salesforce integration to search for or retrieve selected case fields, pass only necessary context to an agent, validate its proposed route, and update only approved fields. The integration reference lists search, get, update, upsert, and API-call capabilities. Permissions, object configuration, queries, and limits still need to be checked for the Salesforce organization.
If a search returns no record or multiple plausible matches, route to a Salesforce administrator or support operations owner rather than letting the agent guess. Check that the selected record belongs to the expected account or case, and preserve its Salesforce record ID and source timestamp in the state record. See Make’s Salesforce module reference and CRM systems consulting.
Protect state from duplicate events, stale reads, and failed runs
Use the immutable source event ID plus action type as the basis for idempotency. A customer ID or date alone cannot distinguish separate legitimate events. Record the accepted event or use a destination-side idempotency mechanism so a retry can recognize completed work.
A lookup-then-insert check can race. When correctness depends on preventing duplicate records or lost updates, use a database-enforced uniqueness constraint or atomic upsert where the selected destination provides it. Do not assume Make Data stores provide those controls. If the chosen store cannot enforce the required guarantee, move the idempotency decision to a system that can or route conflicting events for review.
Instant Make webhooks run in parallel by default. Enabling ordered processing can help when events for a scenario should be handled sequentially, but it is not a universal transaction or a lock shared across scenarios. If two runs can update the same record, select storage and update semantics that meet the workload’s concurrency needs. See Make webhook documentation.
Define freshness rules by decision. Compare the source event timestamp and state timestamp. If state is too old for the action, re-read the authoritative system or send the case for review. Check approval expiry and revalidate status immediately before consequential actions. These thresholds are business rules, not Make defaults.
Plan for the external-action and write failure. If an email, refund, or provisioning action succeeds but the state write fails, reconcile using the external action ID and source event ID before retrying. Make error handlers and incomplete executions can help manage failures, and incomplete executions may be retried or resolved depending on configuration. They do not guarantee exactly-once external actions or transactional rollback. See error handling, incomplete executions, and managing incomplete executions.
Test the workflow and observe what it actually used
Test missing, duplicate, stale, malformed, unauthorized, and concurrent events. Also test a failure after an external side effect. For each case, record the expected destination, owner, and whether state should change.
Inspect Make module outputs and execution details to review mapped bundles and agent inputs. These details can help diagnose what was passed through the scenario, but they should not be treated as complete provider-side or record-level lineage. If audit requirements permit, store a redacted state snapshot or a hash of the decision input with the run record.
Make Grid can show dependencies among scenarios, apps, data stores, and AI-related components. It is an infrastructure map, not a record-level memory audit system. Track operational measures that match the workflow: repeated requests for information already recorded, duplicate external actions, stale-state rejections, human-review rate, and unreconciled failed writes.
- A missing or ambiguous key has a named human owner.
- Current state, source events, and run records have distinct grains and identifiers.
- Duplicate events are detected using event identity, not customer ID alone.
- Stale state, expired approvals, and unauthorized events are rejected or revalidated.
- Malformed output and disallowed state transitions cannot write to the system of record.
- Concurrent updates have a documented storage strategy, including uniqueness or transactional controls where required.
- A successful external action followed by a failed write can be reconciled without blindly repeating the action.
- Execution details expose the mapped fields needed for diagnosis, with sensitive data handled according to retention and access rules.
Frequently asked questions
Does Make AI Agent remember prior scenario runs?
No. Persistent state requires explicit storage and retrieval. A reused Conversation ID carries conversation history, but it is not a substitute for a well-keyed operational record. Make documents that reusing a Conversation ID grows the history passed to the agent. Limiting conversation history and filtering inputs can reduce token use, but this does not mean external memory automatically prevents usage limits.
Can Make Data stores replace a database?
They can provide basic structured state across scenarios. Suitability depends on volume, concurrency, schema complexity, retention, access controls, and transaction requirements. Use a system with the necessary uniqueness and update guarantees when those controls matter.
Should I use RAG for changing customer status?
Usually not as the sole source of truth. Use the CRM, Data store, or database that owns current status. Use Knowledge files for stable reference material such as policies or product documentation.
Should the workflow store a whole conversation?
Store the fields required for the next decision and retain source-event references for review. A compact structured record is a practical design choice, not a vendor-published performance guarantee. Keep raw messages or documents only where retention, privacy, and audit requirements justify them.
How do I prevent one webhook from updating a CRM twice?
Use an immutable source event ID with an action type, plus an idempotency record or destination-side uniqueness control. Do not rely only on a prior search followed by create when concurrent runs are possible.
What should AI decide, and what should rules decide?
Use AI to interpret unclear language, extract fields, or summarize relevant context. Keep authorization, eligibility, opt-out, duplicate detection, and permitted state transitions in deterministic workflow logic.
Are these official Make templates?
No. Lookup-classify-write and wait-resume-complete are adaptable patterns assembled from documented capabilities. The cited Make pages do not establish them as downloadable, validated vendor templates.