Although adoption of coding agents has skyrocketed, the economic impact has been less clear-cut. The models keep getting more powerful, but in this article we explore whether there's something more critical missing: context.
The core premise behind DevOps is that the same engineering team should be involved in every stage of the software delivery lifecycle. There should be no split between developing and operating your software; engineers have context across the full lifecycle.
The current paradigm of agentic software development doesn't work like this. Coding agents are missing key context like the engineering tradeoffs, design decisions, or what the team considers important. Some of this can be distilled into a Markdown file, however this loses details that could prove to be critical. This manifests as tone-deaf decision making which limits the amount of rope engineers can give an agent. Similarly, agentic SREs are also often missing key information needed to triage alerts e.g. the details of changes that have been deployed recently.
Software delivery is a complex problem with lots of context at each stage:
- Planning produces a design doc or similar, but there's also context around how decisions were arrived at that is important.
- Implementation produces the final code artefact, but there's also context in how that code was written. What other approaches were tried? What changed?
- Review generates highly pertinent feedback. These iterations enable engineers to align with engineering practice and standards and improve over time.
- Deploying and monitoring contains key insights into what works and what doesn't. Did the code change have the desired impact? Did it have unintended consequences? What do we need to do differently next time to improve?
This all feeds back into planning. Closing this feedback loop is the core development practice that DevOps brought, and it was a key driver of improvement in the software engineering discipline. However, with the advent of coding agents, the cost of code has been massively reduced. The time from ideation to delivery can be minutes to hours rather than days to weeks. This has driven a fundamental change in how we approach software delivery.
Without a memory solution, you must rely on humans, or static documentation to provide this context to the agents during the implementation cycle. However, with planning and implementation being so condensed these days, often a quick chat in standup is all that's needed before Claude is fired up and a pull request opened minutes later. The design decisions, implementation details, and other context generated during planning and implementation are lost. The agent doesn't retain these details, and with the volume of code being produced, the team often only reviews and validates the final outcome rather than the full implementation. This leads to a cognitive debt within the team, where no intelligence, human or otherwise, really has enough context.
One option for solving this would be to slow delivery down so the team can catch up via code review, but that erodes the core value proposition of AI. So what do we do?
A far more appealing option is to stop discarding this context in the first place; capture the decisions, discarded approaches and review feedback, and what we were taught from production, then surface the right piece of it back to the agent at the right stage of its next task.
When we talk about agentic memory, we are really talking about this: how do we set the agent up with the right
information to maximise their success and build trust, to allow organisations to give the agents more autonomy to
tackle bigger, more complex tasks. This isn't just a bigger AGENTS.md
but a more profound system that distils durable lessons from history and recalls them when they're relevant. This closes the DevOps feedback loop again, but crucially this time with agents fully in the loop, with access to these additional memories.
Achieving this at scale is a complex indexing and recall problem. How do you structure the unstructured information an organisation produces, and present this to an agent in the right format so it can make informed decisions?
At Volary, we're building a memory architecture for this future. If you'd like to learn more about how that works, read
some of the other posts in this series: [the agentic memory problem](/articles/the-agentic-memory-problem),
[not all memory is the same](/articles/not-all-memory-is-the-same), and
[how Volary remembers](/articles/how-volary-remembers).
If this problem rings a bell with you, join the discussion in our Slack community.