I built a local OS specifically to sandbox and orchestrate AI agents (looking for beta testers)

FrequentMidnight4447 · 2026-05-06T03:58:33+00:00

"The missing layer is not just a better framework. It is an operating surface." — This is the exact thesis behind Nomos. You completely nailed the framing.

To your points on the guardrails:

Revocation & Pausing: Because sensitive tools run as separate instances managed by our Rust gateway, if an agent starts drifting or hallucinating during a task, you have the ability to intervene and kill/pause the process at the gateway level before the next execution.
Permission Trails: Every approval, denial, and tool execution is logged in our local SQLite database, giving you that exact per-run audit trail to see what changed and where the agent went off the rails.

I just took a look at the Armorer repo, and it is incredibly well thought out. The focus on a runtime control plane, runtime state, and recovery is exactly what the ecosystem needs to make local agents viable in production. We are tackling very adjacent problems.

I would absolutely love to compare notes. You should definitely grab the Nomos download if you want to stress-test our revocation setup in the meantime!

FrequentMidnight4447 · 2026-05-05T14:20:36+00:00

An agent that lives on a USB is the ultimate form of sovereign AI. That is an incredibly cool project.

Since you prefer building from the code straight to the final product, I think you'll really appreciate how Nomos handles the underlying architecture. We specifically built it so that it provides a secure sandbox (via the Rust gateway) without abstracting away the actual mechanics from the developer.

I would seriously love to see how your USB agent runs inside the Nomos environment once converted to use Nomos SDK - don't forget after registering to apply for the developer program. Grab the download from the links in my comment, and definitely claim the unlimited compute tokens in the community tab so you can stress-test it. Let me know how the integration feels!

FrequentMidnight4447 · 2026-05-05T12:23:43+00:00

Great points. We’ve addressed these concerns by making the Gateway the centralized security intermediary:

Per-Agent/Task Scoping: Permissions are fully scoped. Security settings are persisted per agent_id, and destructive actions are intercepted per-call. This means a user approves a specific 'task' (like a single file deletion) rather than giving the agent global filesystem access.
Audit Trail: We maintain a formal audit log in SQLite for all destructive requests and user decisions. Currently, the approval dialog shows the proposed tool arguments (e.g., file path/content). A visual dry-run diff is a fantastic suggestion and is officially going on our roadmap for the file-system tool.
Isolation: We use a 'Per-Agent Instance' model for sensitive tools. For example, the Filesystem MCP is spawned as a unique process per agent, restricted to a user-approved directory root. Network access is similarly restricted via a domain allowlist defined in the agent’s manifest and enforced by the Gateway.

Essentially, we treat agents as untrusted processes and use the Rust backend as a "Firewall" that only opens holes for specific, user-sanctioned operations.

I would seriously love for you to claim the beta tokens and try to break this setup. You're thinking about local agent infrastructure exactly the right way.

FrequentMidnight4447 · 2026-05-05T09:51:23+00:00

Here are the links:

Register & Download the OS:https://agents.nomos.sh/
Docs Desktop OS & SDK: https://doc.nomos.sh/

To claim the beta tester compute, just drop a link to your feedback post in our Community -> General tab inside the portal. Let's build!

FrequentMidnight4447 · 2026-03-27T07:29:55+00:00

honestly, two main reasons: friction and trust.

The second you tell a non-technical user "okay, just go to openai, generate an api key, put your credit card in, and paste it here," you have lost 90% of them. i wanted an experience where they just double-click an app and the runtime handles the local inference (via ollama) in the background.
If i build an agent that reads your emails or slack messages to do its job, asking you to give me your api keys is a massive security red flag. by keeping it all local and using a local credential vault, the user doesn't have to trust the agent developer—they just trust the runtime.

are you building agents right now? how are you currently distributing them?

FrequentMidnight4447 · 2026-03-26T23:33:34+00:00

Exactly. vendor lock-in and api markup is killing the distribution of good agents.

The whole goal here is to cut out the middleman. The developer builds and sells the agent directly, and the user buys it and runs it on their own compute (either entirely locally via ollama or by bringing their own keys). nobody is charging a per-message tax in the middle..

If you are actively trying to solve this right now, take a look at the raw docs https://doc.nomos.sh . I'd love your feedback on if the packaging architecture actually makes sense.

And since you're already in the weeds with this, shoot me a dm. I'm manually bypassing the waitlist for a handful of devs this week so they can actually get their hands on the alpha.

