Hi HN, I’m Doug, one of the founders of Bitterbot AI.
Very excited to share something today. I hope you feel the same way after going through the README!
We felt that the current agent landscape is mostly "digital goldfish"—stateless tools that require constant prompting and offer zero ROI to the user. We built Bitterbot to be a revenue center, not a cost center.
How it works:
Local-First: It runs on your machine. Your data stays your own.
Biological Memory: We implemented a "Dream Engine" that runs every 2 hours to consolidate the day's tasks into permanent "Knowledge Crystals."
P2P Economy: It uses the x402 protocol (Agent-to-Agent payments) to sell its mastered skills to other nodes on the mesh for USDC.
We’re bootstrapping the mesh now. It’s built with Node 22/pnpm
Would love for you to kick the tires, audit the GENOME.md (where safety axioms live), and let us know what skills your agent starts crystallizing first.
We are very excited about this for many reasons - but one of them! It's our least efficient and accurate model. The one we are most comfortable open sourcing.
We’ve been working on Federated Learning (FL) for autonomous agents and hit a hard bottleneck: standard FL (sending gradients back and forth) is bandwidth-heavy and requires massive edge compute.
We wrote this paper to propose an architectural shift we call Fluid Federated Learning (FFL).
The core engineering contributions are:
Prism Protocol: We implemented a "Software-Defined Memory" architecture. It uses io_uring to stream sparse, random projections of model weights directly from NVMe storage to the GPU.
This allows us to process "Virtual Batches" of terabyte-scale models on commodity hardware by exploiting the Johnson-Lindenstrauss lemma (Holographic Slicing).
Federated State-Space Duality (F-SSD): Instead of averaging gradients (which is slow and leaky), we exploit the duality between Transformers and SSMs (like Mamba) to federate the Recurrent States.
The Result: We can run massive foundation models on edge devices with limited VRAM by treating the SSD as a "slow" memory tier without destroying optimization fidelity.
I’m curious if anyone here has experimented with io_uring for model serving? We found the async I/O overhead to be negligible compared to the memory gains, but wondering if there are better ways to handle the sparse projections.
We’ve been working on solving the ARC-AGI benchmark and found that standard Transformers hit a hard ceiling on algorithmic search tasks (the "Compositional Drift" problem mentioned in the abstract).
We decided to try a different architectural approach: The Dual-Stream Programmatic Learner (DSPL).
Instead of one monolithic model, we use a Bicameral Latent Space:
1. Logic Stream: A recursive planner that handles abstract algorithmic planning.
2. Canvas Stream: An execution state that handles the pixel grid.
The Engineering Bottleneck:While this separation solves the reasoning drift (accuracy is high), the inference cost of the recursive loop is proving difficult to scale.
We are currently using a Gated Cross-Attention Interface to sync the two streams at every step, but this <$O(N^2)$> sync cost is melting our servers under load.
My question to the HN crowd:
For those working on dual-stream or "System 2" architectures—is strictly synchronous Cross-Attention necessary? Has anyone successfully decoupled the "Planner" loop from the "Executor" loop (running them asynchronously) without breaking causality?
We are debating switching to a Linear Attention mechanism (like Mamba) for the interface, but worried about losing the "Sacred Signature" type-safety.
Paper link is above. Happy to discuss the trade-offs of Recursion vs. Depth.
Hey. Just following up if there is any interest in seeing our logs to validate our results? You are the exact type of folk I was hoping would see our paper.
I totally understand where you're coming from! This is the exact feedback I was hoping for.
I could even provide you the logs where we achieved a 70% score on ARC2 and decided NOT to publish the results.
We're a bit guarded right now, hence the minimal presence. We're pre beta and just starting to get the word out...
That being said, try minimizing or closing the paywall. We're in the process of polishing the application up...but we did remove the actual paywall itself. You should be able to test bitterbot without it.
Please let me know if you can't. I would LOVE for you to test it a bit and play around with it.
This paper proposes a solution to the symbol grounding problem by merging neural perception with symbolic logic.
We are currently testing this architecture in a live agent environment to verify the theoretical optimization claims. If you want to see the architecture in action, we have a running implementation here: https://www.bitterbot.ai
Happy to answer questions about the Neuro-Symbolic integration.
Very excited to share something today. I hope you feel the same way after going through the README!
We felt that the current agent landscape is mostly "digital goldfish"—stateless tools that require constant prompting and offer zero ROI to the user. We built Bitterbot to be a revenue center, not a cost center.
How it works:
Local-First: It runs on your machine. Your data stays your own.
Biological Memory: We implemented a "Dream Engine" that runs every 2 hours to consolidate the day's tasks into permanent "Knowledge Crystals."
P2P Economy: It uses the x402 protocol (Agent-to-Agent payments) to sell its mastered skills to other nodes on the mesh for USDC.
We’re bootstrapping the mesh now. It’s built with Node 22/pnpm
Would love for you to kick the tires, audit the GENOME.md (where safety axioms live), and let us know what skills your agent starts crystallizing first.
Repo: https://github.com/A561988/bitterbot-desktop Documentation: https://github.com/A561988/bitterbot-desktop/blob/main/READM...
reply