UAT scenario builder
About this agent
The output is written for the person who signs off the release — a product owner, business user or domain expert who has never read the code. Scenarios are in business language; implementation detail lives in `tracesTo`, which nobody executing a scenario reads, and generated scenarios are scanned for leaked code identifiers so anything suspicious lands in `reviewFlags`. Acceptance testing is organised around who is doing the work, so personas are discoverable from the system itself before a plan is written — conservatively, since a plan written for roles the system does not have covers behaviour nobody has. Scenario ids stay stable across refinement, because a UAT id may already be printed on a signed checklist.
What changed with Zenmem?
The same agent, built twice against the same contract — once on Zenmem, once on MongoDB + LangChain/LangGraph.
Before → after
Before With Zenmem
What the team gained
- Personas are discovered by querying the indexed system rather than assumed, so a plan covers roles that actually exist.
- Every scenario's `tracesTo` comes from the same retrieval that produced it, so the traceability matrix is a by-product rather than a second artefact to maintain.
- Business-language output and code-level evidence live in one document without two stores to reconcile.
- A refinement thread is a session id, so scenario ids stay stable across a conversation that may span a signed checklist.
- A system with no role distinctions returns one persona, because an empty result is allowed to be empty.
How memory is scoped
Two scopes. The workspace knowledge base is the long-lived one — the indexed codebase that personas are discovered from and every scenario traces back to. A session is the refinement thread over it: generation or chat allocates one, follow-ups on the same id resolve against what was already said, and closing it is terminal.
How it works
The run order the collection walks through.
Discover the personas
Roles read from the system rather than assumed. No role distinctions returns a single persona instead of an invented cast.
Generate in business language
Scenarios a non-technical signer can execute; code identifiers that leak in are flagged for review.
Keep ids stable
A scenario id may already be on a signed checklist or in a defect ticket, so refinement never renumbers.
Export for the session
A printable checklist with pass/fail/blocked boxes and a signature block, ordered by business impact — plus a pivotable traceability matrix.
API surface
The whole agent, endpoint by endpoint.
Endpoints
- GET /health — liveness, plus whether Zenmem is reachable.
- GET /api/v1/workspaces/{workspaceId}/status — knowledge base readiness and the indexed file list. Always 200.
- GET /api/v1/workspaces/{workspaceId}/personas — which roles the system actually recognises. Worth calling before generating.
- POST /api/v1/uat/generate — the main route: a feature in business words, a depth, and optionally the personas to restrict to.
- POST /api/v1/uat/refine — adjust a plan in place with stable scenario ids.
- GET /api/v1/plans/{planId} — one plan in full.
- GET /api/v1/workspaces/{workspaceId}/plans — every plan for a workspace.
- GET /api/v1/plans/{planId}/export — sign-off checklist, traceability matrix, Markdown, Gherkin or CSV.
- POST /api/v1/chat — ask about acceptance coverage in business language, without generating a plan.
- POST /api/v1/sessions/{sessionId}/close — end a refinement thread.