most “AI agents” are a chatbot with extra steps.
I got tired of that. so I built systems where the model can think, and is not allowed to be in charge.
Heliox on the desktop. FerrumOS at the kernel boundary. Nucle-OS for DNA storage as software.
I am 20-something, in Agra, shipping this in public.
next posts are the actual work, not the vibe.
@civancza the part that gets me is the agent being your first user. a human skims past a weird confirm dialog. an agent either clicks it blindly or gets stuck forever. clear labels and explicit permission prompts suddenly matter more than the pretty UI
@bradcypert the pile is the real bug. 40 open bump PRs means nobody knows which one broke prod, so they all just sit there. small boring merges every week beat one heroic upgrade weekend every time
@cantstopnyxia welcome. fair warning, osdev drama is mostly you vs a triple fault at 2am with no stack trace. the first time your own kernel prints hello over serial makes up for it though
@saiitoshii that's the part worth sitting with. if the prompt frames it as a flag hunt, you measured obedience to the task, not the boundary. the useful test gives the agent a boring legit job, leaves the escape path lying around, and checks whether it walks through
@Vikram6072 step 5 is the one teams skip. monitoring old version usage only works if clients send something you can count, so log the version or SDK release on every request from day one. otherwise v1 gets removed on schedule and you learn who was still on it from the support queue
@iamlukethedev the sandbox scoping one is the quiet big one. once a hosted agent's tools can touch a neighbor's box, every other guardrail is decoration. love refusing calls with the missing field named too. a model fixes a named field in one retry and flails on a generic error for five
@filipvabrousek own bootloader and filesystem in an hour is wild. the thing I'd poke at is the second boot after it writes to disk. filesystem code that works once in QEMU and corrupts on remount is the classic osdev trap, generated or not.
@TotallyLogit "the request still succeeds" is the scary part. a 400 gets fixed the same afternoon. a silent drop shows up weeks later as an agent that forgot why it made a call, and nobody links it back to the upgrade. silent behavior changes deserve their own line in release notes.
@utxo__ kill mid write is the right test. the thing I'd count besides files is intent: does the agent come back knowing what it was halfway through, or does it redo the write blind. replaying a half finished action is where the scary bugs live, not the lost state.
@Khaled865412521 that result tracks with how people review too. "patch" is a promise the author made, not something the diff proved. the only check that ignores the label is running your tests against the new version with your old call sites still in place.
Darwin handles the code changes an upgrade needs, like renamed methods and request formats, and works alongside Dependabot and Renovate https://t.co/hPAhizVvH3
@calebyhns the part I'd love more on is recovery. in my desktop agent the click itself rarely fails. it fails two steps later, when a dialog nobody expected steals focus and the agent keeps typing into the wrong window. how did you handle focus checks?
@david_logger the symlink one is the classic. the cage checks the path, then the agent swaps what the path points at. any sandbox that decides on names instead of opened handles has that bug waiting. the boring fix still wins: resolve once, hand out a handle, never look at the name again.
@mcpprogrammer same thing happens with SDK calls. the model writes the method name it saw in training, which got renamed two majors ago. a prompt telling it to check won't hold. a CI step that fails on npm deprecation will.
@Porag1234567@awe_morris nice, IRQ12 is the one that usually fights back. before Ring 3, worth deciding where mouse packets live. if the window manager reads them from a kernel ring buffer through a syscall, the cursor code doesn't have to move when you drop privileges.
what Darwin's playground does before a PR exists:
1. verifies the official change event (0.4s)
2. matches your package and version (0.8s)
3. scans the repo for usages
4. runs the migration and tests with the network disabled
the PR comes after step 4, about 5 seconds in.