jameschaearley

Love the pixel office. Such a fun way to make multi-agent work less abstract. Being able to actually watch agents walk to their desks and pick up tasks makes it way easier to follow what's happening than staring at terminal logs. Curious if the orchestrator handles cases where two agents need to edit the same file.

Since the vault sees every outbound request with the real credential attached, are you logging all of that? Feels like you're sitting on a full audit trail of everything agents actually did across services. That would be huge for debugging agent behavior after the fact.

Love this. Going from "interpret the UI and guess what to click" to "here are the functions you can call" is how it should have always worked. Since the tools are just JS on the page, could the site surface what the agent is doing to the user in real time? Would be cool for human-in-the-loop stuff where you want to approve actions before they execute.

Really excited to see where this goes.

Oh one other idea that popped into my mind is getting facial and vocal emotion data to help drive supportive interactions. One thing that is lost in lot of these tools is guiding folks when the action taken isn't one that is expected. I think back to when I was trying to get Google Assistant to play a particular song but was getting it wrong (I actually had the title wrong but I didn't know that then) I asked it 4-5 times with my tone getting more and more frustrated and it just continued playing the same song. If it knew I was getting frustrated it could have went "Sounds like i'm not getting the right song, can you hum the tune or say some of the lyrics".

Running multiple agents and having to check each terminal tab to know what's happening is annoying and this is a cute way to solve it. Love it! Curious how agentprobe/core detects the lifecycle transitions, especially the difference between "idle between tasks" and "actually stuck."

Interesting idea. Does the Docker sandbox protect against anything beyond file system changes though? With --dangerously-skip-permissions the agent can still hit external APIs, databases, etc. from inside the container. Curious what the threat model is here.

For motor disability accessibility, the architecture advantage is real. Most assistive tech sits outside the app and navigates by DOM tree or pixel position, which is brittle. Since you're inside the React tree, you could expose semantic actions — not just "click the third button" but "open this ticket" — which is what users actually want to do. That beats anything screen readers offer today.

And it's not just permanent disability. Temporary and situational cases are everywhere and constantly overlooked — a parent holding a child, someone with a broken arm, post-surgery recovery. These people aren't going to install a full assistive tech stack for a few weeks or a few minutes. But gaze + voice built into the app they're already using? That's zero-friction.

The real value is combining inputs. Gaze to set context, voice for commands, and simple nonverbal signals (blink, nod) for confirm/cancel. That covers users who have voice but limited mobility and users who have gaze control but inconsistent speech. Most assistive tools force you to pick one input mode. Having all three with shared app context is the differentiator.

Even starting with head nod as a binary yes/no would unlock a lot. Reduces the voice dependency for simple interactions and makes the whole system more resilient when one input channel is unreliable.

6832 bytes for the core loop really shows how little actual agent logic exists once you strip away the framework overhead. Cool that you went all the way to assembly to make it visible. The pipe architecture is slick too since you never have to touch the binary to extend it.

I see a huge accessibility opportunity for this. Gaze + voice running inside the app (with actual React state access) is way more reliable than screen-reader bolt-ons for hands-free use. Curious if you've thought about other nonverbal inputs, head nods for confirm/cancel, blink patterns, facial expressions since you already have the webcam feed.

Monster Rancher was one of those games where half the fun was just raiding your parents' CD collection to see what you'd get. URLs are a solid stand-in for that.

I read through SKILL.md and liked how the type heuristics and stat scaling are structured as loose guardrails rather than rigid formulas. The "decide the vibe" step before any stats get generated is a good call -- it seems like that's what keeps the creatures from feeling like generic fantasy output. How much iteration did that take to land on? Did earlier versions skip that step and just go straight to stat generation?

This is the tension I keep hitting when building data tools on top of LLMs. A nice-looking chart makes the output feel more trustworthy, but the data can still be wrong. The chart just makes it harder to notice. LLMs still need to come with receipts of where the data came from and the math they did. It's as bad as "I read the headline so I know everything in the article."