Hi, I'm Forrest

Tag: supporting-narrative

  • Three Columns Actually Works

    September 22, 2025

    The three-column memory is working great. But there’s a new problem that’s driving me crazy: latency.

    When a user sends a message, the agent has to:

    1. Query Neo4j for relevant entities (2-3 seconds)
    2. Traverse relationships to load context (2-3 seconds)
    3. Populate the three columns (1-2 seconds)
    4. Generate response (1-2 seconds)

    Total: 6-10 seconds before the first word appears.

    Users think it’s broken. They start typing “hello?” or clicking refresh.

    I’ve Been Thinking About This Wrong

    I’ve been treating it like a database query problem: user asks → agent fetches → agent responds.

    But humans don’t work like that.

    When you walk into a 9:30am meeting, your brain doesn’t spend 10 seconds loading context about who’s in the room and what you’re discussing. You already know. You prepared on the way there, or this morning, or when you first saw the meeting on your calendar.

    The insight: Move the latency from the critical path (user waiting) to background (user unaware).

    Time-Based Context Activation

    What if the agent could pre-load context before the user interaction?

    Calendar events: Meeting at 9:30am → Load context at 9:00am (participants, topics, relevant history)

    Recurring workflows: Month-end approaching → Load accounting workflows 3 days early

    External triggers: Email arrives from CFO → Load CFO relationship beliefs immediately

    Built a rough prototype with background workers monitoring calendar events. Pre-loads working memory 30 minutes before meetings.

    Results So Far

    Results:

    • Latency: 6.2s → 0.38s (94% reduction)
    • Users can’t tell the difference between “thinking” and “already thought about it”
    • Only works for ~70% of interactions (the predictable ones)

    The other 30% are ad-hoc messages without warning. Those still have the full latency. But 70% instant is way better than 0% instant.

    Still refining trigger detection and context prediction accuracy. But the core idea works: proactive beats reactive when latency matters.

    More technical details coming in a proper writeup soon.

  • Independent Temporal State Breakthrough

    August 28, 2025

    I’ve been silent since May. Not because I stopped working—because I’ve been heads down building.

    Took all those conceptual ideas from the early blog posts (beliefs, context, expectations, trigger-action loops) and tried to turn them into a working system. An actual AI agent that could learn from experience and operate professionally.

    It’s been messy. Let me walk through what I figured out.

    The Context Contamination Bug (June)

    Remember my post about context-conditional beliefs? The idea that agents should have different confidence levels for different contexts instead of averaging?

    Built it. Immediately hit a weird bug: updating beliefs for Client A would corrupt beliefs for Client B. Completely unrelated contexts bleeding into each other.

    Took me three weeks to figure out the problem: shared temporal state.

    I had one last_updated timestamp per belief, shared across all contexts. When I updated ClientA’s context, the global timestamp changed, which affected belief strength calculations for ClientB even though ClientB hadn’t been touched.

    The fix: Each context needs completely independent temporal state. Each one tracks its own lastupdated, lastoutcome, success/failure counts—everything.

    Seems obvious in retrospect, but it was subtle. The bug only showed up in production with multiple contexts interacting.

    The Dead End: Episodic Memory (July)

    Hit another wall with working memory. The agent would either remember too much (context window full of irrelevant stuff) or too little (forgot important context).

    I got obsessed with episodic memory for a few weeks. What if instead of extracting beliefs, the agent just stored interaction episodes and retrieved them when relevant?

    Built a prototype. It was terrible. Retrieval was slow, most episodes were noise, and it didn’t scale at all.

    That failure taught me something though: you can’t treat all information the same. “Currently processing invoice” is different from “user prefers detailed explanations” is different from “review this report later.”

    The Breakthrough: Three-Column Memory (August)

    That realization led to the three-column structure:

    Column 1: Active Tasks (3-4 slots max)

    • What’s being worked on right now
    • Rich state tracking
    • Top priority

    Column 2: Notes (acknowledged queue with TTL)

    • Things to address later
    • Auto-expire so they don’t pile up
    • Surface when contextually relevant

    Column 3: Objects (ambient context)

    • People with relationship beliefs
    • Entities, high-strength beliefs
    • Loaded based on salience, not everything

    Key insight: Different information types need different management policies. Active work needs focus. Queued work needs TTL. Background context needs smart filtering.

    Been running this for 3 weeks now:

    • Context window usage: down 40%
    • Task completion: up 23%
    • Relationship quality scores: up 31%

    It actually works.

    What’s Next

    I’ve got maybe 15-18 concepts that came out of this build process. Some feel genuinely novel (independent temporal state, three-column memory, time-based context activation). Others are creative applications of existing ideas.

    Going to start writing these up formally. Not as blog posts—as proper technical papers with evaluations and citations. Partly for prior art, partly to force myself to be rigorous about what actually works vs what was speculation.

    More on that soon. Back to building.