by EVE Online Team11:00am on Tuesday 29th September 2026
As a part of the EVE Evolved initiative, work continues to upgrade EVE Online’s client and server from Python 2 to Python 3. This work is important to ensure we are building on a solid foundation and to set us up for many more years of future development.
This installment of EVE Evolved examines NPC agent memory, both how it manages the bureaucracy of tracking the ~100,000 missions given out every day, and some of the interesting challenges it poses, that might affect players in the future.
In this blog “agent” refers to the NPC agents that inhabit EVE: those lovable characters that (sometimes rudely) ask you to haul their trash to another station, eliminate the latest pirate threat, or yet again save that poor Damsel, in exchange for a reward.
Because you all love a good technical deep dive, we will soon get quite detailed. But for anyone who just wants the TL;DR, here are the key takeaways:
As part of the modernization of EVE Online through upgrading to Python 3, changes need to be made to the way data for NPC agents is stored. Behind-the-scenes upgrades will be made to the way missions and other interactions with agents are tracked. This requires clearing out some old data and converting what remains into a more future-proof form.
This process will mostly be invisible. The only noticeable impact should be on what happens to old mission progress that was saved prior to 29 September 2026.
Your NPC standings are safe, and any agents that you have unlocked will continue to be available, even if you do not log in or are not currently Omega. You will not lose any progress.
If you request a new agent mission (or complete/fail an existing one) from today onwards, that mission progress is now being carried forward into the new memory automatically.
If you have interacted with an agent BEFORE today, and you do not interact with the agent AFTER today to update that progress, then jobs from that agent will be cleared out and deleted when the move to Python 3 is fully completed.
We don’t yet have a firm timetable for when this clear-out will happen, as it is only one part of the huge Python 3 migration. This process will take months, rather than days. As we get closer to this moment, we will remind you before we wipe the memory.
If you have an offered/accepted mission from BEFORE today, and you do not interact with the agent to complete that mission after today, there will be a point in the future when such mission progress will be cleared.
If you have contracted a Research agent to generate Research Points BEFORE today, you will need to complete at least one mission with that agent after today to keep it active. (This only needs to be done once per agent per character). Eventually, we will be clearing all old research jobs that have not been touched since today. But rest assured, before that happens, we will reach out to those affected, both inside and outside New Eden, to remind you to check in with your research agents.
In short, if you are actively running agent missions, you can carry on playing as normal, and nothing will change. If you have some agents that you care about (particularly Research Agents), then you should pay them a visit and do a mission for them, so they don’t forget you.
Now that you know the basics, if you still want to know more about the hoarding habits of agents, and some secrets from the past, read on…
To understand what we mean by agent memory, we first need some context. A breakdown of the overall Python 3 project gives these broad areas:
Runtime - The client and the server executables that make the game tick.
Data - The bits of information that define the unique experience that is EVE Online. This can be sub-divided further:
Content data - The models, textures, words, stats and everything else that our artists, designers, and writers create. Some of this data is shipped to you as part of the client, and some only lives inside our servers.
Network data - The packets of information that travel across the internet between your client and our server, and that travel between the 200+ nodes within our server cluster in the data centre.
Persisted data - The ever-growing “save file” that records the 20+ years of progression that have happened in the game. Primarily, this is the huge SQL database that sits at EVE’s heart. This is where the agent memory lives.
Developer ecosystem - The tools and processes that we developers use in our day-to-day work to bring the game to you.
Now that we know where the agent memory lives, we can talk about what it actually is. Every time your character interacts with one of the NPC agents, we record that fact in the database. The interaction might be requesting a new mission, completing (or failing) a previously offered mission, starting a research task or a locator job, or getting a referral to one of the special storyline agents.
Every agent knows the state of the last interaction it had with every single character it has ever spoken to. If you went to an agent 20 years ago and started a mission to retrieve some dubious holoreels, that agent remembers you and is still waiting to tell you that you failed to do the job within a reasonable time!
Memories that an agent might maintain about your character include:
Which mission they have offered you, and the state of that mission (e.g. has a target NPC been eliminated yet?)
If the agent is performing a research task, and how that is going
If the agent has been tasked with locating another character for you
How far along a storyline chain you have progressed
Which epic-arc or career missions you have completed
Note that the standings relationship between NPC characters/corporations and your character are NOT part of this agent memory. Standings are their own, separate mechanic with its own way of tracking state.
Finally, we can turn attention to how this data is stored and retrieved, and the reason for this blog.
Back in the very early 2000s, when EVE Online was in its final push to launch, the agent memory database was conceived. The requirement was to store the complex state that represented the interactions between an agent/character pair. Normally in database design, we try to construct very formal models of tables and relationships for such data. But the agent memory requirements were messy and dynamic - each interaction had very different sets of variables (think about describing a courier mission versus a storyline referral, for example), and what’s more, the designs were changing rapidly as the game evolved.
At this time, the modern NoSQL movement had not yet begun. EVE was firmly using MSSQL for its persistence layer. A clever programmer realized they could take the Python object storing an agent’s memory, serialize it into a binary blob, and store that blob as a piece of text in a database table.
Then, the next time the agent is awoken by a character interaction, the inverse happens. The binary blob for that agent is fetched from the database and deserialized to turn it back into a Python object, which is then injected into the running agent, thus restoring its memory. (In Python, this process is also known as pickling and unpickling.)
While this was great for solving the immediate problem at hand, it created two future problems:
The memory blobs were not easily searchable. The power of a database comes from searching: find all entries where a parameter has some value. But having each memory wrapped up in a python envelope meant that it was impossible to efficiently query the internals. To find all memories related to the aforementioned Damsel, for example, would require loading every memory, one at a time, into python so that it can be checked. Not ideal.
The data format was coupled to the Python version in use. As the Python language evolved, new features were added and others were deprecated and eventually dropped. This meant that, sometime in the future, those memories would become unreadable - lost, like tears in the rain. With the move from Python 2 to 3, that future will soon be upon us.
To explain this problem with a non-technical analogy, imagine you need to put your belongings into storage while you move. One way would be to pack it all into one giant sealed shipping container and send that into the storage warehouse (this is "serializing" your data). It is flexible (the truck carrying your container doesn’t care if your music collection inside it is vinyl or CD), fast to do, and container shipping has become a standardised process.
Later, when you move into your new house, you have the container delivered and can unpack your prized possessions. However, this comes with a downside: if the warehouse requires a safety audit to ensure that it isn’t storing any illegal materials, then only way to do this would be to open and search every single container by hand. Not a very efficient process.
Despite the longer-term drawbacks of the approach, it worked. EVE Online made it to launch and beyond. The agent memory solution survived and held up remarkably well, all things considered. But nothing can last forever.
The migration to Python 3 is giving us a golden opportunity (which we can’t overlook... like, literally can’t) to address the sins of our past. We need to move away from the inflexibility and built-in obsolescence of storing Python blobs in a SQL database. At the same time, we are using this opportunity to do some housekeeping and clear out a lot of hoarded data. (The agent memory table is one of the largest in our DB, and one of very few that only grows and never shrinks.)
This work has already begun behind the scenes. We recently updated how we load and save Agent Memories. Whenever a new memory needs to be saved, we are now doing so in two parallel forms:
The legacy opaque python-blob form, exactly as we have always done.
A new future-proof, transparent form that does not rely on a particular Python format, and is also open for better searchability and future adaptability.
All new/updated memories will exist in both forms for now. If you request a mission from an agent today, that memory is saved in both. This allows us to choose which form to prioritize when loading an agent memory. It also reduces the risk, as we can check that both forms tell the same story before switching off the old method.
When we need to load an agent’s memory back from the database, we now have a few options for which source is treated as the priority, which we will change across three phases:
Phase 1: Initially we will continue to load only from the legacy storage, until we are satisfied that the new form is working correctly.
Phase 2: Then we will switch the priority, so that we first look for a memory in the new form, and then if nothing is found we fall back to loading it from the old form.
Phase 3: Eventually (when we fully migrate everything else to Python 3) we will stop reading from the old form entirely. Only memories that were saved in the new form will be available to the agents. We can then finally drop the old legacy memories that were never updated from the database, making our database admins happy.
As of today, any new memory will get brought forward with us as we migrate to Python 3. This migration will be a long process, and so you will have plenty of time to interact with your agents and get new missions or complete existing ones. We are talking months here, not days. As we get closer to Phase 3, we will make sure you know about it.
There are some memories that we DO need to bring forward with us, regardless of how old they might be, even if the associated character does not log in or generate an updated memory with each agent. Certain tutorial or epic-arc missions are one-time only, for example, so we need to track that. In those limited cases, we will automatically migrate the data to a new form in the background.
An important part of the relationship between characters and agents is their standing. This is what you’re working on as you work up the ranks from level 1 agents to level 4 or even 5. All standings between characters and NPC agents/corporations/factions will be preserved and unaffected by these changes. We will not reset or lose those standings.
Work continues on the Python 3 migration. In addition to the “simple” part of converting the client/server code, there is just as much (if not more) work involved in updating everything around the code. There are the many tools that our developers use every day. The many boundaries where a Python process talks to some other component across a network. The deployment processes that let us push a button and make an expansion go live.
And, as we have seen here, even the data stored inside a database needs a little refreshing sometimes.
Fly safe, and we will see you in another blog soon o7