Hi, I'm Forrest

Category: Building

  • Why Don’t AI Agents Feel Like Teammates Yet?

    Why Don’t AI Agents Feel Like Teammates Yet?

    Linear Has First-Class Agents. Everyone Else Has Bots.

    We recently completed a plethora of integrations for Aleq particularly around— getting it to actually do things inside the tools our customers use. ClickUp, Asana, Linear, eventually Jira, maybe Monday but Aleq can now do nearly anything a human can do in 314 different software applications 🙂

    Standard pattern every time: OAuth flow, webhook setup, map their task schema to ours, write the adapter, ship it.

    Then I opened Linear to build their integration and something clicked.

    Linear’s agent isn’t a feature.

    It’s a teammate.

    AND its powered by 3rd party apps–Linear isn’t trying to control the purse and this sentence alone deserves its own blog post quite frankly, but we’ll leave that for another day.

    It has an identity. You can assign it work. It shows up in the timeline like a human. It’s governed by the same permissions as everyone else in the workspace.

    Inside Linear, the agent belongs there.

    And the second I saw that, I thought: “Oh. This is obviously where everything is going.”

    The Obvious Part

    Every ops platform already has the same building blocks:

    • OAuth2 workspace installs
    • Webhooks for events
    • APIs to create tasks, post comments, update statuses
    • Users, permissions, workspaces

    That’s it. That’s the foundation.

    Linear just connected the dots differently.

    They gave their agent a real identity in the workspace instead of treating it like a floating API token.

    And now their agent can do things no one else’s can:

    • Be assigned work
    • Show up in audit logs
    • Get @mentioned
    • Operate under workspace policies

    It’s not that Linear invented new technology.

    They just treated the agent like a member instead of a bot.

    The Gap

    So here’s the thing:

    If you’re building a serious agent — something that needs to operate across ClickUp, Asana, Jira, Notion, Monday — you’re writing completely custom integration logic for each one.

    ClickUp has one schema.
    Asana has another.
    Jira is a whole different religion.

    But the behavior you want is always the same:

    • Create a task
    • Update a status
    • Post a comment
    • Assign work
    • Respond to events

    Same intent. Five different implementations.

    There’s no standard for how agents should exist inside workspaces.

    Not behavior. Not identity. Not governance.

    Everyone’s just writing adapters.

    The Missing Layer

    Right now the stack is:

    • OAuth → who you are
    • MCP → how models call tools
    • Platform APIs → what you can do

    But there’s nothing that defines:

    • What an agent is in a workspace
    • How it should show up
    • What verbs it should speak
    • How its actions get recorded
    • How it gets restricted

    That’s the layer we need.

    Internally, we’ve started calling our version MAP — Multi-App Agent Protocol.

    Not because we’re trying to start a movement.

    Because we need it for Aleq anyway, and we figured we might as well think out loud about what shape it should take.

    What MAP Would Look Like

    This isn’t a spec. It’s barely an outline.

    But here’s the shape:

    1. Identity
    Agents get workspace-level presence, not just API tokens.

    2. Capabilities
    Universal verbs: create_task, update_status, comment, assign.
    Each platform maps their API to these.

    3. Events
    Normalized webhook format across providers.
    No more “ClickUp calls it taskUpdated, Asana calls it task.changed.”

    4. Guardrails
    Rate limits, approval workflows, restricted fields.
    Built in, not bolted on.

    5. Audit Trails
    Everything the agent does becomes a traceable log entry.

    6. Provider Adapters
    Thin mapping layer for each platform’s quirks.

    Build your agent once. It works the same everywhere.

    Why This Is Happening

    Agent-native software is coming.

    Linear already proved the model works.

    The rest of the ecosystem will follow because the primitives are already there — they just need to be connected.

    Right now every agent builder is solving this problem in isolation.

    Eventually someone standardizes it.

    We’re building it for Aleq anyway.

    If it ends up being useful beyond that, great.

    MAP ≠ MCP

    MCP handles transport — how models call tools.

    MAP handles semantics — how agents exist in workspaces.

    Different layers. Both needed.

    What Happens Next

    We’re building this because we need it.

    If you’re working on something similar and this resonates, reach out.

    You’re probably hitting the same walls.

    That’s it.

    Back to building integrations.

  • 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.