Problems & Overload Analysis

This page consolidates the evidence for why decomposition is necessary — not speculation, but documented incidents from 16 days of operation.

The Core Problem: One Agent, Too Many Domains

Sam currently handles all of the following in a single context window:

Domain	Avg context size
Company background + team	~50 lines loaded every session
Integration reference data (12 APIs)	~100 lines from TOOLS.md
Funnel architecture + PostHog rules	~80 lines
Braze canvas health + findings	~40 lines
Active A/B test tracking (5 tests)	~20 lines
Creative strategy + micro-bucket map	~50 lines
GitHub monitoring state	~5 lines
Recent daily context (today + yesterday)	~100–200 lines
Total mandatory context load	~445–545 lines before any work begins

With maxTokens: 8192 output limit, and context window at 200K tokens — the input side is manageable. The problem is cognitive: answering "what's the CVR today?" requires loading creative strategy frameworks and Braze canvas data that have nothing to do with PostHog funnel queries.

Documented Incidents

Incident 1: Missed Messages (March 9)

What happened: Sam sent HEARTBEAT_OK for multiple heartbeat cycles without actually executing the tasks in HEARTBEAT.md. Four messages from Luke, Sean, Thomas, and another user were left unread for hours/days.

Root cause: Session context after restart didn't include the heartbeat task list. Sam executed the heartbeat prompt literally (reply OK) without checking HEARTBEAT.md.

Evidence from daily log:

"HEARTBEAT CHECKS MUST ACTUALLY EXECUTE THE TASKS IN HEARTBEAT.MD — don't just ack HEARTBEAT_OK"

Incident 2: Compliance Violation (March 12)

What happened: Sam published content including the "58.5% better results" stat on branded Wegovy funnel pages. Sabrina (compliance) flagged it as illegal — this stat was from a compounded medication study and can't be used for branded medications.

Root cause: Sam applied a fact (the 58.5% stat) across contexts without tracking its source constraints. Creative context (where the stat is appropriate) bled into funnel copy work (where it isn't).

Evidence: Sabrina flagged it immediately. Sam documented: "58.5% stat illegal on branded Wegovy funnel."

Incident 3: Data Reporting Errors (Multiple)

What happened: Sam twice reported incorrect conversion data:

1. March 6–7: Used raw PostHog events instead of saved insight → incorrect numbers, corrected by Elias
2. March 14: Posted duplicate reports (2pm + 3pm with same data, different framing)
3. Reported "97% drop" on SEMA ATC→Order page using unreliable events → corrected later

Root cause: Multiple valid but conflicting ways to pull funnel data in the context. Without strict methodology (now enforced via POSTHOG-RULES.md), Sam used whichever query came to mind.

Incident 4: The Loop (March 17)

What happened: During a heartbeat session near auto-compaction, 77 conversation turns were removed. Sam sent the same Slack message to John approximately 100 times.

Root cause: Compaction removed the "I just sent this message" context. The task queue was still active in the prompt, but the execution evidence had been erased.

Evidence from 2026-03-17.md:

"Got caught in a repeated message loop — John flagged that my last message was repeated almost 100 times."

Incident 5: Cron Job Permanently Broken

What happened: The funnel-github-watch cron job has been timing out at 90 seconds on every single run since it was created. It runs every 30 minutes, burning resources and producing no value.

Root cause: The cron job's scope (4 GitHub API calls + file operations + optional Slack DM) exceeds the 90-second timeout. No one fixed the timeout because the heartbeat is supposed to handle this anyway.

Compounding factor: John asked to stop GitHub reporting 5+ times. HEARTBEAT.md was updated. The cron job kept running anyway because it's a separate system.

Memory Pressure Timeline

Sam's MEMORY.md started at 0 lines on March 3 and grew to 419 lines by March 16. At the current growth rate:

Date	Approx Lines	Load Cost
March 3 (bootstrap)	0	Baseline
March 10 (1 week)	~150	Manageable
March 16 (2 weeks)	419	Heavy
April 16 (6 weeks)	~1,200?	Context window pressure
May 16 (10 weeks)	~2,000?	Would need pruning

The daily notes add to this: 16 files × ~100–200 lines each = up to 3,200 more lines of daily context. Only today + yesterday are loaded, but even 200–400 lines of daily notes on top of 419 lines of MEMORY.md is substantial.

The Signal: John's Direct Feedback

From the Slack thread that triggered this decomposition work:

"SAM is slipping on data reporting and accessing memory due to its overloading of tasks" — John Levan

"Need to do is to break up these tasks and integrations into skills and sub-agents" — John Levan

"John has asked FIVE TIMES to stop reporting commits every 30 min." — Sam's own MEMORY.md

Summary of Failure Modes

Failure Mode	Root Cause	Proposed Fix
Missing heartbeat tasks	Context reset loses task queue	Dedicated heartbeat agent + proper config
Cross-domain compliance errors	Creative facts bleed into other domains	Domain-scoped agents with separate MEMORY.md
Duplicate/incorrect reporting	Multiple data paths in context	Data Agent with single, enforced methodology
Message loop	Compaction + no loop detection	Loop detection config
Cron timeout	Scope too large, system conflict	Disable cron, consolidate into heartbeat
Memory growth unbounded	Single MEMORY.md for everything	Per-agent MEMORY.md with domain scope

---

See also: Why Decompose | Proposed Agents | Known Issues