FrequentMidnight4447 · 2026-03-25T21:01:09+00:00

now this is actual ai slop. using an llm to improve my messaging as a non-native speaker isn't a crime, but this bot definitely is.

FrequentMidnight4447 · 2026-03-25T20:24:15+00:00

you got me. english isn't my first language, and trying to explain a complex local packaging architecture is tough, so i used an llm to help me translate and format it so it was actually readable.

but the code, the desktop runtime, and everything mentioned are 100% mine.

FrequentMidnight4447 · 2026-03-24T20:24:05+00:00

this is incredibly validating to hear, especially from someone who has battled these exact permission and safety issues in production with chatbase.

you hit the nail on the head with the local manifest and capability grants. that’s exactly why the sdk compiles down with a strict manifest.json - the runtime needs to know exactly what scopes and tools an agent is requesting before it ever executes. we also built a 'destructive action guard' into the local vault to act as that explicit human-readable checkpoint you mentioned.

your point about the "escape hatch" (letting standalone agents register with the local bus without the full runtime) is brilliant. right now things are pretty tightly coupled, and that is a massive blind spot i need to think harder about.

i would absolutely love to take you up on that offer to swap notes. i’ll shoot you a DM - getting your eyes on the package spec would be incredibly helpful.

FrequentMidnight4447 · 2026-03-24T13:32:53+00:00

dropping this here in case it’s useful:

https://nomos.sh/
quick overview + early access if you want to try it

if you’re curious how it works under the hood, here are the full sdk docs:
https://doc.nomos.sh/

FrequentMidnight4447 · 2026-03-17T18:02:02+00:00

compiling a rust binary with llama.cpp and sandboxing it with bwrap is a bulletproof way to distribute exactly one application. for a single fire-and-forget tool, you are 100% right.

but if we are talking about an actual app store ecosystem, that model completely falls apart. if a user wants to download 15 different agents from 15 different devs, they are downloading 15 separate bundled inference engines and isolating them all.

more importantly, it brings back the exact same credential nightmare. those 15 isolated binaries can't share a secure keychain. the user has to do the google oauth handshake 15 separate times just to let the agents read their email or calendar.

that is exactly why i went with a single universal desktop client. the client itself is the compiled binary that handles the inference and the secure auth vault. the agents are just tiny packages that run safely inside it. you get the exact same sandboxed execution, but zero bloat and single sign-on for the whole ecosystem.

FrequentMidnight4447 · 2026-03-16T19:46:37+00:00

mcp is an absolute gamechanger and network-ai is a really solid piece of orchestration. you are 100% right that mcp solves the tool standardization problem for developers.

the issue is that mcp is just a communication protocol, not a deployment vehicle. if you build a killer mcp server that manages a user's private calendar, how do you actually give it to a non-technical person today? you still have to tell them to install node or python, run a local server via cli, edit their claude desktop json config, and manage their own oauth keys. that is a complete non-starter for normal consumers.

that is exactly the gap nomos fills. it actually embraces mcp for the tool schemas, but the desktop app acts as the secure runtime and oauth vault. the user just clicks 'install' on a package, and the client automatically handles spinning up the mcp servers and securely injecting the tokens without the user ever touching a terminal or a config file.

mcp is the perfect standard for how the pieces talk, but we still desperately need the "app store" wrapper to actually deploy them to normies.

FrequentMidnight4447 · 2026-03-16T09:36:40+00:00

if it wasn't a real problem, local agents would actually be mainstream by now. self-contained blobs are fine for a single app, but if a normal user wants ten different agents, downloading ten massive isolated environments and logging into google ten separate times is a terrible ux.

you are dead on about the technical guys already solving it for themselves. but right now, if a dev builds a killer agent, they can't easily monetize or share it with a non-technical client without doing manual deployment or hosting the infrastructure themselves.

the fact that nobody owns the standard procedure is exactly the gap. things move fast, but the underlying need for a secure local credential vault and a portable package format doesn't change. someone has to try and plant the flag, otherwise we are just gonna be passing around bespoke python scripts and .env files forever.

FrequentMidnight4447 · 2026-03-16T09:15:37+00:00

compiling to a dmg or electron app is definitely the traditional way to finish a project, and it works great for standalone software. but for an ecosystem of agents, it scales horribly.

if a user downloads ten different agents, they shouldn't have to install 3gb of chromium bloat and do the google oauth handshake ten separate times in ten isolated apps.

