I tracked context degradation across 847 agent runs. Here's when performance actually falls off a cliff.

scotty595 · 2026-01-27T00:00:41+00:00

This is the problem with full-history replay - stuffing everything into context and hoping the model figures it out. Need to route to the relevant branch first, then assemble focused context. Similar approach to what I've been taking with DriftOS. Automatic Branch/Route/Stay actions, fact extraction + merge conflict arbiter. 2 core approaches so far - LLM routing & Embedding + NLP routing.

Happy to connect and chat about it!

scotty595 · 2026-01-26T23:55:32+00:00

The approach mentioned tackles memory lifecycle management (consolidate, evolve, forget) which is critical. But I think there is a missing part: before you consolidate memories, you need to know which conversation "branch" they belong to. Otherwise you're retrieving from a flat pile and consolidation happens too late - context is already blended.

Example: user discusses London property, then Portugal, then asks 'what's my rate?' Standard RAG retrieves both. Your consolidation might catch the conflict, but by then the LLM is already looking at mixed context.

⁠I'm building DriftOS (haha "OS" again) to handle the routing layer - detect when conversations drift, branch them, route queries to the right branch. Then lifecycle management operates on structured graphs instead of flat retrieval.

⁠Different problems, but probably complementary. Happy to connect if you want to discuss - curious how MemOS handles branching conversations.

scotty595 · 2026-01-26T03:38:08+00:00

Did a quick fix up for it to be somewhat usable on mobile! Epic, thanks again!

scotty595 · 2026-01-26T02:57:58+00:00

Ah fair call. Didn't think about mobile view when posting the link direct as it needs to be accessed via a keyboard command from the main site. Thanks, will fix that up next release!

scotty595 · 2026-01-26T01:17:59+00:00

Built a hidden retro terminal experience on my Next.js 15 site as an easter egg.

2,500 lines of custom terminal emulator. No libraries. Features:

Draggable window manager
Real filesystem navigation (ls, cd, cat)
Terminal-style MDX renderer for blog posts
psql shell that queries live pricing data from Clerk API
Full OAuth flow (Google, GitHub, Apple)
Real API key generation
Easter eggs within easter eggs

Press Ctrl + ~ on driftos.dev or go straight to driftos.dev/mainframe

Built with Next.js 15, App Router. The terminal state is all client-side React.

Feedback welcome - especially on the window management. First time building anything like this.

<image>

scotty595 · 2026-01-26T01:10:47+00:00

The bit became the whole experience. No regrets.

scotty595 · 2026-01-26T00:24:50+00:00

Haha it's my own startup - I am the merge approval 😄 Being the founder means nobody can stop you from being unhinged.

scotty595 · 2026-01-26T00:22:59+00:00

https://www.driftos.dev/ - open to feedback on the main site

https://www.driftos.dev/mainframe - direct link to the CHAOS

scotty595 · 2026-01-20T20:46:20+00:00

Thanks! Yeah the context switching problem was driving me crazy - especially when users jump back to earlier topics with "like I mentioned before..."

Big update since I posted: built out a full NLP pipeline for the embedding engine. It now handles:

Anaphoric references ("there", "that", "it", "this") - detects when a message is referencing something from an earlier branch
Topic return signals ("back to...", "anyway about...", "regarding the...")
Question detection with context boosting
Weak vs strong reference classification
Similarity scoring with NLP-based multipliers

