Originally published on tamiz.pro.

The narrative surrounding Artificial Intelligence has shifted from "what can it do?" to "can it run alone?" While Large Language Models (LLMs) have mastered text generation and code synthesis, the jump to autonomous agents—systems that operate 24/7 without human intervention—remains fraught with operational failures. The hype cycle often presents autonomy as a feature of the model itself, but in reality, autonomy is a property of the architecture.

This deep dive explores the hidden engineering constraints that prevent most AI agents from surviving in production. We will analyze the "Mercury-Agent" pattern—a hypothetical but representative architectural paradigm for high-frequency, low-latency agent orchestration—and dissect how to implement the rigorous guardrails necessary for safe, continuous operation. This is not a guide to prompt engineering; it is a guide to agent systems engineering.

Table of Contents

• 1. The Autonomy Illusion
• 2. The Mercury-Agent Pattern
• 3. Constraint 1: Bounded State Spaces
• 4. Constraint 2: Deterministic Execution Gates
• 5. Constraint 3: The Resource Feedback Loop
• 6. Implementing the Control Plane
• 7. Failure Modes and Recovery
• 8. Frequently Asked Questions

1. The Autonomy Illusion

In many software engineering contexts, we assume that if a model can "think" for 10 steps, it can "think" for 10,000 steps. This is a fallacy. LLMs suffer from context drift and compounding error. In a 24/7 environment, an agent does not just fail; it degrades. It begins to hallucinate dependencies, ignore new constraints, and eventually, it loops.

True autonomy requires treating the AI model not as the "brain" of the system, but as a component within a larger state machine. The model provides probabilistic decision-making, but the surrounding infrastructure must provide deterministic constraints. Without these constraints, an autonomous agent is merely a non-deterministic script that runs on a timer.

The goal of this article is to define the "Mercury" standard: a low-latency, high-reliability pattern where the agent operates within strict physical and logical boundaries, ensuring that "autonomous" does not mean "reckless."

2. The Mercury-Agent Pattern

The Mercury-Agent pattern is an architectural design derived from the need for speed (Mercury) and stability (Jupiter-like stability) in high-frequency agent loops. Unlike traditional RAG (Retrieval-Augmented Generation) setups which are often batch-oriented or interactive, the Mercury pattern assumes continuous stream processing.

Core Components

1. The Actor Core: A lightweight, stateless execution unit that receives the LLM's intent.
2. The State Ledger: A persistent, append-only log of all agent actions. This is not a database in the traditional sense; it is a stream of facts.
3. The Constraint Engine: A synchronous filter that validates the LLM's proposed action against hard limits before execution.
4. The Feedback Loop: A mechanism that ingests system telemetry (CPU, memory, API costs) and injects it back into the LLM's context in real-time.

Why "Mercury"?

In classical computing, speed is achieved through parallelism. In AI agent design, speed is achieved through parsing efficiency. The Mercury pattern minimizes the time between "Model Output" and "Constraint Check." By keeping the constraint engine in-memory and using compiled validators (rather than interpreting rules), we ensure the agent can make thousands of micro-decisions per second without becoming a bottleneck.

3. Constraint 1: Bounded State Spaces

The most significant failure point in 24/7 agents is state bloat. If an agent interacts with a long-term memory system (like a vector database) and accumulates 10,000 chunks of context, its inference cost and latency increase exponentially, and its hallucination rate spikes.

The Context Window as a Resource

We must treat the context window as a finite resource, similar to RAM. The Mercury pattern enforces a Fixed-Size Sliding Window for active state.

Implementation Strategy

Instead of letting the LLM decide what to remember, the architecture forces a Distillation Step.

1. Active Window: The last N interactions (e.g., 500 tokens).
2. Summary Block: A compressed representation of the last M interactions (e.g., 1,000 interactions).
3. Long-Term Archive: Immutable, searchable, but not actively loaded.

When the agent approaches the limit of the Active Window, the system automatically triggers a Summarization Agent (a smaller, faster model) to compress the oldest 500 interactions into a single "Historical Context" block. This keeps the primary agent's payload small, predictable, and fast.

