Quality of Meaning
Collection
Measuring whether agent messages mean what the receiver thinks. Ontology adherence + schema fidelity, scored where it matters. • 1 item • Updated
AI & ML interests
Independent research lab. Agent infrastructure, evaluation, and the systems under LLMs. Correctness where the code executes. Receipts, not punditry.
Recent Activity
dipankarsarkar
updated a
collection 3 days ago
dipankarsarkar
published a
Space 3 days ago
dipankarsarkar
updated 2
Spaces 3 days ago
dipankarsarkar
published a
Space 3 days ago
dipankarsarkar
posted an update 3 days ago
Post
92
Your issue tracker is in the wrong place.
It lives on a server. Your code lives in git. So every time an agent picks up work it makes an API call, burns a token, fights a rate limit, and still cannot see what the other agent just did.
Move the issues into the repo. Append-only event log in git refs. Branches when you branch, merges when you merge, CRDT so two agents never conflict. No server, no database.
The coordination signal that PR-level telemetry misses lives before the pull request. The paper, and a live demo running the real tool:
Before the Pull Request: Mining Multi-Agent Coordination (2606.19616)
https://huggingface.co/spaces/neullabs/grite
If your agents share a repo, where does their shared state actually live right now?
It lives on a server. Your code lives in git. So every time an agent picks up work it makes an API call, burns a token, fights a rate limit, and still cannot see what the other agent just did.
Move the issues into the repo. Append-only event log in git refs. Branches when you branch, merges when you merge, CRDT so two agents never conflict. No server, no database.
The coordination signal that PR-level telemetry misses lives before the pull request. The paper, and a live demo running the real tool:
Before the Pull Request: Mining Multi-Agent Coordination (2606.19616)
https://huggingface.co/spaces/neullabs/grite
If your agents share a repo, where does their shared state actually live right now?
- 1 reply
dipankarsarkar
authored 13
papers 4 days ago
The Correctness Illusion in LLM-Generated GPU Kernels
Paper • 2606.20128 • Published
Before the Pull Request: Mining Multi-Agent Coordination
Paper • 2606.19616 • Published
Epistral Network: Revolutionizing Media Curation and Consumption through Decentralization
Paper • 2402.04881 • Published
Navigating the Knowledge Sea: Planet-scale answer retrieval using LLMs
Paper • 2402.05318 • Published
FairFlow Protocol: Equitable Maximal Extractable Value (MEV) mitigation in Ethereum
Paper • 2312.12654 • Published
Decentralized Deepfake Detection Blockchain Network using Dynamic Algorithm management
Paper • 2311.18545 • Published
Centralized Intermediation in a Decentralized Web3 Economy: Value Accrual and Extraction
Paper • 2311.08234 • Published
Towards Universal Atomic Composability: A Formal Model for Multi-Rollup Environments on Ethereum
Paper • 2311.00422 • Published
Generalised DePIN Protocol: A Framework for Decentralized Physical Infrastructure Networks
Paper • 2311.00551 • Published
Curriculum generation using Autoencoder based continuous optimization
Paper • 2106.08569 • Published
CatFedAvg: Optimising Communication-efficiency and Classification Accuracy in Federated Learning
Paper • 2011.07229 • Published
Fed-Focal Loss for imbalanced data classification in Federated Learning
Paper • 2011.06283 • Published
Test-Input Generation for Tensor Programs: What Actually Finds Kernel Bugs
Paper • 2606.27396 • Published
dipankarsarkar
posted an update 5 days ago
Post
86
LLM-generated GPU kernels pass the standard correctness test and are still wrong.
The industry oracle is one line: torch.allclose at one shape, one dtype, one seed. Every modern kernel benchmark uses it. It is blind to whole bug classes.
So I built the receipts:
- a 26-op corpus of correct and LLM-buggy kernels
- a differential fuzz vs an fp64 reference that catches what allclose misses
- a live demo you can click
The Correctness Illusion in LLM-Generated GPU Kernels (2606.20128)
dipankarsarkar/gpuemu-corpus
dipankarsarkar/the-correctness-illusion
What is your teams actual correctness oracle for generated kernels?
The industry oracle is one line: torch.allclose at one shape, one dtype, one seed. Every modern kernel benchmark uses it. It is blind to whole bug classes.
So I built the receipts:
- a 26-op corpus of correct and LLM-buggy kernels
- a differential fuzz vs an fp64 reference that catches what allclose misses
- a live demo you can click
The Correctness Illusion in LLM-Generated GPU Kernels (2606.20128)
dipankarsarkar/gpuemu-corpus
dipankarsarkar/the-correctness-illusion
What is your teams actual correctness oracle for generated kernels?