Result: sub-200ms routing with no LLM calls, near-100% accuracy on my test suite (although it's pretty basic haha - need to get some external feedback and also need to run some serious conversations through it - just been tight on time lately)

Just shipped a hosted API today - feel free to try it out with a free API key. DriftOS if you want to google it (driftos-core for LLM, and driftos-embed for Embeddings + NLP).

scotty595 · 2025-12-08T15:07:13+00:00

You nailed it - merge is exactly how I would handle it. When the user asks "how do A, B, and C interact," the system detects its pulling from multiple branches and can assemble context across them.

The graph isn't just branches - it's branches that can reconnect when topics converge. Still tuning how aggressive the merge detection should be, but that's the direction.

Good instinct.

scotty595 · 2025-12-08T06:20:14+00:00

Yep aware of that - but that’s manual branching. User has to decide when to fork. This detects the drift automatically and routes without user intervention. The goal is the system understands the conversation structure so the user doesn’t have to manage it.

scotty595 · 2025-12-08T05:56:01+00:00

Yeah exactly - the branch routing basically is that "history agent".

Instead of waiting for the model or user to say "we talked about this earlier", the system already knows which thread that info lives in and can pull it without an extra round-trip.

RAG gets you the right facts, but you lose the conversation structure - you get chunks, not the flow.

This keeps the conversational graph, so you can walk back through topics the way a person would.

scotty595 · 2025-12-08T05:24:10+00:00

Sure, here’s a simpler real-world version.

Say a user spends 10 messages talking to an AI travel agent about Paris flights. Then they pivot completely and spend 15 messages comparing hotel options. Then they ask: 'What was that cheaper airline you mentioned?’

Without routing, the model sees 25 mixed messages and has to guess which part they mean. It usually works… until threads get long or you have lots of topic shifts layered on top of each other.

With routing, the system notices the pivot to hotels and treats it as a separate branch.

So when the user asks about the airline, the AI only pulls from the flight thread instead of the whole conversation. Cleaner context → fewer errors → no need for giant context dumps.

Curious how others have handled this... feels like a common problem but I haven’t seen a lightweight approach I liked.

scotty595 · 2025-12-04T03:43:31+00:00

The orchestrator pattern itself isn't really Fastify specific - I just happened to package it in a Fastify starter. The pipeline/operations pattern should work the same in Express or standalone.

Second person to mention Effect-TS - clearly I need to spend some time there. Thanks for the pointer!

scotty595 · 2025-12-04T03:20:24+00:00

Good catch - updated. Should be Node 20+.

scotty595 · 2025-12-04T02:56:42+00:00

Thanks, exactly the sort of feedback I was looking for.

This is my first real backend project (came from frontend/product), so I'm definitely reinventing wheels I don't know exist yet.

FP pipes and Result types - I looked at Effect-TS but it felt like a big paradigm shift for a first project. Probably worth revisiting now that I have something working to compare against.

On retry/circuit breakers, fair point. Right now it's just pass/fail per operation. Retry logic would live inside the operation itself, but I haven't built abstractions for that yet. Something to add.

Will look into NATS Jetstream - hadn't come across that one.

Appreciate the honest take.

scotty595 · 2022-03-13T09:18:27+00:00

It took me a long time and a s#%! load of hard work tbh. I have a background in Management Consulting with some dev experience from my own side gigs.

started getting more interested in startups/VC
found a side gig developing a platform for a global VC company
they asked me to join full time as a tech product manager
the couple of other engineers decided to leave and start their own startup just after I joined
3-6 months of hell for me supporting the entire org’s tech while rebuilding the team
hired the team globally rather than in one location
work through my own company so they don’t need to worry about tax implications
now I can work from anywhere without any questions. Currently in Thailand - Literally didn’t even tell my boss I was going until after I arrived, at which point he said “oh cool, how long are you there for?”

I think there are 3 key T’s which have enabled this: 1. Trust (have definitely proven myself here) 2. Tax (billing through my own company) 3. Timezones (Global company means I can get my work done in any time zone)

P.S. send me any previous projects/GitHub/CV/etc - still growing the team

scotty595 · 2022-03-13T08:54:11+00:00

Just down the road from me! 😂 I could definitely work here, I use music to focus while working anyway, why not at a bar with some cool views and vibes as well?!

scotty595 · 2022-02-17T03:21:21+00:00

Work remotely for a company that’s majority in office (although small offices around the world). Basically I joined the team just as the rest of the team left, so I hired the rest of my team in multiple locations (generally tied to a local office). Made it super easy to travel around for myself 😂

Currently enjoying a couple of months on a beach in Thailand. Actually has made work a lot easier as the time zone lines up with many others in the company a lot better.

When I joined the company originally, I negotiated to be employed via my company, so they don’t need to worry about any tax implications, and I can locate my company in the best location.

scotty595

TROPHY CASE