Memory, Identity, and Seeing What the Agent Did

Model context is not memory. It is a working set that vanishes when the session ends and that costs tokens on every turn it is carried. Agents that feel competent across days need something else, and AWS splits it the way the problem splits.

Short-term memory is the multi-turn conversation: what was said earlier in this session, what the last tool returned, what the user just corrected. Its job is coherence within a task.

Long-term memory persists across sessions, and AWS describes AgentCore Memory as supporting both, with stores that can be shared across agents and that let agents learn from experiences.

The distinction matters because the two have different failure modes. Short-term memory that grows unbounded becomes a token bill and eventually a context overflow. Long-term memory that grows unbounded becomes a retrieval problem, where the useful fact is buried among thousands of stale ones.

Key idea: the hard question in agent memory is never storage, which is cheap and solved. It is selection: what is worth keeping, and what should be retrieved into context now. Both are editorial decisions, and a managed service can hold the data without making them for you.

Writing every turn to long-term memory is the default and it is wrong, because recall quality degrades as the store fills with things that were never worth keeping.

A usable rule: store facts that will still be true and still be relevant next week.

That last exclusion is the one teams get wrong most often. If the current order status is in your database, an agent should call the tool, not recall a remembered value: memory of mutable facts is a cache with no invalidation, and it will confidently report yesterday's state.

Gotcha: shared memory across agents multiplies both the benefit and the blast radius. One agent writing a wrong or malicious fact means every agent sharing that store now believes it. Treat writes to shared memory as a privileged action, and prefer per-user scoping unless there is a reason to cross it.

Agent identity looks like ordinary service authentication until you notice the agent is acting for someone.

AWS positions AgentCore Identity as agent identity, access and authentication management compatible with existing identity providers including Amazon Cognito, Okta, Microsoft Entra ID and Auth0, explicitly so that adopting it does not require migrating users or rebuilding authentication flows.

Key idea: the correct posture is that an agent's authority is the intersection of what the agent may do and what the user it acts for may do, never the union. If a downstream system cannot tell which user is behind a call, it cannot enforce that intersection, which is the design consequence of the inbound-auth choice from the previous lesson.

When a conventional service returns the wrong answer, you read the code path. An agent's behaviour is not in the code: it is in a sequence of model decisions, each conditioned on a context you did not write directly, and the same input can produce a different path tomorrow.

That makes three questions unanswerable without recorded telemetry:

• What did it actually do? Which tools were called, in what order, with what arguments, and what came back.
• Why did it go that way? What was in context at the decision point, including which tools were even offered.
• Where did the time and money go? Which step dominated latency, how many model calls the task took, and how the context grew across them.

AWS describes AgentCore Observability as a unified view to trace, debug and monitor agent performance, with visualisations of each step, the ability to inspect the execution path and audit intermediate outputs, and telemetry emitted in OpenTelemetry-compatible format so it works with CloudWatch or an external stack.

In practice: the OpenTelemetry choice is the strategically important part, and it should be familiar from ordinary services. Standard telemetry means your agents appear in the same tracing tool as the rest of your platform, so an agent step and the API call it triggered sit in one trace rather than in two systems nobody correlates.

An agent trace is a tree, and its shape is the diagnosis. One user request is the root span; each model call and each tool call is a child, nested where one caused another.

Read that tree and the common pathologies are visible without reading a line of code. A long flat run of near-identical tool calls is a loop that failed to make progress. A step where latency dominates everything else names the slow dependency. A tool called with obviously wrong arguments points at its description rather than at the model. And a trace that reached the answer in three steps where yesterday's took eleven is the variance that makes averages misleading for agents.

Two practices make traces worth having. Record the context, not just the calls: knowing which tools were offered and what the prompt contained at a decision point is usually what explains the decision. And keep a per-task step and token count as a first-class metric, because the failure that costs real money, an agent looping until something stops it, shows up there long before anyone reports a bad answer.

Traces explain single runs. Knowing whether the agent is getting better needs aggregate judgement, and AWS layers two services onto the telemetry it already collects.

Evaluations is described as a purpose-built service for automated, consistent, data-driven agent assessment: measuring how well agents and tools execute tasks, handle edge cases and maintain output reliability across diverse inputs, operating on sessions, traces and spans from frameworks including Strands and LangGraph instrumented with OpenTelemetry or OpenInference.

Optimization builds on that, using AI-generated recommendations, versioned configuration bundles and A/B testing to improve agent performance, supporting system prompt and tool description optimisation with traffic splitting through Gateway.

The loop is coherent: instrument, evaluate against a fixed set, change one thing, split traffic, compare. Two cautions carry over from measurement disciplines the catalogue covers in depth. Agent evaluation is only as good as its evaluation set, which is a curated artefact somebody must own and refresh. And traffic-split comparisons are experiments, with all the machinery that implies, so the same peeking and sample-size rules apply here as anywhere else.

In practice: tool description optimisation is the highest-yield target on that list and the least glamorous. A large share of wrong tool calls trace back to a description that was written for a human skimming API docs rather than for a model choosing between forty options.

Closing the course by separating the two, because the boundary is what a platform evaluation actually turns on.

What AgentCore takes off your plate: session isolation and the microVM boundary, agent lifecycle and scaling, converting existing APIs into MCP tools, sandboxed code execution and browsing, credential storage and identity federation, memory infrastructure, and a standards-based telemetry pipeline. Each is weeks of work with real security consequences if done badly, and none of it differentiates your product.

What remains entirely yours: what the agent is for, which capabilities it should have and which it must never have, the prompts and control flow, what is worth remembering, whose authority each action carries, the evaluation set that defines "better", and the judgement about when a human belongs in the loop.

Key idea: managed platforms move the difficulty rather than removing it. Once infrastructure stops being the obstacle, the binding constraints become capability scoping, delegated authority and evaluation, which are design and product problems that no service can answer for you.

One last durable caution: this is a fast-moving product surface, and the specific service names and limits here will drift. The mechanisms will not. Isolation boundaries, the M by N problem, retrieval over tools, the distinction between an agent's identity and its user's, and the need for recorded traces are properties of the problem, and they will still be true whatever the console looks like next year.