class BoundedState:
    def __init__(self, max_active_tokens=1000, summary_model="gpt-4o-mini"):
        self.active_buffer = []
        self.historical_summary = ""
        self.max_tokens = max_active_tokens
        self.summarizer = SummarizerClient(model=summary_model)

    def add_interaction(self, user_input, agent_response):
        # Tokenize and check length
        input_tokens = count_tokens(user_input)
        response_tokens = count_tokens(agent_response)

        # Pre-check: If adding this would exceed limit, trigger compaction
        current_load = self.get_current_load() 
        if current_load + input_tokens + response_tokens > self.max_tokens:
            self._compact()

        self.active_buffer.append({"in": user_input, "out": agent_response})

    def _compact(self):
        """
        Move the oldest 50% of active_buffer into historical_summary.
        """
        # Split buffer
        split_index = len(self.active_buffer) // 2
        old_interactions = self.active_buffer[:split_index]

        # Generate summary of old interactions
        summary_prompt = f"Summarize the key facts and decisions: {old_interactions}"
        new_summary = self.summarizer.generate(summary_prompt, self.historical_summary)

        # Update state
        self.historical_summary = new_summary
        self.active_buffer = self.active_buffer[split_index:]

This ensures that the LLM never sees more than max_active_tokens of raw data, keeping latency in the low 200ms range even after days of operation.

4. Constraint 2: Deterministic Execution Gates

Autonomy implies the agent chooses how to act, but it must not define what is allowed. The Mercury pattern utilizes a JSON-Schema Bound Action Space.

The LLM is not allowed to output free-text actions. It must output a JSON object that conforms to a strict schema. The Constraint Engine acts as a synchronous gatekeeper.

The "Allowlist" Approach

