Memory for automated workflows

This page shows how a workflow can ask Alvia which instruction currently applies at a decision point, then act on the answer with its own controls. A workflow step calls the REST API, and a model call or a reviewer reads the answer; no chatbot or autonomous agent is needed.

The problem

A support operation requires a manager’s approval for refunds above $1,000. On September 12 the finance lead announces in the team channel that the threshold is now $500. A week later a $640 refund reaches the routing step. The workflow has to route it to approval under the new rule, and the reviewer should see why: the $500 threshold replaced the $1,000 one, and when.

Instructions like this change often, arrive as text from people and come with reasons and exceptions. Nobody files them as a schema change.

Why the usual approach falls short

A rules table or configuration value. It is the right home for a limit your system enforces, and you should keep it there. It holds only the value someone remembered to update. It does not capture an instruction given in a message, the reason for it or what it replaced.
Searching past messages. Both announcements are similar to the question, so both come back. The workflow then has to work out which one is current, which needs the date each was stated and a rule for when a later message replaces an earlier one and when it only conflicts with it.
Writing the instruction into the workflow or its prompt. Every change needs a deploy, and the old instruction stays in place until someone notices.

How Alvia changes the design

The workflow writes each instruction when it is given, with the time it was stated. Alvia compares the new instruction with what it holds in the same scope and records how they relate. In this example, Alvia classifies the $500 rule as replacing the $1,000 rule, so it becomes that memory’s next version (see Memory formation). At the decision point the workflow asks one question and gets one resolved answer: the current rule, what it replaced and when.

The workflow no longer stores, deduplicates or ranks instruction messages. It still enforces payment limits and permissions, executes the refund, decides what to do when the answer is missing and records the decision with the case. Alvia returns context, and approval and execution stay under the workflow’s controls.

Set up

Project. Use one project for the operation’s instructions. Use a separate project for any customer or business unit whose instructions must be kept apart. A project is the access boundary; scope is not. See Projects and scope.
Scope. Write and read with the same scope, here organization_id: acme and application_id: refund-flow. Alvia compares a new instruction only with memories in exactly that scope, so a write with a different scope is not recognized as a change.
Memory policy. Exclude payment credentials and personal identifiers, so instructions are kept but case details are not. Remove anything that must never reach Alvia before you send it. See Filter memories.

Example

Store the original rule

When the rule takes effect, the workflow submits it with Store memories. infer: false keeps the statement as one memory.

{
  "content": "Refunds above $1,000 require a manager's approval.",
  "infer": false,
  "occurred_at": "2026-09-01T00:00:00Z",
  "scope": { "organization_id": "acme", "application_id": "refund-flow" }
}

Record the change

When the finance lead changes the rule, the workflow stores the new instruction with the time it was given, and says what it replaces.

{
  "content": "Refunds above $500 now require a manager's approval. This replaces the previous $1,000 threshold.",
  "infer": false,
  "occurred_at": "2026-09-12T09:30:00Z",
  "scope": { "organization_id": "acme", "application_id": "refund-flow" }
}

Each write answers 202 and forms in the background, and a change becomes readable once formation finishes. Send the time the instruction was given as occurred_at; a future activation date belongs in the workflow.

Once the change forms, the memory’s two versions, the $1,000 rule and the $500 rule, are available through the API and in the dashboard, with how Alvia classified the change and why.

Ask at the decision point

When the $640 refund reaches routing, the workflow asks:

curl https://api.alvia.ai/v1/memories/context \
  -H "Authorization: Bearer $ALVIA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "What approval requirements apply to a $640 refund?",
    "scope": { "organization_id": "acme", "application_id": "refund-flow" }
  }'

An illustrative response:

{
  "context": "A $640 refund requires a manager's approval. The $500 threshold replaced the previous $1,000 threshold on September 12, 2026."
}

A model writes the sentence from the memories Alvia selects, so read it as text rather than parsing a fixed sentence.

Use the answer in the workflow

The routing step attaches the context to the case and routes the case by what the answer says. This sketch uses the get_context function from Read memories, which returns None on 404:

1
SCOPE = {"organization_id": "acme", "application_id": "refund-flow"}
2
ROUTES = ("approval", "auto_refund", "review")
3

4

5
def route_refund(case):
6
    question = (
7
        "What approval requirements apply to a "
8
        f"${case.amount} refund?"
9
    )
10
    try:
11
        context = get_context(question, SCOPE)
12
    except Exception:
13
        context = None
14
    if context is None:
15
        return hold_for_review(case, "No approval context")
16
    case.record("approval_context", context)
17
    # A model call reads the answer and returns one of ROUTES.
18
    route = choose_route(context, case.amount, ROUTES)
19
    if route not in ROUTES:
20
        route = "review"
21
    return send_to(route, case)

choose_route stands for the workflow step that reads the answer, such as a model call limited to the workflow’s routes. Here it returns approval, because the $500 threshold applies to a $640 refund, and review when the answer reports a conflict. Any other output goes to review. auto_refund still passes the refund system’s own limit check, so a route never releases money on its own.

The reviewer sees the current rule and its history beside the case. Payment limits and approver permissions are still enforced by the refund system; a generated sentence never authorizes a payout. A missing answer, a timeout or a conflict holds the refund for review instead of falling back to the old threshold.

If two people give conflicting instructions and neither replaces the other, Alvia keeps both and links them as a contradiction, so the context can report both. Route that case to a person.

The same pattern in fulfillment

A customer’s receiving instruction changes from “deliver to the main loading bay” to “use the side entrance while the loading bay is under repair”. The operations system stores the new instruction with the customer’s scope and the time it was given. Before it builds the dispatch pack, it asks which receiving instruction applies, shows the answer to the dispatcher and records it with the pack. Verified addresses, shipping labels and delivery status stay in the fulfillment system.

What Alvia does here

Supersession makes a new rule that Alvia classifies as a replacement the next version of the old one, as it is written
Contradiction keeps conflicting instructions and links them instead of merging them
Occurrence dates keep the time each rule was stated
Resolved context returns one answer at the decision point
Scope keeps one operation’s instructions compared and read together
Memory policies keep case details out of memory

Design notes

Formation is asynchronous. Formation finishes in less than a minute, so a rule change is readable shortly after the write. When a change must take effect at an exact time, change the enforced control in your system too.
Keep the context with the case. To show later which rule applied to a past case, store the context you used with the case.
The workflow keeps authority. Execution, permissions, payment limits and the audit record stay in your system.
Where Alvia fits. Read a value your team maintains in a database or configuration from there. Alvia holds the instructions that arrive as text, change over time and carry reasons. See Alvia compared with other approaches.

Build it with a coding assistant

Give a coding assistant this brief together with Build with an AI assistant:

Add Alvia to our refund routing step. When an approval instruction
changes, store it with the time it was given and the same scope:
organization_id "acme", application_id "refund-flow". At routing, ask
for the context that applies to the refund amount, attach it to the
case and have a model call pick one of our fixed routes from it. Keep
enforcement in our payment controls. On a 404, timeout or conflict,
hold the refund for review. Test a threshold change from $1,000 to
$500 with a $640 refund.