HumanOS

Demo

About

HumanOS is a local-first workspace for people who want useful automation without becoming prompt engineers. Describe an outcome, and HumanOS turns supported requests into reusable, typed workflows for research, writing, email and scheduled work. The experience is simple: delegate the work, review meaningful external actions, and keep the final say. Instead of asking a large language model to reinvent every step, HumanOS separates decisions from execution. Jev evaluates a finite set of server-defined blocks; DeepSeek generates written content; deterministic connectors perform the work. Workflows preserve their state, outputs and execution receipts, and pause when required information or a connection is missing. This is designed to reduce repeated model reasoning and make costs more predictable; we are not claiming a measured percentage of credit savings. ENSv2 gives each workflow agent a resolvable identity beneath a human namespace, with version-bound capability scope, expiry and revocation. This also applies to agents doing offchain work, such as writing or sending email. HumanOS checks the agent's authority before dispatching supported steps. Separate permissioned resolvers isolate agent records, while receipt hashes make execution evidence inspectable without publishing private message or booking details. ENS provides identity and auditable authority—not a guarantee that generated content is true. JAW account sign-in and World ID human verification serve separate purposes: proving account control versus establishing human assurance. The current prototype includes real-provider research and content runs, local scheduling, and a Resend email test with delivery evidence. Browser-assisted restaurant booking is in progress: the TableCheck integration currently supports guarded availability inspection, not a completed production reservation. Live booking and full live-chain acceptance are not claimed as completed demos. HumanOS makes unsupported or uncertain outcomes visible rather than inventing success.

How it's made

HumanOS is a TypeScript monorepo with a React/Vite frontend, a backend API, PostgreSQL-backed workflow state, shared schemas, model adapters, connectors and Solidity contracts. Flue is part of the local service architecture. Requests are normalized into deterministic intent and parameter bindings. Jev evaluates offered typed blocks and returns structured choices; it does not generate arbitrary executable plans. DeepSeek, accessed through OpenCode, handles content generation. The server validates the graph and controls which capabilities and connectors can execute. The durable runner records graph versions, attempts, outputs and receipts. Brave supplies web search and source links; Resend supplies email dispatch. External effects use exact payload review, account binding and final confirmation. Uncertain dispatch outcomes require reconciliation rather than an automatic retry that could duplicate an email or reservation. Local schedules retain their authorization context. ENSv2 is central to agent identity and authorization. The hierarchy is task-agent.human-root.parent.eth. The HumanOS registrar and adapter create isolated Permissioned Resolver instances and restrict agent setters to humanos.status and humanos.receipt, using Enhanced Access Control rather than granting registry administration. Application-level capability scopes are bound to the workflow version; the backend combines those scopes with live checks of ownership, controller, hierarchy validity, expiry and revocation. This distinction matters: ENS record-edit roles are not themselves permission to send email or spend funds. Agent keys are backend-managed in this prototype, and only opaque receipt hashes are published onchain. JAW signs users in through backend-verified SIWE sessions. World ID/IDKit is a separate human-verification integration with server-side validation; simulator coverage is not represented as production credential acceptance. Browser automation uses a dedicated Python Browser Use worker and Chromium, communicating with the API through a framed local protocol. It uses finite actions and guarded network policies, rather than an unrestricted autonomous browsing loop. The TableCheck adapter currently checks availability only; production submission, verification handoff and final booking confirmation remain unfinished. Tests cover local contracts, authorization boundaries, cancellation, replay and browser fixtures, while live-provider evidence is tracked separately. The key engineering tradeoff is deterministic execution with explicit failure states instead of treating plausible AI output as proof of an action.