External agents

Memory for the agents that answer your customers.

An external agent runs in production, in front of a customer. It answers a request, calls your tools, and closes the conversation. Stash captures those runs, refines them into context, and serves that context back before the next answer.

This page explains why production agents need a memory layer, and what Stash does about it. For the agents your own team runs, see internal agents.

Why production agents need memory

An agent in production repeats its errors. Every conversation starts with no record of the last one, so the same wrong answer comes back in a different ticket a week later.

The problem is harder than it looks:

• A prompt is not a memory store — corrections get appended to a system prompt until it is thousands of tokens long and nobody knows which line is still load-bearing.
• Similarity is not relevance — “what did this customer agree to last spring” needs reasoning about time and scope, not the nearest vector.
• Facts arrive disconnected — one run learns the part number, another learns the warranty rule. The agent has to join them to answer at all.
• Context is not global — the same fact means different things for different customers, and one customer's context must never reach another one's answer.

The correction loop

Each production run produces a log. Stash refines the log into a document, and the next run reads the document before it answers. No prompt is edited and no deploy is needed.

# run 1841
request   part for unit 44, under warranty
answer    wrong part number returned
operator  supplied the correct SKU

# refine
→ parts/lookup-rules.md updated
→ skill: warranty-check created

# run 1842
› read parts/lookup-rules.md
✓ correct part returned, no escalation

What gets written

A correction becomes a page. Work that repeats becomes a skill: a folder with a SKILL.md and the files that support it, which the agent loads on the next run.

Recall

Recall returns the smallest set of facts that changes the answer. Two properties decide whether it is correct.

Permission and isolation

Memory that crosses a tenant boundary is a security incident, not a bad answer. Stash scopes every memory to an owner and resolves permission at read time, using the access controls that databases have had for decades.

• Scoped by default — a memory belongs to one owner. Sharing is explicit.
• Resolved at read — the agent sees only what the caller is allowed to see.
• Deletion propagates — removing a source removes what was derived from it.

Audit

Every run is legible after the fact: the context the agent read, the tools it called, and the answer it gave. Each change to the memory keeps its origin, so a correction can be traced to the run and the person it came from.

Run Stash on your own Postgres, inside your own network. The code is MIT licensed, so nothing about the memory layer is a black box.

Next steps