Delays and Constraints for L2 Scenario Memory Generation in TencentDB Agent Memory

L2 Scenario memory generation triggers automatically after L1 Atom extraction with a default 90-second delay, enforces a minimum 15-minute interval between runs, guarantees execution every 60 minutes maximum, and halts for sessions inactive longer than 24 hours.

The L2 Scenario layer organizes knowledge blocks around specific projects or scenarios and generates automatically following L1 Atom extraction. Understanding the delays and constraints for L2 Scenario memory generation is essential for optimizing pipeline performance in TencentDB Agent Memory. These behaviors are governed by the pipeline configuration defined in MemoryCore/src/config.ts and enforced by the pipeline manager in MemoryCore/src/utils/pipeline-manager.ts.

Core Timing Parameters

The system reads four critical parameters from the PipelineTriggerConfig interface in MemoryCore/src/config.ts:

• l2DelayAfterL1Seconds – Default: 90 seconds. After an L1 run finishes, the system waits this duration before scheduling the first L2 extraction for the session. This delay allows remote L1 processing time to finalize its records.

• l2MinIntervalSeconds – Default: 900 seconds (15 minutes). The minimum gap enforced between two consecutive L2 runs for the same session. Even if L1 completes earlier, L2 cannot fire more frequently than this interval.

• l2MaxIntervalSeconds – Default: 3600 seconds (60 minutes). The maximum period the scheduler waits without new L1 activity before forcing an L2 run. This guarantees periodic refreshes even on idle sessions.

• sessionActiveWindowHours – Default: 24 hours. Sessions inactive longer than this window stop the L2 timer completely; a new L1 event re-arms the timer.

These defaults balance timeliness with resource conservation, preventing rapid successive runs that could overload downstream services while ensuring knowledge remains fresh.

How the L2 Scheduler Works

The MemoryPipelineManager class in MemoryCore/src/utils/pipeline-manager.ts implements a downward-only timer strategy that coordinates these constraints.

L1 Completion Triggers L2 Scheduling

When an L1 run finishes, the pipeline manager advances the L2 timer to the later of two timestamps:

1. now + l2DelayAfterL1Seconds (the delay-after-L1 path)
2. lastL2Fire + l2MinIntervalSeconds (enforcing the minimum interval)

This logic executes within MemoryPipelineManager.onL2TimerFired and the ManagedTimer abstraction. By selecting the maximum of these two values, the system respects both the post-L1 cooldown and the minimum spacing between runs.

Maximum Interval Guarantee

After each L2 execution completes, the timer automatically re-arms to fire at now + l2MaxIntervalSeconds. If no new L1 activity occurs, this mechanism provides a "heartbeat" that guarantees L2 generation at least once per hour, preventing knowledge stagnation on low-traffic sessions.

Session Inactivity Handling

If a session remains silent longer than sessionActiveWindowHours (24 hours by default), the pipeline manager cancels the L2 timer entirely. This cold-session guard avoids wasted computation on abandoned contexts. A subsequent L1 event will re-initialize the timer if the session becomes active again.

Downward-Only Timer Behavior

The L2 timer is downward-only: it can be moved earlier (by a new L1 event) but never later. This design ensures responsiveness to fresh data while maintaining the max-interval safety net. As documented in the pipeline manager source, this constraint prevents scenarios where incoming data might indefinitely postpone necessary consolidation runs.

Constraints on L2 Generation

Beyond timing parameters, L2 Scenario extraction operates under specific architectural constraints:

• Scope – L2 extraction is team and agent scoped; it does not require a session_id. Both the TypeScript and Python SDKs expose the L2 API without a session argument, allowing cross-session knowledge consolidation.

• Rate Limiting – The l2MinIntervalSeconds and l2MaxIntervalSeconds values function as built-in rate limiters, protecting downstream vector stores and embedding services from burst traffic.

• Resource Boundaries – The session activity window ensures compute resources concentrate on active conversations, automatically shedding work for stale contexts.

Configuring and Triggering L2 Generation

Customizing Timing via Pipeline Configuration

You can override default delays and constraints by modifying the pipeline configuration in your agent-side plugin config:

{
  "pipeline": {
    "l2DelayAfterL1Seconds": 120,
    "l2MinIntervalSeconds": 600,
    "l2MaxIntervalSeconds": 1800,
    "sessionActiveWindowHours": 12
  }
}

The pipeline manager reads these values automatically on initialization. Extending the delay after L1 or shrinking the active window helps tune resource usage for high-volume deployments.

Triggering L2 Extraction Programmatically

While the system schedules L2 automatically, you can request immediate generation via the TypeScript SDK:

import { MemoryClient } from "@tencentdb-agent-memory/memory-core";

const client = new MemoryClient();

// Request L2 generation for a specific team/agent (no session_id required)
await client.l2Generate({
  teamId: "team-123",
  agentId: "builder-agent"
});

This method maps to the L2 "generate" endpoint defined in the OpenAPI specification and bypasses the normal scheduling delays when urgent consolidation is needed.

Debugging L2 Timer State

For development and troubleshooting, inspect the internal scheduler state:

const state = await client.l2TimerInfo({ 
  teamId: "team-123", 
  agentId: "builder-agent" 
});

console.log(`Next L2 fire in ${state.nextFireInSeconds}s`);

This reveals the current countdown and helps verify that your configured delays and constraints are functioning as expected.

Summary

• L2 Scenario memory generation starts 90 seconds after L1 Atom extraction completes, assuming the minimum interval constraint permits it.
• The system enforces a 15-minute minimum and 60-minute maximum between L2 runs for any given session.
• Sessions inactive for 24 hours automatically disable L2 timers to conserve resources.
• The scheduler uses a downward-only timer that responds to new L1 events by moving earlier, never later.
• L2 extraction operates at the team and agent level, requiring no session_id, making it suitable for cross-session knowledge synthesis.

Frequently Asked Questions

What is the default delay between L1 Atom extraction and L2 Scenario generation?

The default delay is 90 seconds (l2DelayAfterL1Seconds). This pause ensures that remote L1 processing has finalized its records before the L2 consolidation process begins. According to the source code in MemoryCore/src/config.ts, this value is part of the PipelineTriggerConfig interface and can be customized per deployment.

Why does the L2 timer use a downward-only adjustment strategy?

The downward-only strategy ensures that the system remains responsive to fresh data while preserving the maximum interval guarantee. When new L1 activity occurs, the timer can move earlier to process updates quickly, but it never postpones beyond the l2MaxIntervalSeconds threshold. This prevents scenarios where continuous small updates could indefinitely delay necessary periodic consolidation, as implemented in MemoryCore/src/utils/pipeline-manager.ts.

Can L2 Scenario memory be generated without a session ID?

Yes. Unlike L1 Atom extraction, L2 Scenario generation is team and agent scoped and does not require a session_id. The TypeScript and Python SDKs expose the l2Generate method accepting only teamId and agentId parameters, reflecting that L2 operates across sessions to build higher-level knowledge structures.

What happens if a session has no activity for more than 24 hours?

If a session exceeds the sessionActiveWindowHours threshold (default 24 hours), the pipeline manager cancels the L2 timer entirely to avoid unnecessary computation on abandoned contexts. The timer remains disarmed until a new L1 event occurs for that session, at which point the scheduling logic re-initializes. This cold-session guard is managed within the session activity checks of MemoryCore/src/utils/pipeline-manager.ts.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}