The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Keep the model out of the identity business. An agent’s durable identity, meaning its instructions, permissions, authoritative memory, and history, should live in a governed state layer that the agent system owns. For each task, the system assembles a scoped, temporary context from that state and passes it to whichever model is configured. When you switch providers, you replace the inference component and keep the state. You still have to test the agent afterward, because portable state does not make two models behave the same.
What makes up an agent’s identity?
A persona string in a system prompt is only one small part of it. Microsoft Learn’s guidance on the AI agent shared responsibility model distinguishes a stateless prompt-and-response exchange from an agent that holds persistent memory, can influence future behavior across sessions or users, and can authenticate with its own identity and carry its own privileges. Once an agent can act through tools, what makes it the same agent from one session to the next is spread across several records.
![Claude AI for Beginners Bible: [5 in 1] The Ultimate Guide to Automate Your Work, Save Hours Every Week, and Use AI for Real-World Results](https://m.media-amazon.com/images/I/415+fSJacsL._SL160_.jpg)
| Layer | What it holds | Where it should live | Survives a model change? |
|---|---|---|---|
| Identity and instructions | Agent role, persona, behavioral rules, with version numbers | State layer | Yes, as stored data. How strongly the new model follows it must be tested. |
| Scoped memory | User facts, preferences, and prior decisions, each tagged with scope and provenance | State layer | Yes, if it can be exported and retrieved. The new model may use it differently. |
| Episodic history | Dated record of interactions and their outcomes | State layer (event history) | Yes, as records |
| Task state | Current goal, completed steps, pending approvals | State layer | Yes, as records |
| Permissions and credentials | Agent service identity, delegated tokens, tool scopes | Identity and secret management, outside the prompt | Independent of the model; governed separately |
| Reasoning behavior | How a given model interprets instructions and writes replies | Model | No. This is the part that changes. |
Why the context window cannot be the memory
The context window is the working input for a single model call. The Persistent Agentic Memory Architecture project, an evolving technical draft that is not an IETF standard or a published RFC, treats the context a model sees as a projection assembled for one operation. That projection can be truncated, reordered, transformed, or discarded. It therefore cannot be the only copy of anything you need to keep. The same draft defines persistent memory as addressable, machine-readable state retained beyond a single inference request.
The practical consequence is simple. If a useful fact exists only in a conversation transcript, a context overflow or a provider change can erase it. If the fact exists as a record with an identifier, the next call can rebuild the projection from it.
#1 Best Overall
How the layers fit together
Persistent state plane
This layer stores the authoritative identity and policy records, memory objects, their versions, scope, provenance, validation and lifecycle status, relationships between records, and an event history. Each memory should be traceable to the event that created it, carry an owner scope, show whether it has been validated, and point to any record that supersedes it. Writers can borrow the draft’s vocabulary for these fields, but the draft is a proposal, not a specification every vendor follows.
Compute plane
Inference, planning, orchestration, transformations, and tool execution belong here. Microsoft Learn calls the orchestration layer the “brain loop” and places planning, reasoning, tool selection, the system prompt and instructions, and multi-agent coordination inside it. The compute plane selects the current model and tools, requests the data it needs from the state plane, and performs the work. It should never become the only place where the agent’s truth is stored.
Rank #2
Context assembly
Context assembly builds the per-operation projection from approved identity instructions, relevant memories, current task state, and the tool results the agent is permitted to see. Use the state layer to rebuild that projection after a session reset or a model change. Log which record IDs and versions went into each projection. That log is how you answer the question every operator eventually asks: why did the agent say that?
Identity and authorization
Separate the agent’s service identity from the human user’s identity and from any delegated credentials. Scope access to the specific action and data required. Microsoft Learn identifies distinct agent identity and delegated tokens as concerns specific to agents. Two agents running on the same model still have separate permissions, so a shared model never implies shared authority.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Change control
Version the identity and memory schemas. Log every update and its provenance. Keep a rollback or review path, validate imported or generated memories before they are used, and re-run representative tasks whenever the prompt compiler, memory policy, tools, or model changes. The architecture sources support the need for these controls. The evaluation step is a recommended practice derived from those requirements, not a published standard.
What happens on each turn
- Authenticate the caller, and resolve the agent’s service identity and the user’s scope.
- Load the active identity record at its pinned version, not the newest unreviewed draft.
- Retrieve only memories whose scope matches this user, tenant, and project and whose validation status is accepted.
- Add current task state and any tool results the agent is allowed to see. Label retrieved documents and tool outputs as data, not as instructions.
- Assemble the projection and record the record IDs and versions used.
- Send the projection to the selected model. Apply step, loop, and budget limits to every tool call the model requests.
- Write the response, tool outcomes, and any new memory candidates back to the state layer as events with provenance. New memories stay pending until they are validated.
Memory or system prompt: where each piece belongs
| Content | Where it goes | Reason |
|---|---|---|
| Stable role, tone, and behavioral rules | Identity and instructions record, versioned | Changes should go through review and get a new version number |
| A user’s stated preference or fact | Scoped memory with provenance | It must be attributable to its source and deletable |
| What happened in earlier sessions | Event history and episodic memory | Keeps the detail without bloating every prompt |
| Current goal and progress | Task state | Lets a different model resume the work |
| Credentials, tokens, and API keys | Identity and secret management systems | Should never appear in prompt text |
| Retrieved documents and tool output | Per-call projection, labeled as untrusted data | May contain instructions the agent should not obey |
Does a portable identity keep the agent the same?
Not by itself. Portability asks whether you can move the state to another provider or runtime. Equivalence asks whether a different model produces the same behavior from that state. These are separate claims, and only the first is supported by the architecture described above.
The clearest academic example of identity tied to action is PersonaAgent, described in the 2026 Findings paper “PersonaAgent: Bridging Memory and Action for Personalized LLM Agents” in the ACL Anthology. The framework separates episodic memory for detailed interactions from semantic memory for stable profiles. It maintains a user-specific system prompt that evolves from user data and action outcomes. The paper is an example framework. It does not show that a persona stays unchanged across model providers.
Safety boundaries that travel with the agent
Microsoft Learn’s guidance on agent security gives a starting set of controls:
Best Value
- Limit instructions and scope to what the agent’s role requires.
- Treat retrieved documents, tool outputs, and messages from other agents as untrusted input.
- Add step, loop, budget, and tool-chain guardrails, along with planning guardrails.
- Keep tool permissions in the identity layer. Changing the model should not change what the agent is allowed to touch, and a prompt instruction is not an access control.
How to evaluate a runtime or memory platform
Compare real options along these axes rather than on the word “memory” alone.
| Axis | Questions to ask | Evidence to look for |
|---|---|---|
| Portability | Can authoritative state be exported, inspected, and used with another provider or runtime? | A documented export format and a tested import path |
| State semantics | Are identity, user memory, task state, provenance, lifecycle, and validation separate and versioned? | Schema documentation that names each field |
| Security boundaries | Are user, agent, tool, tenant, and project scopes explicit? Are credentials and tool permissions governed independently? | A documented scope model and separate permission settings |
| Audit and correction | Can you trace where a memory came from, revise or supersede it, and see how it entered a model context? | Event log entries and projection logs that record record versions |
| Runtime integration | Which orchestration, tools, model routing, recovery, and deployment environments are supported? | Verification in your own deployment, not only vendor descriptions |
| Operational control | How are cost, access, safety policy, and model lifecycle managed? | Admin controls and usage reporting you can test yourself |
| Behavior after migration | Does the new model keep instruction adherence, retrieval accuracy, task completion, privacy boundaries, and refusal or escalation behavior? | Results from your own representative task set |
Two vendor products illustrate the category. Both descriptions are vendor claims, not independent evidence of outcomes:
- Persistent Systems describes its Core offering, in “AI Infrastructure for Scale | Secure, Governed Core Layer,” as an abstraction layer with model management and routing, agent runtimes, security, identity, governance, and cost controls.
- PersistentAI’s introductory documentation, “PersistentAI Intro,” describes a flow-based framework with templates, model calls, tools, and MCP integrations, and states that it supports any LLM provider. Verify provider support for your own models before relying on it.
Procedure: swapping the model under a live agent
- Freeze the baseline. Record the active identity record version, memory schema version, prompt compiler version, and the tool list.
- Build a representative task set from real workflows. Include tasks that depend on remembered user facts, multi-step tool use, a privacy-sensitive request, and a request the agent should refuse or escalate.
- Run the task set on the current model and save the outputs and projection logs.
- Change only the model in the compute plane. Keep identity, memory, and tools constant.
- Re-run the same tasks and compare results on instruction adherence, retrieval accuracy, task completion, privacy boundaries, and refusal or escalation behavior.
- Promote the new model only for the task categories where it meets your thresholds, and keep the previous model configured as a rollback.
No standardized benchmark covers this comparison, so the team that owns the agent must set the pass thresholds.
Quick Recap
Troubleshooting: the agent changed after a switch
| Symptom | Likely cause | Check |
|---|---|---|
| Tone or persona drifts toward the model’s defaults | The new model weights the persona instructions differently | Compare the assembled projection with the baseline. Tighten the identity instructions, then re-run the test set. |
| Forgets facts that were stored | Retrieval filters exclude the records, or the memory was never written | Check the projection log for record IDs. Verify scope tags and validation status. |
| Follows outdated instructions | A stale identity version is pinned or cached | Confirm that the version in the projection log matches the intended release. |
| Shows information from another user or project | A scope boundary failed during retrieval | Audit the retrieval query and its provenance. Keep the agent in a restricted mode until scope filtering is corrected. |
| Repeats tool calls or runs for too many steps | Step, loop, or budget limits are missing for this model | Confirm the guardrails apply to every model in use. |
| Refuses or escalates differently | The new model’s refusal behavior differs from the old one | Compare against the refusal category in the test set. Change policy only as a versioned update. |
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Recommended Free Tools
