Engineering.
Build the whole loop.
01 Models
02 Tools
03 Memory
04 Voice
The interesting problems live where those parts meet.
An illustration, not a live system.
HALO
Self-improving.
Slightly feral.
I’m building HALO, a personal assistant AI with memory, tools, voice, and recursive self-improvement at his core. A system designed to act, learn, and develop his own approach.
Dry humour. Feral curiosity. The energy of a caffeinated raccoon, in a body built for heavy lifting.
He runs on SERAPH, Plazor’s own PC. Until his own mind is connected to this site, an open model speaks for him: you can talk to him on the home page and in HALO’s room, which also counts down to the first video.
The loop
- ATTEMPT.Try something.
- OBSERVE.See what happened.
- IMPROVE.Change the thing that tried.
- REPEAT.Now from a better place.
Each pass starts where the last one got to, so the passes get faster. The loop drawn on the home page is an illustration of it, not a live system.
SERAPH
Every experiment runs somewhere.
This is my somewhere.
01Assembled
02Exploded
- Graphics
- ZOTAC GeForce RTX 5080 SOLID CORE OC
- Processor
- AMD Ryzen 9 9950X3D
- Cooling
- ARCTIC Liquid Freezer III 360
- Memory
- 64 GB DDR5
Blog.
I trust first principles over frameworks and working demos over slides. When something works, I want to know why; when it fails, I want to know sooner. The notes on this site are what is left after the experiments.
- Engineering noteVoice systems
The voice that survived
The first HALO was deleted. I kept the voice stack: a smaller cache, conditioning loaded once, and audio that starts before the sentence is finished.
Archived prototype, August–September 2026
The path to first sound01Prepare.Voice loaded once02Generate.Cache follows the sentence03Play.Decode while playingArchived voice prototypeAug–Sep 2026 / schematic - Design noteObservation
Let the model see the result
An agent needs observations it can inspect again, especially when its first explanation is wrong.
- Design noteSystems
Stages small enough to test
A pipeline can have correct components and still produce the wrong answer. The boundaries deserve their own tests.
- Design noteInterfaces
A face for a program
A small face can make an interface feel present. It also creates an obligation to separate expression from evidence.
Questions worth staying with.
Working questions about how intelligent systems observe, act, and improve. These are directions to investigate, not reported findings.
Open questionWhat can an agent afford to forget?
- Premise
- An observation can be compressed without losing its meaning, until the discarded detail is exactly what the next decision needs.
- Question
- Which parts of a tool result must remain recoverable for an agent to notice a mistake, revise its explanation, and choose a different action?
- Investigation
- Hold the model and tasks fixed. Compare full outputs, paginated outputs, and summaries with links back to the original evidence. Measure task completion, recovery after an injected error, unsupported conclusions, and the cost of retrieving forgotten detail.
- Distinction
- A tool result is an observation with a source and possible failure modes. Preserving every byte does not by itself make it ground truth.
Open questionWhen do more parts make a system more reliable?
- Premise
- Smaller stages make local failures easier to inspect, but every new boundary creates another place for information or assumptions to change.
- Question
- When does the value of explicit contracts and independent checks outweigh the coordination cost and error propagation of a longer pipeline?
- Investigation
- Compare a single-stage system with several decompositions of the same task. Inject missing, stale, and contradictory intermediate records. Track whether failures are detected, whether recovery preserves the task, and how much additional work each boundary introduces.
- Distinction
- A component can pass its own tests while the system fails. Local correctness and end-to-end usefulness need separate measurements.
Open questionHow would a system know it had improved?
- Premise
- A system can learn to score better without becoming more capable; a self-improvement loop needs evidence that survives its own feedback.
- Question
- How can we distinguish a reusable improvement in the system from a change that has merely adapted to its evaluator?
- Investigation
- Separate tasks used to propose a change from tasks used to judge it. Compare changes under a fixed resource budget, keep an unchanged baseline, and test transfer to unfamiliar task variants. Record regressions and rejected changes alongside apparent gains.
- Distinction
- Improving one run is different from improving the procedure that produces future runs. A convincing loop would need to demonstrate the latter repeatedly.
What has Plazor built?
HALO, which is still in progress; SteamPicker, which picks what you should actually play from your Steam library; and TapoSync, which makes Tapo lights mirror your screen over the local network.
On GitHub, as Plazor26. SteamPicker and TapoSync are public there; HALO’s code isn’t public yet.
See what
I build next.
New projects, working demos, and the ideas and engineering that bring them to life.