How the agent learns and improves over time

An agent dropped into an unfamiliar production environment has the same problem a new engineer has, and needs the same things to solve it.

What is agent memory in an operations context?

It is the additional context an agent draws on during an investigation, beyond what it can query live from your tools. Telemetry tells the agent what is happening right now. Memory tells it what normally happens, which services depend on which, who owns what, which alerts are noisy, and how to write a log query that returns something useful in this particular environment.

Why does an agent need it at all?

Because the environments are large enough that raw access is not sufficient. Consider what an experienced engineer would need if they were dropped into an unfamiliar production system and asked to explain why a particular alert was firing. Access to the tools would not be enough. They would want runbooks, a service map, some description of how the system fits together.

An agent needs roughly the equivalent, and then something the engineer gets for free. When an investigation goes wrong, that correction should become part of what the agent knows, so the same mistake is not repeated.

Where does the knowledge come from?

From two directions. The first is proactive exploration of the environment, where the system examines the connected integrations and works out the dependencies between services, logs, and alerts on its own.

The second is feedback, at varying levels of signal strength. A thumbs up or down on an investigation is one form. A written explanation of why an investigation was good or bad is a stronger one. Lower down the scale, and easy to miss, is someone in Slack asking the agent to remember something, or correcting it in the middle of a conversation. Those corrections are knowledge, and treating them as disposable conversation loses them.

What is seeding?

Seeding is generating a baseline of environment knowledge before the customer has done anything, by exploring their connected integrations and working out how the system fits together.

The effect is on what the customer spends their attention on. Without a baseline, they are correcting small details about why a given log line exists or where a particular query should be made. With one, there is a set of established facts everyone agrees on, and the customer's contribution shifts to the things only they know.

How do you know generated knowledge is actually correct?

By evaluating it, which is the step that separates this from a text generation exercise. Language models are very good at producing a large volume of plausible knowledge about an environment. Producing knowledge that is correct and that measurably helps an investigation is a different problem.

Doing it requires deep familiarity with how each integration behaves, a strong opinion about what is worth learning from a given scenario rather than recording everything, and a framework for evaluating whether the generated knowledge helped. Resolve AI validates knowledge changes through the same eval pipeline used for the agent itself. When the exploration strategy changes, or the knowledge generated for a particular team changes, evals are what determine whether it was an improvement. Without that final check, you are guessing.

What changes for the customer during onboarding?

The manual reconstruction goes away. The previous version of this work had engineers going into a customer environment to map the architecture, establish ownership models for services, find out where alerts fire and which ones are noisy, learn how to write log queries relevant to each service, and discover the environment's specific quirks around things like label structure. That was interviews, documents, and repeated back-and-forth to confirm what was accurate.

Now that knowledge gets generated and verified before it reaches the customer, so what they see is a proposal to correct rather than a blank page to fill. The agent has durable memory of the environment before the first alert fires, and the setup timeline compresses from weeks of iteration to hours.

Why can't a team build this in-house?

The generation is not the hard part and never was. The hard part is the verification layer, and it is hard for a specific reason: you need a way to tell whether a piece of generated knowledge actually improved an investigation, which means you need the eval infrastructure before the memory system is worth anything.

That ordering is what catches teams. Knowledge generation demos well immediately. Whether the knowledge is right, and whether it is making the agent better or quietly making it worse, is invisible without a measurement system that most teams have not built.