[devashishjadhav]

Interesting approach. The context bloat problem is real I've been running into it while building an MCP server for a code knowledge graph. The pattern I landed on was the opposite direction: instead of compressing what goes in, keep the tool set small and well-scoped so the schema overhead stays predictable. Lazy tool loading helps too. Curious how Packet28 handles the case where the agent genuinely needs historical context like when a bug in step 8 is caused by a decision made in step 2. Does the daemon store enough to reconstruct that, or does the handoff lose that thread?