The Problem Of Moving Metrics Through AI Systems
Organisations today are attempting to use AI agents to drive real business outcomes, improving renewal rates, reducing churn, optimizing revenue pipelines. But most of these systems hit the same wall: they can analyze data, surface trends, and generate recommendations, yet the metrics barely move forward to actually generate revenue.
The problem is not access to data. Most systems already have dashboards, databases, and reporting pipelines. The problem is that understanding revenue metric in a real organization is not a data retrieval task.
Moving revenue metric requires knowing who owns it, how decisions around it actually get made, which teams are involved, and where the relevant information actually lives, much of which is never formally documented.
Every organization runs on a layer of context that sits outside structured systems. This layer is invisible when all you are doing is data retrieval. It holds the metadata that actually matters, which data pipelines exist inside the revenue system, how information moves between them, who is responsible for what, and where things quietly break down.
Organizational Context: A Bottom Up View
Looking Organizational Context From Inside
Organizational context is difficult to define in a single line. As the title suggests, it is not one thing but a composition of multiple layers that come together to shape how organizations optimise revenue.
To understand it better, let's take a microscopic bottom up view.
At the foundation is the organizational hierarchy teams, their structure, and reporting lines. As we move down the hierarchy people within it change more frequently.
On top of this comes responsibility, who actually does what. This is often not clearly documented and keeps changing over time. Capturing this requires continuously interacting with individuals, understanding their roles, and observing how work flows in practice.
Then comes the data sources. Information is scattered across systems documents, spreadsheets, databases, and sometimes even personal storage. Knowing where data exists is not enough. It is important to understand who owns it, who maintains it, and whether it is actively updated or automated.
Beyond this, there is a more meta layer to the business itself. What the company does, how it operates, what products it builds, and how different teams contribute to that process.
Finally, there are the metrics each team tracks. These metrics are not isolated; they are tied to people, processes, and data sources across the organization.
How Organizational Context Becomes The Context For Building Revenue
All of this connects through tasks and dependencies. Different workflows pull data from different data sources. Product understanding might live in structured tables, financial context in spreadsheets, operational knowledge in a Slack thread from six months ago. These relationships are almost never formally documented, but they are exactly where the context required to move revenue quietly slips through.
Context here exists in both structured and unstructured forms, spread across systems and people in roughly equal measure.
Without understanding how organizational context is built, any attempt to improve revenue outcomes stays surface level. And this is exactly where agents alone fall short, not because they lack capability, but because they lack continuity.
Why Agents Need To Have Continuity
Is Knowing Everything About Your Organization's Data Enough?
Imagine your organization had an oracle. Something that could answer any question about your teams, clients, workflows, and data. Would that be enough to actually move a metric?
We don't think so.
Having the right information is only half the problem. The other half is having a system that can act on it continuously, across teams, data sources, and workflows, long enough to actually shift outcomes.
Agents Need More Than One Single Run.
Think about the last time you handed something to a junior hire. How long before they needed guidance? Now give them the goal: improve this KPI. That is not a one hour task. It means coordinating across teams, revisiting data, adjusting as they learn, and staying with the problem until something moves.
Current agents operate this way. They answer a query, complete a task, and stop. Every restart silently breaks momentum toward revenue.
Working Memory That Is Built By Long Running Agents.
Standard agents cannot sustain duration, task decomposition, and continuous learning.
Whereas, LRAs accumulate working memory across all three, building a persistent representation of the organization that goes beyond what any structured data layer captures.
This is the shift in how you think about agents. You do not deploy them to answer "where are we losing revenue." You deploy them to keep building context around that question, continuously, across the people, workflows, and data sources where the answer actually lives.
Two agent types do the heavy lifting. Human following agents track how responsibilities shift and how decisions actually propagate through teams. Data source agents monitor documents, sheets, and systems, not just for current state but for how data moves and changes over time.
Engineering Revenue With LRAs That Work On Organizational Context
Why This Matters For Revenue
Revenue does not move inside dashboards. It moves through people, systems, and decisions. Most AI systems stop at analysis; they generate insights but fail to carry them through execution layers.
The gap is not intelligence, it is context. And more importantly, it is a continuously evolving context.
The Human Parallel: Insights On How Context Is Built And Used
To operate on organizational context over time, LRAs must mirror how humans manage context continuously.
Now imagine agents that filter what matters, retrieve context only when needed, verify their own actions, and learn from mistakes, but do this continuously across an entire organization.
Memory and context are no longer static or fragmented; they are actively built, refined, and applied in real time, all aligned toward moving a metric. At that point, the system shifts from assisting decisions to consistently driving them toward revenue.
What Follows Is A Parallel Between How Humans Build And Use Context, And How LRAs Can Replicate This To Move Metrics In The Real World
1. Filtering over retrieval
Humans don’t retrieve everything, they filter most inputs before they reach working memory. Cognitive Load Theory, Paas, 2020 show efficiency comes from blocking irrelevant signals, which helps in managing complex tasks efficiently.
LRAs do the same. In long running systems, excess retrieval compounds only context relevant to the current metric should enter working memory. This keeps decisions focused, reducing noise and directly improving execution on revenue critical paths.
This implies a pre retrieval gating layer is more optimal than post retrieval ranking. Filtering should happen before memory expansion, not after.
2. Retrieval is task triggered
Humans recall information based on relevance, not recency. This paper from 2018 shows memory is surfaced based on expected utility, not what was accessed last.
LRAs mirror this. As they operate over time, the right context keeps changing schemas, ownership, and dependencies should surface only when needed, not through static retrieval. This ensures decisions happen with the right context at the right time, preventing delays and improving metric movement toward revenue.
Retrieval should be modeled as a policy function over expected future utility, not similarity search or recency heuristics.
3. Continuous verification
Humans constantly track whether something feels correct, even before external feedback arrives. Work on error neurons and dopamine prediction error shows that systems can internally detect mismatches and label them in real time.
This is the "Verification Loop”.
LRAs have a similar loop. As they run continuously, they maintain awareness of what’s done, pending, or drifting and flag inconsistencies early. This prevents silent failures, keeping execution aligned and protecting revenue from gradual degradation.
Systems need an internal state evaluator that compares expected vs actual outcomes at each step, instead of relying only on terminal evaluation.
4. Learning through labeled experience
Humans don’t just experience, they label mistakes and learn from them. Work on dopamine prediction error shows learning is driven by identifying mismatches, not just storing events. Humans can learn and mentally reconstruct complex networks from scattered experiences and use them for reasoning and planning.
LRAs do the same. Over time, they convert failures, corrections, and outcome gaps into labeled signals not as raw logs.
This allows systems to improve across runs, compounding gains and steadily improving revenue outcomes. Learning requires structured feedback signals (labels) raw logs are not sufficient for adaptation.
5. Memory as a continuous system
Human memory is not session based, it evolves, reorganizes, and surfaces what matters over time.
MemGPT (Packer, 2023) establishes the baseline with memory tiers, while recent work like A-Mem (2025) points toward relational, evolving memory systems.
LRAs have this shift. Organizational context cannot be stored as static chunks it must persist and adapt as systems and dependencies change. This continuity ensures context doesn’t reset, allowing sustained execution that compounds into long term revenue impact.
Memory should be modeled as a dynamic graph with temporal updates, not static embeddings or chunk stores.
What To Expect Next?
In the coming blogs, we’ll go deeper into the engineering behind long running agents and how organizational context can be systematically built, stored, and operated on. We’ll explore architectures, memory systems, and design patterns that make LRAs truly effective in real world systems moving from ideas to implementation.