7 Ways Slack Manages Context in Long-Running Systems

Imagine a developer building an agentic workflow that spans hundreds of requests, only to watch the system slowly lose its grip on reality. As the conversation progresses, the AI begins to hallucinate, forgets earlier instructions, or gets lost in a sea of its own previous words. This is a common wall that many engineers hit when moving from simple chatbots to complex, autonomous systems. When a single session generates megabytes of output, the traditional method of simply feeding the entire chat history back into the model becomes a recipe for failure. To solve this, engineers have had to rethink the very core of how they handle information, moving toward a sophisticated method of managing agent context that prioritizes distilled truth over raw data accumulation.

managing agent context

The Hidden Danger of the Context Window

Most people interacting with Large Language Models (LLMs) are accustomed to short, snappy exchanges. In these brief sessions, the model can easily keep track of the topic because the total amount of data is relatively small. However, as soon as you transition into long-running systems, the architecture changes. Most standard agent frameworks attempt to manage state by simply accumulating every single message exchanged between API calls. While this works for a five-minute chat, it creates a massive technical debt for an agent that needs to operate for hours or even days.

The primary issue is the context window, the finite amount of information a model can process at once. As this window fills up, several things happen simultaneously. First, the computational cost rises. Second, and more importantly, the quality of the responses begins to degrade. When an agent is forced to sift through thousands of lines of “noise”—old greetings, discarded ideas, and intermediate reasoning steps—it loses the ability to focus on the actual objective. This phenomenon is often referred to as the “lost in the middle” problem, where models struggle to retrieve information located in the center of a massive prompt.

For a high-scale application, such as one that might span hundreds of requests, the sheer volume of data can reach megabytes. If you try to pass all that raw text into every new request, you aren’t just hitting a limit; you are actively drowning the intelligence of the model. This is why modern architectural shifts are moving away from simple chat logs and toward structured memory systems. Instead of asking the model to “remember everything,” engineers are learning how to ask the model to “remember only what matters.”

Moving Toward Structured Memory and Distilled Truth

To address the limitations of raw history, a more robust approach involves managing agent context through structured summaries. Instead of treating the conversation as a continuous stream of text, the system treats it as a database of evolving knowledge. This shift requires a move from “unstructured” data (the messy chat log) to “structured” data (organized findings, decisions, and observations).

A sophisticated way to implement this is through a coordinator/dispatcher design. In this model, a central intelligence—the coordinator—does not do all the heavy lifting itself. Instead, it acts as a project manager. It receives a high-level goal, breaks it down into smaller tasks, and dispatches those tasks to specialized agents. Some agents act as experts, performing specific research or coding tasks, while others act as critics, reviewing the work of the experts. This separation of concerns is vital because it prevents any single agent from becoming overwhelmed by the total volume of the system’s output.

By utilizing specialized roles, the system can distill information at every stage. An expert agent might produce a massive report, but the coordinator does not pass that entire report to the next agent. Instead, a critic agent processes that report and produces a condensed, verified summary. This ensures that the “context” being passed around is always high-density and high-quality, rather than high-volume and low-quality.

Implementing a Coordinator/Dispatcher Architecture

If you are designing an agentic workflow, you can implement this by following these steps:

  • Define the Coordinator: Create a central agent whose primary job is not to execute tasks, but to maintain the state of the project and decide which specialized agent to call next.
  • Create Specialized Expert Agents: Build agents with narrow scopes. For example, one agent might only handle database queries, while another only handles documentation writing.
  • Introduce a Critic Layer: This is the most critical step for accuracy. Create an agent whose sole purpose is to inspect the output of the experts and flag inconsistencies or errors.
  • Standardize the Handover: Never allow agents to pass raw logs to one another. Require every agent to output its findings in a specific, structured format (like JSON or a highly organized markdown summary) that the coordinator can easily parse.

The Three Channels of Contextual Coherence

A highly effective way to manage these complex interactions is to divide the agent’s memory into distinct, functional channels. Rather than one giant “brain,” the system uses three complementary streams of information to keep everyone on the same page. This approach prevents the “noise” of one task from polluting the “signal” of another.

1. The Director’s Journal: Maintaining the Narrative

The first channel is the director’s journal. Think of this as the “working memory” of the entire operation. In a long-running system, the biggest risk is that the agents lose sight of the original goal. The director’s journal solves this by storing a structured record of the mission’s progress. It doesn’t store every word said; instead, it captures specific categories of information: findings, observations, decisions made, pending questions, and current hypotheses.

