A sneaky rule change has the potential to blow up scientific research in the United States. But there's still time to fight it.
On May 29th, the Office of Management and Budget (OMB) issued a 412-page proposal to revise federal financial assistance. The language is a combination of distinctly Trumpian attacks on "woke" policies and boring governmentese designed to make your eyes glaze over as quickly as possible. But under phrases like "providing further clarification on the regulatory status of the OMB requirements" is something darker - a threat to scientific research in this country, the livelihoods of thousands of scientists, and the li …
The following article originally appeared on Angie Jones’s LinkedIn page and is being republished here with the author’s permission.
I’m fascinated by the concept of agent memory. LLMs are stateless by design, meaning they have no memory or awareness of past interactions. Each prompt you send to an LLM is treated as a completely isolated event.
When you have a continuous chat with an AI agent, it feels like the AI remembers previous messages. However, the interface itself is faking it. Behind the scenes, your agent takes the entire conversation history and resends all of it to the LLM as one giant, combined prompt.
Companies, researchers, and even indie devs are all trying to crack agent memory. Because once an agent can remember, the entire interaction changes. It can build on what it learned, adapt to the user, resume work after a restart, and develop a sense of continuity.
Recently, I spent time with Richmond Alake, who has been in the trenches working on agent memory at Oracle.
Richmond Alake, the agent memory guru
We talked about the different kinds of memory, why memory is harder than it sounds, and what it takes to build a memory system that is actually useful in production.
That conversation made something very clear to me. When people say, “agent memory,” they often mean very different things.
So let’s unpack the various types of memory.
Conversational memory
Conversational memory is the one most people think of first. It stores the messages exchanged between the user and the assistant.
This makes sense. If I ask, “What did I say was the ultimate goal of this task?” the agent needs access to the conversation in order to answer. Without that history, every turn starts from zero.
But this is also where many memory systems go wrong.
The most common first attempt is to keep appending prior messages to the prompt. For example:
User: I’m building a customer support agent.
Assistant: Great, what should it do?
User: It should look up past tickets and draft replies.
Assistant: Got it.
User: Also, I prefer Python and FastAPI.
Then on the next call, we send all of that back to the model along with the new question.
This works for a short conversation, but the agent only “remembers” because we keep reminding it. This is not really memory engineering.
Eventually, the conversation gets too long and the model receives a giant blob of context where some details are important, some are stale, and some are completely irrelevant. The agent may technically have the information, but that doesn’t mean it can use it well.
So yes, conversation history is a valid and important type of memory. But it shouldn’t be the whole memory strategy. Real agent memory requires deciding what should be stored, where it should be stored, how it should be retrieved, and when it should be summarized, forgotten, or compressed.
Semantic memory
Semantic memory stores durable facts.
These are things that should outlive the exact conversation where they were learned:
The user prefers Python over TypeScript for backend work.
The customer support agent needs access to past tickets.
The production system handles 50,000 queries per day.
This is different from conversational memory because the exact wording and sequence are less important. What matters is the meaning.
If the agent needs to recall what stack the user is using, it should retrieve the memory even if the user never says those exact words again.
Vector search is useful for this. The memory can be embedded and retrieved by semantic similarity.
The benefit is that the agent doesn’t need to replay the full conversation. It can retrieve the few durable facts that are relevant to the current request.
Episodic memory
Episodic memory stores events.
This is the “what happened” layer of memory:
The agent searched the web for recent API gateway patterns.
The agent generated a draft response for ticket #4821.
The workflow failed at the compliance review step.
Episodic memory is especially useful for debugging, auditing, and long-running workflows.
For example, if an agent makes a decision, I may want to know what happened right before that decision (e.g., What tools did it call? What data did it retrieve?).
This type of memory often benefits from structured storage.
For example:
Find all failed tool calls from the mortgage approval workflow in the last 24 hours.
That is a database query problem, not just a vector search problem.
Procedural memory
Procedural memory is about how to do things.
For example:
When investigating a failed deployment, check logs first, then recent config changes, then dependency updates.
When drafting a customer support reply, include the ticket summary, likely cause, recommended fix, and next step.
When creating a database-aware agent, scan table comments, column comments, constraints, and recent workload patterns.
This is the kind of memory that helps an agent improve its process. That’s powerful because agents are often asked to operate in messy real-world environments. With procedural memory, it can reuse proven approaches.
The value extends beyond just knowing things to actually knowing how to proceed.
Entity memory
Entity memory stores facts about specific people, accounts, projects, systems, tickets, or objects.
For example:
Angie prefers practical examples over abstract explanations.
Customer Acme Corp has strict data residency requirements.
Ticket #4821 is related to a billing reconciliation issue.
Entity memory matters because many agent tasks are scoped around a particular thing.
If I ask, “What do we know about Acme Corp?” I don’t want every memory in the system. I want memories attached to that customer.
This is also where memory safety becomes important.
Agents should not accidentally mix memories between users, customers, or projects. A memory system needs strong scoping so one user’s context does not leak into another user’s response.
Working memory
Working memory is the short-term scratchpad for the current task.
This is where the agent keeps temporary information while reasoning through a problem.
Working memory is usually not meant to last forever. It’s useful during the task, but it may not deserve to become durable memory.
If an agent stores every temporary thought as long-term memory, the memory store gets noisy very quickly. The agent may later retrieve half-baked assumptions as if they were facts, which is dangerous.
Not everything the agent observes or thinks should be remembered permanently.
Summary memory
Summary memory is one many agent users are familiar with. It deals with the problem of context windows being limited.
Even with large context models, you can’t keep appending forever. At some point, you need to compress.
Summary memory stores a compact version of a longer thread or context window. The original details can still live in the thread, but the prompt gets a smaller representation.
For example, instead of sending 80 turns of conversation, the agent might send:
The user is building a SaaS customer support agent. They prefer Python and FastAPI, deploy on OCI, and want the agent to retrieve past tickets before drafting replies. They are currently evaluating memory strategies for production usage.
Why memory is hard for agents
At first, memory sounds straightforward: store things, retrieve them later.
But the hard part is judgment, not storage.
What should be remembered? If the user says, “I usually prefer Python,” that’s probably worth remembering. If they say, “Let’s try Python for this one experiment,” maybe not. The agent needs to distinguish durable details from temporary context.
When should memory be updated? People change their minds, and systems and requirements change. If a user used to prefer FastAPI but now works mostly in Java, should the old memory be deleted, overwritten, or kept with a timestamp? A memory system needs a correction strategy.
How much memory should be retrieved? Retrieving too little means the agent misses important context. Retrieving too much means the prompt becomes noisy. This balance matters as more context isn’t always better.
How do we prevent memory leaks? If memories are shared across users, agents, or tenants, scoping is critical. The agent should only retrieve memories it’s allowed to use. This is especially important in enterprise systems where agents may operate across many customers, teams, or workflows.
How do we know whether memory helped? Memory should improve the agent’s behavior. It should reduce repeated questions, improve continuity, lower token usage, and help the agent produce more relevant responses. If memory just adds complexity without improving outcomes, it isn’t doing its job.
How Oracle is approaching agent memory
Richmond was gracious enough to share how Oracle is tackling this with the Oracle AI Agent Memory Package (OAMP), built on top of Oracle AI Database 26ai.
Yes, an AI database! Think of it as a database that can store and query the kinds of data AI applications need, not just rows and columns. That includes embeddings and JSON documents along with text search and regular SQL. These live together in the database, so an agent does not have to bounce between separate systems just to gather context.
The idea is to make Oracle AI Database the memory core for agents. Instead of stitching together a vector database, a relational database, a document store, and custom thread management, OAMP provides agent-friendly memory primitives on top of a database that already supports multiple data access patterns.
At a high level, OAMP gives you:
Users and agents to scope memory ownership
Memories for durable facts and extracted knowledge
Threads for conversation history and continuity
Context cards for compact, prompt-ready memory retrieval
Summaries for long-running conversations
Vector search for semantic recall
Database-backed persistence so memory survives restarts
This matters because, again, agent memory is not only a vector search problem. Some memory needs semantic retrieval. Some need ordered reads or exact SQL filtering. A database-backed memory system gives you room to support all of those patterns.
Here’s a small example of what that looks like in code:
from oracleagentmemory.core import OracleAgentMemory
from oracleagentmemory.core.llms import Llm
client = OracleAgentMemory(
connection=connection,
embedder="text-embedding-3-small",
llm=Llm("gpt-5.5"),
extract_memories=True,
schema_policy="create_if_necessary",
)
client.add_user(
"angie",
"Developer exploring agent memory patterns."
)
client.add_agent(
"memory-demo-agent",
"Assistant that demonstrates Oracle AI Agent Memory."
)
client.add_memory(
"Angie is fascinated by agent memory and prefers practical examples over abstract explanations.",
user_id="angie",
agent_id="memory-demo-agent",
)
There are a few important ideas packed into this snippet.
The OracleAgentMemory client is the bridge between the agent application and Oracle AI Database. The database connection tells OAMP where memory lives. The embedder tells it how to turn memory text into vectors for semantic retrieval. The LLM enables automatic memory extraction and summary generation. And schema_policy="create_if_necessary" lets OAMP manage the underlying memory schema instead of making every application reinvent it.
The user and agent registration may look like simple setup code, but it’s actually part of the memory model. Memories need ownership. In a real system, you don’t want one user’s preferences showing up in another user’s session, and you don’t want memories written by one agent casually mixed with another agent’s context. The user ID and agent ID give the memory layer a way to scope what gets stored and retrieved.
The add_memory() call stores a durable fact. This is a piece of information the agent may need later, even if the exact conversation has moved on.
Given this, we can now recall memories.
results = client.search(
"how should I explain this topic to Angie?",
user_id="angie",
max_results=3,
)
This search() call shows the part that makes semantic memory useful. The query doesn’t have to match the stored sentence exactly. We stored that I prefer practical examples, but we searched for how to explain something to me. Those are different words but related in meaning. That’s the point.
Threads and context cards
Durable memories are only part of the picture. Agents also need conversation continuity.
With OAMP, a thread can represent a real work session, such as an agent helping investigate a production issue:
from oracleagentmemory.apis.thread import Message
thread = client.create_thread(
user_id="angie",
agent_id="support-triage-agent",
)
thread.add_messages([
Message(
role="user",
content="Customer Acme Corp is seeing intermittent checkout failures after the latest deployment.",
),
Message(
role="assistant",
content="I'll check recent deployment notes, related incidents, and payment service logs.",
),
Message(
role="user",
content="Focus on the payment gateway first. We saw similar timeout errors last quarter.",
),
])
This is much closer to how memory shows up in real agent applications. The useful context is not just that messages were exchanged. It’s that this thread is about Acme Corp, checkout failures, a recent deployment, the payment gateway, and a related incident from last quarter.
When it’s time to call the model, instead of passing the entire raw thread, you can ask for a context card:
card = thread.get_context_card()
The context card gives the agent a compact block of relevant memory to use in the next prompt.
Conceptually, the prompt becomes:
System: You are a helpful assistant. Use the provided memory context.
Memory context: [context card]
User: What did we decide earlier?
This is a much cleaner pattern than appending every message forever.
Automatic memory extraction
OAMP can also extract memories from conversation.
For example, if the user says:
I prefer Python over TypeScript for backend work. I usually deploy FastAPI apps on OCI behind an API gateway.
The memory system can extract durable facts such as:
The user prefers Python over TypeScript for backend work.
The user deploys FastAPI applications on Oracle Cloud Infrastructure behind an API gateway.
That means the application does not have to manually call add_memory() for every useful fact.
This tells the system to periodically inspect recent messages, extract durable memories, and maintain a running summary.
Here is where agent memory starts to feel more like a living part of the agent architecture vs just a data structure.
Teaching an agent about a database
One of the most interesting examples Richmond and I discussed was using memory to teach an agent about a database.
Imagine an enterprise data agent that needs to answer questions about a schema it has never seen before. Instead of fine-tuning a model, the agent can scan the database catalog and store what it learns as memory.
It might inspect:
ALL_TABLES for table names and row counts
ALL_TAB_COLUMNS for column names and types
ALL_TAB_COMMENTS for human-written table descriptions
ALL_COL_COMMENTS for column descriptions
ALL_CONSTRAINTS for primary keys and foreign keys
V$SQL for recent workload patterns
Then it can convert those technical details into natural-language memories.
For example:
Table SUPPLYCHAIN.VESSELS stores individual ships owned or operated by carriers. It includes vessel identifiers, carrier relationships, and operational metadata.
Now when a user asks:
Where would I find information about ships and carriers?
The agent can retrieve the relevant schema memory by meaning.
This is a beautiful pattern because it avoids one of the common traps with agents expecting the model to already know your private system.
It doesn’t. And that’s okay.
You can teach it by turning your system’s metadata into memory.
The more I learn about agent memory, the more I believe this will be one of the defining pieces of agent architecture.
Tool calling lets agents act. Planning lets agents decide what to do. Memory lets agents build continuity.
With memory, we can start designing agents that feel less like one-off prompt responders and more like persistent collaborators.
Of course, this also raises the bar. Memory has to be scoped, auditable, correctable, and intentionally retrieved. Bad memory is worse than no memory. So the challenge is not simply giving agents memory but giving them the right memory architecture.
Oracle’s OAMP approach is one way to make that system concrete: users, agents, memories, threads, context cards, summaries, and database-backed retrieval.
And while the implementation details matter, the bigger idea is that if we want agents to be useful beyond a single prompt, they need a way to remember.
Not everything. But enough to carry context forward.
Local news is disappearing. Since 2005, the United States has lost nearly 3,500 newspapers. 213 counties have no local news outlet at all and another 1,524 have just one. Newsrooms continue to shrink, close, and merge, often with no plan in place for the long term preservation and access of their archives. Online content that continues to be published by newsrooms is also at risk. According to the Pew Research Center, 38% of webpages that existed in 2013 are already gone and nearly a quarter of news webpages contain at least one broken link. The local record of our communities is vanishing in real time.
This urgent challenge is what brought two very different professions together on June 17 in National Harbor, Maryland. Hosted by the Internet Archive with the Poynter Institute and Investigative Reporters and Editors (IRE), the National Summit on Local News Preservation gathered journalists, editors, archivists, librarians, and researchers to start a conversation between the newsrooms producing local journalism and the memory institutions preserving it. This event was a part of the Today’s News for Tomorrow (TNT) program, an Internet Archive initiative supported by a grant from Press Forward. The program provides training, tools, and support directly to up to 300 newsrooms nationwide and helps develop collaborative partnerships between archives and news organizations.
Librarians and archivists understand what’s at stake and have been working to address these challenges for a long time. Local news supports a range of information needs for the historians, scholars, students, and citizens they serve. Frequent updates, complex multimedia content, and paywalls are just some of the obstacles they face when working to capture online news while still stewarding decades of journalism produced on physical formats. Journalists also understand how valuable their work is as a record of the communities they cover. Faced with reduced staffing and shrinking budgets, they are forced to focus on tomorrow’s deadline, not who will need access to this story fifty years from now. While the challenges and urgency are well understood by both sectors, there are few models for working together to address this crisis. Taking steps towards developing an actionable plan was the purpose of the Summit.
Panelists Randa Cardwell (Photojournalism Archive Project), Becca Bender (Rhode Island News Media Archive), Stephanie Jenkins (Archival Producers Alliance), Cassidy Meurer (University of Louisville), and Frank LoMonte (CNN) discuss the particular challenges of preserving TV news and photojournalism.
The day mixed expert panels with structured discussion. Panelists tackled hard questions: conflicts over rights and revenue, how to connect communities to archived news, and how libraries and newsrooms can realistically partner together. One panel focused on the particular difficulty of preserving local TV news and photojournalism. Case studies were shared from the professionals doing this work right now in newsrooms, public libraries, state libraries, non-profits, and research groups.
An attendee reports out on their group’s discussion
Then attendees worked together in breakout discussion groups built around five topics: Access and Discovery; Infrastructure and Technology; Organizational Culture and Partnerships; Rights, Revenue, and the Public Good; and Sustainability and Advocacy. Each group named the obstacles in their area and drafted short and long term recommendations aimed at addressing them. Common themes emerged from across all of the groups. Several groups advocated for immediate action across both types of organizations stating that holding out for perfect standards or reliable national infrastructure would result in more information loss. Groups also kept returning to a point that publishers may find counterintuitive: making an archive discoverable and freely accessible tends to directly benefit newsrooms. And more than one group, working separately, proposed the same ambitious idea: a Report for America style fellowship that places archivists inside newsrooms to develop preservation plans and workflows that can be embedded into core operations. Those are just a few of the ideas that came out of the event. Later this summer, a full report will be published and shared widely.
A group of attendees discuss organizational culture and partnerships
As some publishers block the preservation of their websites and local newsrooms continue to shrink, this work has never been more urgent. But the stakeholders who can do something about ensuring that local news persists, that it continues being produced and preserved, are thinking big and taking action. Many of them spent June 17 in National Harbor, working together towards a future where local news isn’t at risk of vanishing.
At Microsoft, we are committed to our customers’ fundamental right to privacy. In a world defined by rapid technological change and geopolitical volatility, this commitment has remained constant. It’s rooted in decades of experience building trusted technologies that our customers rely on every day to manage their data. Many of these organizations depend on the ability to move data across the Atlantic, from the EU to the U.S., in a way that protects their privacy. That’s why we support the European Commission in its defense of the EU-U.S. Data Privacy Framework. And that’s why we have formally intervened in the Latombe v. Commission case before the Court of Justice of the European Union. This case puts at stake two principles that are important for Microsoft – the protection of our customers’ privacy and their ability to do business on both sides of the Atlantic.
To intervene in a case before the Court of Justice, a company must apply for permission. In this case, the Court granted our application, finding that Microsoft has a direct and existing interest in its result. Put simply, the outcome of this case will determine whether Microsoft and its enterprise customers may continue to use the EU-U.S. Data Privacy Framework to transfer data to participating U.S. companies, including vital customers and suppliers. This critical legal bridge promotes stability, beneficial trans-Atlantic ties, economic growth, and prosperity, while upholding strong privacy safeguards. The Latombe case seeks to dismantle it. As an intervener, we can now file legal briefs in support of the European Commission, participate in oral hearings, and share our perspective on the importance of upholding a framework that directly benefits the European economy.
Supporting the European Commission’s adequacy decision on the EU-U.S. Data Privacy Framework before the Court of Justice of the European Union
Companies across the globe rely on data flows to manage their people, produce their goods and services, and distribute products to their customers. We understand that data flows trigger questions about differences in legal traditions. They should. And for that reason, the European Commission and the U.S. administration worked diligently, in the decade since the Safe Harbour ruling, to harmonize EU and U.S. law. As a result of that hard work, and as required under the European General Data Protection Regulation (GDPR), the U.S. has now created an independent review court for any complaints regarding U.S. surveillance and implemented other required measures to provide an “adequate” level of data protection that is essentially equivalent to that in the EU.
This equivalence is a key point. The law entitles our customers to privacy on both sides of the Atlantic. This is the principle on which the Data Privacy Framework rests. And our intervention in the Latombe case is just one part of a long history in which we have stood up for that principle in Europe, as well as in the U.S. As far back as 2014, Microsoft challenged the FBI’s secret attempt to use its national security authorities to obtain information about an account that belonged to one of our enterprise customers. After we filed the case, the FBI withdrew its request. In 2016, we sued the U.S. government to challenge its practice of seeking indefinite secrecy orders—i.e., orders that prevented Microsoft from ever notifying its enterprise customers when the government sought their data. As a result of that case, the U.S. Department of Justice changed its policy to place strict limits on the duration of secrecy orders. In the decade since that first constitutional challenge, we’ve launched a series of successful court challenges to ensure that secrecy orders, of any duration, are the exception, not the rule. As a result of our litigation, numerous secrecy orders have been vacated or modified to allow notification to our customers.
We don’t confine our advocacy to courts. We are a steadfast proponent of strong privacy regulation on both sides of the Atlantic. That’s why we are specifically pushing Congress to update the U.S. Electronic Communications Privacy Act to place stricter limits on the use of secrecy orders and ensuring they are subject to meaningful judicial review. This legislative reform is gaining momentum in Congress and will greatly enhance our continued ability to protect our customers’ data.
Stable and trusted data transfers are not an end in themselves. They are a means to enable innovation, economic opportunity, and public services—while upholding the fundamental rights that are at the core of EU and U.S. law. Our intervention in the Latombe case reflects that principled balance and follows a long line of legal actions we have taken to protect our customers.
Looking ahead
At Microsoft, we have long recognized that trust is not a given—it is earned through sustained action, thoughtful design, and a willingness to engage openly with governments, customers, and individuals. Microsoft has consistently advocated for strong, clear, and globally interoperable privacy frameworks, recognizing that trust in technology depends on the strength of the rules that govern it.
Our customers in Europe can rely on us to continuously improve and update our privacy practices as technology and legal standards evolve. In 2018, we were the first major technology company to extend GDPR subject matter rights to all our customers around the world. And recent positive assessments of our privacy compliance by the European Data Protection Supervisor and the Hessian DPA in Germany underscore our continuous commitment to our customers’ fundamental right to privacy.
In support of this work, we’ve updated the Microsoft Privacy Statement to use clearer structure, simplified language, and more precise explanations of our data practices—making it easier to understand what data we collect and how it’s used, without changing our underlying privacy protections or commitments.
The future of technology will be shaped not only by what we build, but by the principles that guide us. By grounding innovation in respect for people and organizations, and strong legal protections, we can help ensure that technology continues to be a force for good.
Wes, Scott, and CJ break down the latest web dev news. From AI agents and coding tools to Deno Desktop, Nub, and predictive UX. They also discuss bot-filled social media, remote work debates, and a slick 3D bookstore experience.
Gunnar Fischer: Accepting Not Being Accepted—The People-Pleasing Trap That Broke a Scrum Master
Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.
"I accepted not being accepted, and that was a big failure." - Gunnar Fischer
Gunnar's biggest failure wasn't a single bad decision—it was an attitude he carried into work for far too long. As an Agile coach and Scrum Master, he watched a new high-ranking manager arrive who didn't like the team, didn't respect them, never even officially introduced herself. And Gunnar did the worst possible thing: he played along. He did the people-pleasing dance without ever getting feedback, recognition, or even a basic conversation. He formed ideas as a team, did the work, asked for nothing back—and accepted that nobody looked at the work. In hindsight, the Scrum value of respect was the missing piece. "The members of a Scrum team respect each other to be capable, independent people, and are also respected as such by the others." Gunnar respected others. He did not demand that respect for himself. The wake-up came in Ecuador—swimming with sharks in the open sea, he realized he felt safer there than in his own office. So he updated his CV, took an internal switch, and finally stepped out of victim mode. His real insight is uncomfortable: if you read about something good—getting time for your own development, being heard, being respected—and you instinctively deflect it or make excuses for why you can't have it, that's a very clear indicator you've internalized being small.
Self-reflection Question: When was the last time someone described a healthy professional environment to you, and you found yourself making excuses for why you couldn't have it?
[The Scrum Master Toolbox Podcast Recommends]
🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥
Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.
🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.
Gunnar is the leader of the Chocolate Guild. Agile practitioner with a software developer background and a strong interest in people, intercultural contacts and the bigger picture. Gunnar's purpose is to teach and to learn, to grow as a person and to support others who want the same.
Log in