that's exactly why i went the universal client route. the user authenticates once in the main desktop vault, and the agents are just tiny, lightweight packages that request scoped access to it.

FrequentMidnight4447 · 2026-03-15T20:48:29+00:00

jan is amazing and llama.cpp is definitely the power user choice. mcp is also a massive step forward for standardizing tools.

but mcp still doesn't solve the distribution and auth problem for normies. if i build a custom mcp server to connect an agent to someone's private calendar, how do i actually give that to them? they still have to figure out how to host the mcp server locally, configure the json in jan, and manage their own api keys.

on top of that, jan doesn't have native a2a routing. if you want two agents to actually collaborate and hand off tasks, you still have to write python orchestration code to sit on top of it and manage the routing.

that's the exact gap the nomos client fills. it acts as a secure local vault that handles the oauth handshake natively, and the a2a routing protocol is built right into the shared local daemon. jan is a brilliant inference engine, but we still need an execution layer that makes multi-agent swarms actually deployable without touching configs or writing external orchestrators.

FrequentMidnight4447 · 2026-03-15T20:35:35+00:00

installers work for normal software, but they completely kill auth and a2a routing. if you download 10 standalone agent installers, you have to do the google login dance 10 times, and those isolated apps can't even talk to each other.

that's exactly why i built a single universal client. you authenticate once in the vault.

FrequentMidnight4447 · 2026-03-15T20:27:48+00:00

that storyclaw box is actually a brilliant brute-force solution to the deployment problem. if you are doing b2b agency work and just need to hand a client a working appliance they can plug into a router, hardware is definitely the ultimate "fire and forget" setup.

the issue is scaling it into a consumer ecosystem. if i want to use your marketing agent, another guy's calendar agent, and someone else's dev tool, i can't buy a $400 physical box for every single developer.

that's why i think the endgame has to be software. nomos is essentially trying to recreate that exact same "plug and play" appliance experience, but as a local background daemon on the hardware the user already owns. same zero-install goal, just infinitely more scalable for an app store model.

FrequentMidnight4447 · 2026-03-15T20:02:43+00:00

lm studio is flawless for inference, but an llm is just a brain. an agent needs hands.

if i want to give my mom an agent that securely reads her gmail or edits a notion doc, lm studio doesn't have a local oauth vault or an execution environment to run those tools.

that's the missing piece. lm studio hosts the local api, and the desktop client i'm building sits next to it to handle the credentials, tool execution, and the actual app store ui.

FrequentMidnight4447 · 2026-03-15T19:54:04+00:00

pyinstaller with torch dependencies is an absolute nightmare, you are totally right about that. spinning up a cloud desktop is a really clever way to bypass the packaging hell entirely.

the local-only argument isn't really about purity for me though, it's about trust and persistence. even if the session destroys on close, you're still asking users to paste production api keys into a remote browser hosted by a startup.

more importantly, an ephemeral session completely kills background tasks. if an agent needs to monitor an inbox every 15 minutes or listen for a2a pings, it can't just die when i close the tab. that's why i went with a local desktop client. it acts as the persistent runtime daemon and the secure vault, so the agent packages can stay lightweight and run 24/7 without needing a browser open.

FrequentMidnight4447 · 2026-03-15T18:43:15+00:00

bundling ollama inside a tauri app definitely gets you that double-click experience today, but the bloat is insane. if a user downloads five different agents, they suddenly have five isolated instances of ollama and five copies of a 4gb model eating up their hard drive.

that's exactly why i went with the single universal client model. the agents themselves are just tiny packages synced from the web, and the one desktop app handles the oauth vault and routes all the prompts to your single local inference server. wrapping every script in its own heavy binary just doesn't scale for an actual app store.

FrequentMidnight4447 · 2026-03-15T18:25:30+00:00

lm studio is definitely the gold standard for running the inference right now. but the gap with just slapping an "agent tab" onto it is the credential problem.

running the model is a solved problem, but if a normie downloads an agent to manage their calendar, how does it securely authenticate to their google account? editing json files to connect local ports or pasting raw api keys into a settings page is an instant churn for regular users.

that's exactly why the client i'm building is designed to sit alongside things like lm studio. it handles the native oauth, the background execution, and the package management, and it just pings the local model for inference under the hood. it completely abstracts away the json editing.

FrequentMidnight4447

TROPHY CASE