Research
The technical record: code that ships, systems I have built and run in production, and the questions I am working on now. It is deliberately narrow - what is listed here is verifiable by clicking through, and what is not listed is not claimed.
Open source
One project I maintain. The rest of my GitHub is forks I have not contributed to, so it is not listed here.
A full SIP softphone for the ESP32 and ESP32-S3. Roughly 200 KB of C: G.722 wideband codec, an LVGL touchscreen interface, captive-portal provisioning, a web phonebook, and an SDL desktop simulator so the UI can be developed without hardware. GitHub Actions builds firmware for both targets plus the simulator, and attaches signed artefacts to releases. MIT licensed.
github.com/GeorgeBregman/ESP32-SIP-VoiceFour original repositories, nineteen forks, and the commit history behind all of it.
github.com/GeorgeBregmanSystems
Two production systems that sit closest to current questions in AI reliability. Both are private codebases; the descriptions are precise about what exists and what does not.
A Go orchestrator that routes inference jobs across heterogeneous compute it does not own. Results are signed with ECDSA over secp256k1 and verified by the coordinator, so trust attaches to the output rather than to the machine. Redis Streams for job and verification queues; nodes include a self-hosted llama.cpp runner and a browser node running WebLLM over WebGPU. Currently on ARM without GPU, so throughput is small - the interesting part is the verification path, not the scale.
A supervisor-and-workers agent system that runs the day-to-day operations of a group of companies across ninety-odd web properties. What makes it useful as research material is the failure log: a maintained register of ways the agents produced confident wrong answers - an HTTP 200 read as “published”, an API success read as “the change took effect”, a tool result treated as an instruction. Each class has a written rule and a verification step attached to it.
Open questions
Four questions I think are under-examined and that I have unusual material for. Each is stated so that it could come out negative. If one of these is close to your work, I would like to hear from you.
Production agents read web pages, files and tool output all day, and some of that content contains text addressed to the agent. I have a live system and a documented set of real failures. The question is whether instruction-hierarchy training actually holds when the injected instruction is plausible, on-task and phrased as a correction rather than a command - and whether the gap between models is large enough to be worth measuring.
Method: build an eval from observed failures, score open-weight models, ablate the defence.
Screening of documents by language models is now routine - CVs, invoices, tickets, tenders. The attack surface is obvious and the defences are largely untested in public. I hold a small natural corpus of documents carrying real injection payloads, collected rather than synthesised. The question is attack success rate by payload family across models, and how much of it survives delimiting, instruction hierarchy and a detector pass.
Method: measured attack success rate, defence ablation, open corpus and code.
Aurora already does a cryptographic version of this: verify the artefact, not the producer. The open question is the semantic version. When the executor is a capable model and the verifier is a cheap one, how much of the executor’s advantage can be recovered before verification costs more than doing the work directly - and what does the verifier miss first?
Method: cost/coverage curves on tasks with checkable ground truth.
Refusals, hedging and safe-completion behaviour are heavily evaluated in English and thinly evaluated elsewhere. I work daily in English, Russian, Hebrew and German across a large multilingual corpus. The question is whether a model that refuses reliably in English refuses the same request as reliably in the other three, and whether the drift is in the classifier or in the generation.
Method: matched-prompt refusal consistency across four languages, human-checked.
Convening
Stated precisely, because the precise version is the useful one.
I convened and chaired the session and moderated the closing panel on near-term AI forecasting. It ran online in Russian on 7 March 2024, alongside OpenTalks.AI 2024 in Tbilisi - four talks and a panel across an afternoon, not a conference in its own right. The reason it is worth listing is the line-up:
Teaching & mentoring
The part of the work that is easiest to verify externally.
Publication record
A short section, because it is a short record.
Peer-reviewed machine-learning publications: none. I have not published in the ML literature. The work above is engineering and operations, and I would rather say so here than let a skills list imply otherwise. The open questions section describes what I am trying to change about that.
Earlier writing, and a note on an acronym. In 2000 I co-wrote two articles with Ilya Goz for the Russian practical-psychology project Psychology - All Russia. They are about Neuro-Linguistic Programming - the communication methodology - and specifically about representational-system predicates and reframing patterns in prose. They have nothing to do with natural language processing, they were not peer-reviewed, and they are not a technical credential. I list them because they exist and are easy to find, and because “NLP” on a page like this should never be left ambiguous.
If one of the four questions above overlaps with what you do - as a collaborator, a reviewer, or someone who thinks the question is wrong - write to me. Plain email is fine; there is no funnel behind this page.