NotiOps v1.0.19

NotiOps v1.0.19

This release makes long-term memory actually work. Two separate defects were
keeping it off, and each was silent on its own. The one-click CloudFormation
path never created the memory resource at all, and the code reacts to a missing
memory by continuing without one, so a one-click deployment simply never
remembered anything you had told it in an earlier session. Underneath that, on
both deployment paths, retrieval was discarding every memory it found because
of a relevance threshold set too high for the service's actual similarity scores
— so even the setup.sh path, which has had the memory resource all along, was
storing memories and then never using them. Both are fixed here. The remaining
change is smaller and just as practical: the invitation email a one-click
deployment sends you now contains the sign-in URL, not only a password with
nowhere to type it.

⚠️ Sample/reference code, not a production-ready product. Review it with your
own security, legal, and compliance teams before deploying into an AWS account.

Features

• Long-term memory on the one-click path — it was silently missing. The agent
  is built to remember across sessions through four AgentCore Memory namespaces:
  facts extracted from your conversations, preferences you state, a summary per
  session, and episodes. On the setup.sh path those were created for you. The
  CloudFormation template never created the Memory resource and never injected
  the MEMORY_NOTIOPSWEBCHATMEMORY_ID the agent reads — and an empty value is
  handled by returning "no memory" and carrying on: no error, no log line.
  The feature was absent and invisible at the same time, which is the worst
  combination.

  The template now declares an AWS::BedrockAgentCore::Memory with the same four
  strategies and the same 30-day event-expiry as the setup.sh path, an
  execution role for it, the retrieval and write permissions on the agent's
  runtime role, and a new MemoryId stack output so you can check the wiring
  yourself: the value must equal the MEMORY_NOTIOPSWEBCHATMEMORY_ID environment
  variable on the agent runtime. Extraction is asynchronous — after you state a
  preference, give it a minute or two before starting a new session to see it
  honoured.

  ⚠️ Who shares what. In this release the memory actor is one identity for
  the whole deployment (default-user), so facts and preferences extracted
  from any user's conversations are visible to every signed-in user of the same
  deployment. Session summaries and episodes stay within their own session, and
  chat history remains per user. This is the same on both deployment paths. If
  that is not acceptable for your users, deploy separate stacks. Note also that
  the Memory resource carries no retention policy: deleting the stack deletes
  it and everything accumulated in it.

• The invitation email now tells you where to sign in. A one-click deployment
  creates the admin user in Cognito, which emails a username and a temporary
  password. It did not include the address of the site those credentials are for
  — that was only in the stack's ChatUrl output, which the person who received
  the email frequently could not see. The email now has the subject
  Your NotiOps sign-in details and carries the clickable ChatUrl, the
  username, and the temporary password together. On the setup.sh path the
  deployment summary already printed the URL and the password side by side, so
  both paths now hand over the same three things.

Fixes

• Memory retrieval discarded everything it found — on both deployment paths.
  Each of the four namespaces was queried with a minimum relevance score of 0.5.
  Measured against a real deployment's own records, the service's similarity
  scores do not reach that: a stored preference scores ~0.72 against a near-verbatim
  restatement of itself, 0.41–0.49 against the natural question "what response
  format do I prefer?", and 0.33–0.39 against an unrelated question. Every real
  retrieval was therefore filtered out before it reached the model, and the SDK
  logs retrieved memories only when at least one survives the filter — so the
  symptom was an agent that had memories, found them, and then said it had none,
  with nothing at all in the logs.

  Lowering the number would not have fixed it. A stable preference such as "always
  answer briefly" has to apply to "how do I cut my EC2 bill?", a question with no
  semantic overlap with the preference text, and the gap between relevant and
  irrelevant scores is about 0.02 wide at that boundary — any threshold strict
  enough to filter noise also filters the case the feature exists for. The
  threshold is now off and top_k is the only bound (at most 3+3+5+3 short items
  per turn, ranked by the service). The agent also logs how many memory blocks
  each turn received, including zero, so this class of failure can no longer be
  invisible. This affects the setup.sh path too: re-run it to pick up the fix.

• The automated parity check had this gap recorded as intentional.
  scripts/test_oneclick_parity.py listed "the one-click path has no AgentCore
  Memory" as a deliberate difference, justified by a grep showing that no code
  read MEMORY_*. That grep covered core/ and agent/ — but not
  agent-build/, which is exactly where the code that reads it lives. The
  justification was wrong, and because it was written down as intentional, the
  check actively protected the gap. Two new dimensions now assert the memory
  wiring and the first-login handoff instead, and any future "intentional
  difference" has to be searched for across the agent build tree too.

• Three stale template-size figures in the documentation, two of them in the
  customer-facing one-click guide. The one-click guide also documents long-term
  memory properly now, including the sharing caveat above, what the four
  namespaces hold, the 30-day expiry, and that it goes away with the stack.

Upgrading

setup.sh:

git pull            # or re-clone at tag v1.0.19
./setup.sh          # re-run; existing resources are updated in place

This path already created the memory resource, but it needs this release for the
retrieval fix above — until you re-run setup.sh, memories keep being stored and
never used.

One-click (CloudFormation): download notiops-webchat.template.json from the
assets below and update your stack with it — Replace existing template, then
Use existing value for every parameter. The update adds two resources (the
Memory and its execution role) and three permissions on the agent's runtime role.
Your data is not touched: the conversation and configuration tables are Retain,
and re-seeding is idempotent. This upgrade does not resend the invitation email,
change the admin credentials, revert Admin settings, or clear chat history — and
the new invitation text applies to users created from now on, not retroactively.
An existing deployment starts with an empty memory; nothing is back-filled
from past conversations.

Do not mix assets across releases — the template and the four .zip files are
cryptographically bound (each checksum is baked into the template and the release
tag is part of every object key), and the stack verifies every checksum before
use.

Asset checksums (sha256)

d86bf4fab38cf40d28ff8ebe7fefae1ac9700b4d41978b9b4bc6af72ac083f3f  bff.zip
7ce8e996d48b1beefaa50636d151ca1c7f6382c51ded6ef5ba573ef3f0c50f02  chat-dist.zip
562440c873bbf88e558ffbf6ef4d8e3ad80204f4404b78a1d996da7167f5ef89  web-notif.zip
2a6f4b19ca77c461058fb813c3a050bbedae528c998db6995ded5b024cb23984  agent-code.zip

Download notiops-webchat.template.json only. The four .zip assets are
pulled into a bucket in your account by the stack itself; you never need to
download them by hand. The template is above CloudFormation's 51,200-byte
--template-body limit — from the CLI, upload it to S3 first and pass
--template-url.

See README for full setup, one-click deployment
for the console walkthrough, and the documentation for architecture
and operations.