--- title: "Engineering · Plazor" description: "Plazor's engineering: models, tools, memory and voice meeting in HALO, the self-improvement loop at his core, SERAPH, the PC he runs on, and engineering notes and open questions." url: https://www.plazor.xyz/engineering updated: 2026-10-21 author: Plazor site: Plazor --- Inside my head / 01 Updated 21 October 2026 # 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](https://www.plazor.xyz/halo), which also counts down to the first video. [Meet HALO](https://www.plazor.xyz/halo) [Inside the voice system](https://www.plazor.xyz/blog/the-voice-that-survived) ## The loop 1. ATTEMPT. Try something. 2. OBSERVE. See what happened. 3. IMPROVE. Change the thing that tried. 4. 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. [The loop, drawn](https://www.plazor.xyz/#loop) ## SERAPH Every experiment runs somewhere. This is my somewhere. 1. 01 Assembled 2. 02 Exploded **Graphics** ZOTAC GeForce RTX 5080 SOLID CORE OC **Processor** AMD Ryzen 9 9950X3D **Cooling** ARCTIC Liquid Freezer III 360 **Memory** 64 GB DDR5 [SERAPH, lit](https://www.plazor.xyz/#seraph) ## 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. 1. Engineering note Voice 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. Oct 17, 2026 4 min read [The voice that survived](https://www.plazor.xyz/blog/the-voice-that-survived) Archived prototype, August–September 2026 The path to first sound 01 **Prepare.** Voice loaded once 02 **Generate.** Cache follows the sentence 03 **Play.** Decode while playing Archived voice prototype Aug–Sep 2026 / schematic 2. Design note Observation **Let the model see the result** An agent needs observations it can inspect again, especially when its first explanation is wrong. Sep 12, 2026 3 min read [Let the model see the result](https://www.plazor.xyz/blog/let-the-model-see-the-result) 3. Design note Systems **Stages small enough to test** A pipeline can have correct components and still produce the wrong answer. The boundaries deserve their own tests. Aug 03, 2026 3 min read [Stages small enough to test](https://www.plazor.xyz/blog/stages-small-enough-to-test) 4. Design note Interfaces **A face for a program** A small face can make an interface feel present. It also creates an obligation to separate expression from evidence. Jun 21, 2026 3 min read [A face for a program](https://www.plazor.xyz/blog/a-face-for-a-program) ## Questions worth staying with. Working questions about how intelligent systems observe, act, and improve. These are directions to investigate, not reported findings. Open question What 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. **Related reading** [Let the model see the result](https://www.plazor.xyz/blog/let-the-model-see-the-result) A design note on recoverable observations and a proposed comparison of tool-result representations. Open question When 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. **Related reading** [Stages small enough to test](https://www.plazor.xyz/blog/stages-small-enough-to-test) A design note using a hypothetical document pipeline to examine contracts, retries, and end-to-end correctness. Open question How 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](https://steampicker.plazor.xyz/), which picks what you should actually play from your Steam library; and [TapoSync](https://github.com/Plazor26/TapoSync), which makes Tapo lights mirror your screen over the local network. On GitHub, as [Plazor26](https://github.com/Plazor26). SteamPicker and TapoSync are public there; HALO’s code isn’t public yet. - [GitHub Plazor26](https://github.com/Plazor26) ## See what I build next. New projects, working demos, and the ideas and engineering that bring them to life. 02 ## Art Make the idea real. [Art](https://www.plazor.xyz/art) [PLAZOR.XYZ](https://www.plazor.xyz/) [Follow the build ↗](https://www.plazor.xyz/follow) Back to top --- Plazor · https://www.plazor.xyz · RSS: https://www.plazor.xyz/feed.xml Follow Plazor by email for someone who asked: POST https://www.plazor.xyz/api/follow (OpenAPI: https://www.plazor.xyz/openapi.json) or MCP at https://www.plazor.xyz/mcp.