Because the journal is structured, the coordinator can glance at it to understand exactly where the project stands. If an expert agent asks, “What should I do next?”, the coordinator doesn’t need to read the last fifty messages. It simply checks the journal to see the most recent decision and the current hypothesis. This provides a common narrative that keeps all agents, regardless of their specialty, aligned with the overarching objective.

2. The Critic’s Review: The Truth Filter

The second channel is the critic’s review, which serves as the system’s primary defense against hallucinations. One of the greatest challenges in managing agent context is that LLMs are prone to “inventing” facts that sound plausible but are entirely false. When an expert agent submits a finding, there is always a risk that it has misinterpreted the data or simply made something up to satisfy the prompt.

The critic’s review acts as a filter. Specialized critic agents use evidence inspection tools to look at the raw data and compare it against the expert’s claims. They don’t just say “this is good” or “this is bad.” Instead, they build a credibility-weighted list of findings. For example, if three different sources confirm a fact, it receives a high credibility score. If a finding is based on a single, shaky observation, it receives a low score. This allows the system to move forward with confidence, knowing which parts of the context are “distilled truth” and which are merely “possibilities.”

To make this work effectively, critics must be given very narrow instructions. A common mistake is asking a critic to “review the conversation.” This is too broad and leads to more hallucinations. Instead, a critic should be instructed to “only make judgments on the specific findings submitted in this report.” By limiting the scope of the critic, you significantly increase the accuracy of the validation process.

3. The Critic’s Timeline: Resolving Conflicts and Duplicates

The final channel is the critic’s timeline. While the journal tracks the “what” and the “why,” the timeline tracks the “when” and the “how it evolved.” As a system runs for hundreds of requests, information becomes redundant. An agent might find the same piece of data ten different times, or two different experts might reach conflicting conclusions.

You may also enjoy reading: 7 Ways Engineering Collisions at NYU Are Remaking Health.

The critic’s timeline builds a coherent, chronological narrative by synthesizing the director’s journal, the latest critic’s review, and the previous version of the timeline. Its job is to perform three essential functions:

  1. De-duplication: It identifies and removes redundant information so the context window doesn’t fill up with the same facts repeated in different ways.
  2. Conflict Resolution: If Expert A says “The server is down” and Expert B says “The server is up,” the timeline looks at the credibility scores and the timestamps to decide which finding is the most current and reliable. It prefers the strongest sources to resolve the discrepancy.
  3. Narrative Compression: It transforms a series of disjointed events into a streamlined story of progress, ensuring that the most important evolution of thought is preserved while the trivial details are discarded.

Practical Solutions for Preventing Data Misinterpretation

Even with a sophisticated multi-channel system, engineers still face the daily struggle of preventing agents from misinterpreting data as sessions grow. If you are building your own system, you can implement several practical strategies to mitigate these risks.

One effective method is the use of “Evidence Anchoring.” When an agent makes a claim, require it to provide a direct quote or a specific data point from the source material as an anchor. If the agent cannot provide an anchor, the system should automatically flag that finding as “unverified” in the structured memory. This prevents the “hallucination creep” where a small error in request ten becomes a foundational “fact” by request one hundred.

Another solution is to implement “Contextual Pruning.” Instead of waiting for the context window to get full, set a threshold (for example, at 60% capacity). When this threshold is hit, trigger a “summarization event” where a specialized agent is tasked with compressing the entire recent history into a highly dense, structured summary. This summary then replaces the raw history, effectively resetting the window while preserving the essential intelligence.

Finally, consider the implementation of “Multi-Perspective Validation.” When dealing with high-stakes decisions, do not rely on a single critic. Instead, dispatch the same finding to two different critic agents with slightly different personas—for instance, one focused on logical consistency and another focused on data accuracy. If their reviews diverge, the coordinator should flag the issue for human intervention or trigger a deeper investigative loop.

The Future of Long-Running Agentic Systems

The shift from simple chat logs to structured, multi-channel memory represents a fundamental evolution in how we interact with artificial intelligence. We are moving away from treating LLMs as mere “chatters” and toward treating them as components of a larger, more organized cognitive architecture. By managing agent context through the use of journals, reviews, and timelines, we can build systems that are not only more capable but also significantly more reliable.

As these technologies continue to mature, the ability to maintain coherence over massive, multi-step processes will be the dividing line between simple toys and professional-grade autonomous tools. The goal is not to give the AI a bigger memory, but to give it a better way to organize the memory it already has. By focusing on distilled truth and structured summaries, we can ensure that even as our systems grow to handle megabytes of data, their intelligence remains sharp, focused, and profoundly useful.

Add Comment