Agent Intelligence Update: Conversation Memory, Self-Programming Heartbeats, and Context Budgets

Three days after launching MCPWorks Agents, we pushed an update that changes what agents can actually do over time.

Agents now remember across sessions and can leave themselves instructions for the next run.

Here is what shipped today.

The problem we were solving

We spent time analyzing competing agent architectures — OpenClaw, LangGraph, CrewAI, AutoGen — looking specifically at where long-running agents fail. The pattern is consistent: agents degrade over time. Not because the model gets worse, but because the context bloats. Each session adds more state, more history, more injected instructions, until the model is reasoning inside a 200,000-token window where important signals are buried in noise.

Research on this is unambiguous. Performance degrades 40-90% at high context utilization. The agents that stay sharp are the ones with minimal, high-signal context — sniper agents rather than generalist agents that have accumulated rot.

The answer is not to strip context back to zero every session. That gives you amnesia. The answer is intelligent compression: keep the signal, discard the noise, and give agents tools to manage their own context rather than letting it sprawl.

That is what this update is.

Conversation memory with LLM compaction

Agents now persist their conversation history across sessions. Every chat turn, every heartbeat reasoning cycle, every orchestration run gets stored in the agent's encrypted state under __conversation_history__.

Before each session, the agent loads a recent summary plus its most recent turns. When history grows past 30 turns, the LLM summarizes the oldest portion and keeps the last 10 verbatim. The summary is stored back to state. The raw turns that were summarized are dropped.

This means the agent arrives at each session with: what it has generally been doing (compressed summary) plus what it did most recently (exact turns). New sessions have full context of recent activity without the cost of an infinite context window.

The storage uses the same AES-256-GCM encrypted state the rest of the platform uses. Conversations are encrypted at rest. No new tier limits — conversation history counts against the regular state quota.

The practical change: an agent you built last week to monitor your Stripe revenue will remember that it already flagged the Tuesday anomaly and does not need to flag it again. It remembers what it has reported, what conclusions it has already drawn, and what it decided to watch next. Between sessions, it is no longer starting from scratch.

Self-programming heartbeat instructions

This one is the feature we are most interested to see used in unexpected ways.

Agents can now write to __heartbeat_instructions__ via set_agent_state. On the next heartbeat tick, those instructions are injected into the trigger context alongside the agent's soul and goals.

The agent is programming its own next wake cycle.

Consider an agent analyzing sales data. It finishes a run, identifies that Q1 numbers are incomplete until Tuesday, and writes: "Check back in 48 hours — Q1 data finalizes Tuesday morning. Focus on ARR movement vs last quarter." On Tuesday morning, the heartbeat fires with that context. The agent knows exactly what it is looking for and why.

There is no new infrastructure here. The agent uses set_agent_state — a tool it already has — to write instructions to a watched key. The heartbeat scheduler reads that key and injects it. One new convention, significant behavioral change.

Agents without heartbeat instructions work exactly as before. Fully backward compatible.

State search tools

Persistent state is only useful if the agent can find what it stored.

Two new tools are available in all contexts — chat, heartbeat, cron, webhook:

list_state_keys returns all keys in the agent's state store with sizes. No arguments. The agent can survey everything it has remembered without knowing key names in advance.

search_state does a case-insensitive keyword search across both key names and values. If an agent stored market analysis results three weeks ago under a key it no longer remembers, search_state("revenue Q1") finds it.

These tools matter most for older agents with accumulated state. An agent that has been running for 90 days has built up context across dozens of keys. Without search, it either has to remember every key name it has ever used or read everything. With search, it can ask a natural question and find the relevant entry.

Context budget monitoring

We track the estimated token count of every context we send to the LLM. This is surfaced in telemetry with four health levels: green, yellow, orange, red. When context exceeds thresholds, it logs a warning.

This is primarily operational visibility — you can see if a long-running agent is approaching context pressure before it starts degrading. Combined with the conversation compaction system, it gives you the tools to understand and manage context growth rather than discovering the problem when agent quality drops.

The sniper agent design philosophy applies here. A purpose-built agent with 3 tools and focused state stays green indefinitely. A generalist agent with 40 tools and years of uncompacted history goes red. The monitoring tells you which is which.

What this means for running agents

If you have agents in production from the last three days, they will start accumulating conversation history automatically. No configuration required. The compaction kicks in when history exceeds 30 turns.

If you want an agent to leave itself instructions for its next heartbeat, write to __heartbeat_instructions__ in any session. It will be there when the heartbeat fires.

The state search tools are available immediately. Try list_state_keys on any agent that has been running for a while — you may find things you forgot you stored.

Questions or feedback: [email protected] or find us on Bluesky.