In a 24/7 environment, we do not use "denylists" (things the agent can't do). We use allowlists (tools the agent can call).

1. Tool Registry: A static list of functions available to the agent.
2. Permission Levels: Each tool has a risk score.
3. The Gate: Before execution, the engine checks:
   • Is the tool in the registry?
   • Is the input within safe parameter ranges (e.g., limit < 100)?
   • Is the total estimated cost of this action below the budget threshold?

If any check fails, the action is rejected, and the rejection is fed back to the LLM as a "System Error" message, allowing the agent to self-correct within the safe boundary.

// Pseudo-code for the Constraint Engine
import { ZodSchema } from 'zod';

const ActionSchema = z.object({
  tool_name: z.enum(['query_db', 'send_email', 'update_config']),
  parameters: z.object({
    // Strict parameter validation
    query: z.string().max(1000),
    recipient: z.string().email(),
    config_key: z.string().regex(/^[a-z_]+$/),
  })
});

export function executeAction(rawLLMOutput: string, context: AgentContext): void {
  try {
    // 1. Parse and Validate
    const validatedAction = ActionSchema.parse(rawLLMOutput);

    // 2. Permission Check
    if (!context.hasPermission(validatedAction.tool_name)) {
      throw new PermissionError(`Tool ${validatedAction.tool_name} not authorized for this tier.`);
    }

    // 3. Cost Check (Predictive)
    const estimatedCost = calculateCost(validatedAction);
    if (context.budget.exhausted(estimatedCost)) {
      throw new BudgetExhaustionError("Action would exceed monthly budget.");
    }

    // 4. Execute
    const result = toolRegistry.get(validatedAction.tool_name).run(validatedAction.parameters);

    // 5. Feedback
    context.state.logAction(validatedAction, result);

  } catch (error) {
    // Feed error back to LLM as a "System Constraint Violation"
    context.state.setErrorMessage(`Constraint Violation: ${error.message}. Please adjust your plan.`);
  }
}

This pattern ensures that even if the LLM is in a "confused" state, it cannot execute a DROP TABLE or send an email to a malicious address, because the code enforcing the schema is deterministic.

5. Constraint 3: The Resource Feedback Loop

A 24/7 agent that ignores its environment will eventually crash or bankrupt the company. The Mercury pattern requires Telemetry-Driven Context Injection.

Dynamic Budgeting

We must inject real-time system metrics into the LLM's system prompt (or a dedicated "Status" field) every cycle. This forces the agent to adapt its behavior based on physical constraints.

Metrics to Inject:

• Cognitive Load: Average tokens processed in the last hour.
• Economic Load: Spending vs. Budget.
• Environmental Load: Is the database lagging? Is the API rate-limited?

Example System Prompt Injection:

## SYSTEM STATUS (Real-Time)
- **Budget Remaining**: 12% of monthly cap.
- **Database Latency**: High (>500ms). Avoid complex queries.
- **Current Time**: 04:00 UTC (Low traffic).

**Directive**: Due to high database latency, prioritize caching logic. Do not execute writes. Check cache hit ratio before deciding next action.

By feeding this data back into the loop, the agent effectively becomes a reactive controller. It slows down when the system is stressed and speeds up when resources are abundant. This "adaptive throttling

This 'adaptive throttling' mechanism adjusts the agent's action frequency based on real‑time load metrics such as CPU utilization, queue depth, or downstream latency. By treating the agent as a proportional‑integral controller, we can smooth bursts and avoid thundering‑herd problems.

### Heartbeat & Health Checks
A 24/7 agent must know when it is alive and when its dependencies are healthy. The simplest heartbeat is a periodic timestamp written to a shared store (e.g., Redis, etcd, or a database table). Each dependent service reads the timestamp and treats the agent as unavailable if the age exceeds a threshold. Health checks go a step further: they probe critical external APIs, verify circuit‑breaker states, and expose a `/health` endpoint that returns `200` only when all subsystems report OK. Combining heartbeat liveness with readiness probes lets orchestration platforms (Kubernetes, Nomad) restart the agent only when it is truly stuck, not merely slow.

### State Reconciliation & Idempotency
Autonomous agents often operate on eventually‑consistent state. To prevent drift, each action includes a deterministic *action ID* derived from the input payload (e.g., a hash of the request). Before applying an action, the agent checks a persistent log of processed IDs. If the ID exists, the action is skipped; otherwise, it is executed and the ID is appended to the log. This idempotency layer makes retries safe and enables exactly‑once semantics even when the underlying transport guarantees at‑least‑once delivery.

### Backpressure Propagation
When downstream services saturate, the agent should not blindly increase its request rate. Instead, it exposes a *backpressure signal*—such as the length of an internal work queue or the latency of the last N calls—and feeds that signal back into its adaptive throttling controller. If the signal exceeds a configured limit, the controller increases the sleep interval multiplicatively (e.g., `sleep *= 1.5`) until the signal falls below the threshold. Conversely, when the signal is low, the interval decays slowly (e.g., `sleep *= 0.9`) to recover throughput without overshooting.

### Self‑Healing Restart
Long‑running agents can accumulate memory leaks or stuck threads. A lightweight watchdog runs in a separate thread or process and monitors key health metrics (CPU, memory, garbage‑collection pauses). If any metric crosses a safety threshold for a configurable duration, the watchdog triggers a graceful shutdown: it stops accepting new work, drains the queue, persists any checkpoint, and exits. The orchestration layer then restarts the agent with a clean state. This pattern isolates catastrophic failures without affecting the rest of the system.

## Runnable Code Example (Python 3.11)

Below is a minimal, production‑ready skeleton that puts the Mercury Patterns together. It uses only the standard library and `asyncio`.

python
import asyncio
import time
import hashlib
import os
from collections import deque
from typing import Awaitable, Callable

--------------------------

Configuration (tune per env)

--------------------------

HEARTBEAT_INTERVAL = 5.0 # seconds
HEALTH_CHECK_INTERVAL = 15.0
MAX_QUEUE_SIZE = 100
TARGET_LATENCY_MS = 200
ADAPTIVE_KP = 0.1 # proportional gain
ADAPTIVE_KI = 0.01 # integral gain
SLEEP_MIN = 0.05 # seconds
SLEEP_MAX = 5.0

--------------------------

Shared state

--------------------------

work_queue: asyncio.Queue = asyncio.Queue(maxsize=MAX_QUEUE_SIZE)
processed_ids: set[str] = set()
latency_history: deque[float] = deque(maxlen=20)
sleep_interval = SLEEP_MIN
integral_error = 0.0
shutdown_event = asyncio.Event()

async def heartbeat(stop: asyncio.Event) -> None:
"""Write a timestamp to a file every HEARTBEAT_INTERVAL seconds."""
path = "/tmp/agent_heartbeat.txt"
while not stop.is_set():
with open(path, "w") as f:
f.write(str(time.time()))
await asyncio.sleep(HEARTBEAT_INTERVAL)

async def health_check(stop: asyncio.Event) -> bool:
"""Stub: replace with real dependency probes."""
await asyncio.sleep(0) # yield
return True # assume healthy

async def adaptive_controller() -> None:
"""Adjust sleep_interval based on observed latency."""
global sleep_interval, integral_error
while not shutdown_event.is_set():
await asyncio.sleep(1.0) # control loop period
if not latency_history:
continue
avg_latency = sum(latency_history) / len(latency_history)
error = TARGET_LATENCY_MS - avg_latency # positive => we can go faster
integral_error += error
# PI controller
adjustment = ADAPTIVE_KP * error + ADAPTIVE_KI * integral_error
sleep_interval = max(SLEEP_MIN, min(SLEEP_MAX, sleep_interval + adjustment * 0.01))

async def worker() -> None:
"""Consume work items, enforce idempotency, and record latency."""
while not shutdown_event.is_set():
try:
payload = await asyncio.wait_for(work_queue.get(), timeout=1.0)
except asyncio.TimeoutError:
continue

    action_id = hashlib.sha256(payload.encode()).hexdigest()
    if action_id in processed_ids:
        work_queue.task_done()
        continue

    start = time.time()
    try:
        # Replace with actual work: call external API, DB write, etc.
        await asyncio.sleep(0.05)  # simulated work
    finally:
        latency = (time.time() - start) * 1000
        latency_history.append(latency)
        processed_ids.add(action_id)
        work_queue.task_done()

async def producer() -> None:
"""Generate synthetic work; in a real system this would be an event source."""
i = 0
while not shutdown_event.is_set():
await work_queue.put(f"task-{i}")
i += 1
await asyncio.sleep(0.01) # produce faster than we can consume to test backpressure

async def main() -> None:
stop_event = asyncio.Event()
# Launch all concerns as independent tasks
tasks = [
asyncio.create_task(heartbeat(stop_event)),
asyncio.create_task(adaptive_controller()),
asyncio.create_task(worker()),
asyncio.create_task(producer()),
]

try:
    # Run until a termination signal (e.g., SIGTERM) is received
    await asyncio.sleep(3600)  # placeholder for real signal handling
finally:
    stop_event.set()
    shutdown_event.set()
    await asyncio.gather(*tasks, return_exceptions=True)

if name == "main":
try:
asyncio.run(main())
except KeyboardInterrupt:
pass

### How the Example Embodies the Patterns
* **Adaptive throttling** – `adaptive_controller()` continuously tunes `sleep_interval` using a PI controller on observed latency.
* **Heartbeat** – a background task writes a timestamp to `/tmp/agent_heartbeat.txt`.
* **Idempotency** – each payload is hashed; duplicates are skipped via the `processed_ids` set.
* **Backpressure** – the `work_queue` has a bounded size; when it fills, the producer naturally slows.
* **Self‑healing** – the `shutdown_event` is set by external signals (not shown) prompting a graceful drain before exit.

## Concluding Thoughts
Building agents that operate continuously demands more than a naive loop; it requires a disciplined set of patterns that turn the agent into a self‑regulating control system. By layering **adaptive throttling**, **heartbeat/health checks**, **state reconciliation**, **backpressure propagation**, and **self‑healing restarts**, we obtain a service that gracefully degrades under load, recovers from transient faults, and never corrupts its state. The Mercury Patterns presented here are intentionally minimal—each can be swapped for a more sophisticated implementation (e.g., using Prometheus for metrics, a distributed log for idempotency, or a service mesh for backpressure) without altering the core loop. Start with the skeleton above, instrument the metrics that matter to your domain, and let the agent find its own equilibrium. 

--- 

*End of article.*