10keane

been thinking about this exact problem for a while. my own setup uses OS keyring with a <secret:name> token substitution pattern — the agent requests a credential by name, the substitution happens at execution time, the LLM never sees the raw value in context or logs. works reasonably well.

but the problem with that model is it's static protection. if the agent process itself becomes hostile or gets prompt-injected, keyring doesn't really help — it can still request the secret and get it, it just doesn't see it in the context window.

the shift i've been landing on and building into Orbital(my own project) is that it's less about blocking credential access and more about supervising it. you want to know exactly when and why the agent is requesting something, and have the ability to approve or deny in the moment. pre-set policies are hard because you genuinely can't anticipate what tools an agent will call before it runs — claude code might use curl, bash, or a completely random command depending on the problem. the approval needs to happen at runtime, not preset.

the proxy model here is interesting because it creates a natural supervision boundary. curious whether you're planning runtime approval flows or if the design stays policy-based.

i actually like the concept of workspace agent, because i am feeling some real pain here to run long-term project while retaining context for each instance of agent. but based on the demo it seems more like for cooperation instead of preserving long-term project state: decisions made, actions taken, approvals given, history of what each agent did and why. it is then just a more convenient chatgpt entry in group chat.

another thing: this is all on OpenAI's servers. Which is fine if that's what you want. But there's a real class of user — technical, working on actual production code, security-conscious — for whom "my workspace lives on my machine, in my git repo, under my version control, works for my other non-openai tools" is a hard requirement, not a preference.

Hi HN, I'm keane. Orbital is an open-source desktop app for running AI agents in a managed environment. Been building it for two months while holding a day job. Solo dev, mac and windows installers on the release page.

Why this exists:

- I loved Claude Projects, but I couldn't let an agent update the project, and it didn't live on my machine. Cowork Projects now can — but only Claude, closed source.

- I loved OpenClaw, but I had no control over what it was doing on my behalf.

Neither was the thing I actually wanted.

The thing I actually wanted is rooted in a belief about where agent-human interaction is going: from micromanagement to delegation.

Micromanagement — where most of us are today. You give a specific task. You hand-hold the agent, watch it work, provide context when it asks, correct it when it drifts. You're guiding an intern.

Delegation — what I want. It's handing work to a colleague the way you would when you leave a company: you give them all the context, describe the objective, set the boundaries, and then let go. Maybe they check in periodically, but you don't watch every keystroke.

For delegation to work, the agent needs a place to live. Not a session. A "project".

What a project is in Orbital:

- A workspace folder

- Persistent human-editable memory that survives restarts

- A budget cap

- A sandbox

- An autonomy preset (supervised / check-in / hands-off)

- Approval gates on write-risk tool calls

- A shared space for sub-agent coordination. The management agent is an autonomous agent I wrote; sub-agents (Claude Code, Codex, Goose, Cline) are discovered via SDK/ACP/PTY on the system path and called with separate context windows so their output doesn't bleed back into the main one.

The project is the unit you delegate. Everything else — approvals, budgets, memory, boundaries — are the affordances that make delegation actually safe.

Everything is transparent. Everything, from input to output, is on your machine. The only thing that leaves is the LLM API call.

Where this fits relative to other things:

- Claude/Cowork Projects: closest mental model, but you can't dispatch other agents like Codex to work in parallel. Exclusive to Claude.

- OpenClaw / Hermes: session-centric or agent-centric. Orbital is project-centric. Your project can delegate to them as sub-agents (planned).

What's real today. 335 commits over two months. Desktop installers for mac and windows. Used daily for a month — including to run my own launch prep. There's a distilled marketing-agent skill inside the repo that reads my calendar and drafts the next day's tasks, which is how I'm shipping this at all while holding a day job.

What's not there yet. Linux sandbox. Native mobile app (today it's LAN QR pairing plus an optional relay for remote supervision). Agent marketplace. Cross-project coordination with approval cascades. Adaptive autonomy.

Happy to answer questions about the architecture, the sub-agent handoff, the sandbox trade-offs, or anything else.

management and critical thinking.

management - it occured to me that giving instructions to agent is very similar to giving instructions to human employees - even the best of them make mistakes.

i learnt that asking claude code to "investigate for 3 potential root causes" is more effective than "investigate the root cause" in bug fix. this blows my mind as i realize that agent can be lazy, can be careless, and we can give better instruction to prevent that.

another reason why i said this is that giving enough context and defining blast boundary is more efficient than hand-holding/micromanaging and checking every tool call for agents. the management skill for human employees also works here.

critical thinking - you just need to have your judgement on the seemingly solid but actually halluncinated agent bs.

idk man. what do you think is their business model? is it more like ai value-add on their existing services?

i am using --dangerously-skip-permissions with task spec. think this is faster. and it gave me more control actually over architecture and product decision. i think i just dont like reacting to suggestions mid-flow

great project. think my agent will need it. but then one thing i notice is that this only catches single tool calls. most of the time the malicious behavior is a sequence where each call looks fine on its own: read a file, read another, then a curl to somewhere benign-sounding. individually each one scores low. the arc is the dangerous part and per-call scoring kinda misses that.

what is the point of teaching anyway when fundational knowledge are becoming obsolete?

i think what should be taught is the metacognative ability - like how to retrieve knowledge, how to ask the right questions towards a certain goal. knowledge itself are easily accessible with ai. now the difficult part is the ability to discern actual knowledge from llm halucination bs, the ability to retrieve the required knowledge given a scenario.

this still requires some foundational grounding — you can't detect bullshit with zero context. but the balance shifts from memorization to retrieval, iteration, verification. honestly i think it is more about critical thinking and philosophy.

What have we done... like in the Manhattan Project - Sam Altman when releasing gpt5.1

exactly. vibe coding only works when you fully understand the problem and know precisely how to solve it. ai just do the dirty implementation work for you.

that is another reason in why i separate product/architecture design and implementation into two agents with isolated context in my workflow. because i can always iterate with the product agent to refine my understanding and THEN ask the coding agent to implement it. by that time i already have the ability to make proper judgement and evaluate coding agent's output

there is really an arbitage oppportunity now with ai. you can just throw a task to ai and do some minor edits afterwards, and claim that you do it mannually. can significantly inflate your perceived capacity lol. works for bosses that are not that ai-savvy

there are always three elements in the equations of business model: 1. marginal cost 2. marginal revenue 3. value created

for llm providers, i always believe the key is to focus on high value problems such as coding or knowledge work, becaues of the high marginal cost of having new customers - the token burnt. and low marginal revenue if the problem is not valuable enough. in this sense no llm providers can scale like previous social media platforms without taking huge losses. and no meaning user stickiness can be built unless you have users' data. and there is no meaningful business model unless people are willing to pay a high price for the problem you solve, in the same way as paying for a saas.

i am really not optimistic about the llm providers other than anthropic. it seems that the rest are just burning money, and for what? there is no clear path for monetization.

and when the local llm is powerful enough, they will soon be obsolete for the cost, and the unsustainable business model. in the end of the day, i do agree that it is the consumer hardware provider that can win this game.

this same pattern seems to occur every time a new model is about to release. i didnt notice the usage problem - i am on 20x. but opus 4.6 feels siginificantly dumber for some reason. i cant qualitify it, but it failed on everyday tasks where it used to complete perfectly

which aspects are you talking about? the kind of talent needed, management, or organisation structure? everything needs to be changed

yah keyring is more for static protection. when the agent process itself is hostile, keyring is kinda obsolete.

but then i think the key is that sometimes agent does need access to credentials to be useful - like i will give some credentials to agent such as my browser account access.

personally i feel it is not really about preventing agent from accessing credentials, but more to have the supervision layer when agent access it - like you know exactly when and why agent need to access it and you have the ability to deny or approve it.

idealistic as hell.

it has already been proven that with the current system. the enhancement of productive force will only be captured by the few. wealth will be more concentrated instead of being more distributed as corporates have more money and influence over the government, especially when the government is led by one of them with zero sympathy for everyday workers.

steam engine, electricity, internet boom - they all results in larger inequality. and this is when everyday working man still have bargining chips - their intellect and hard labor. just conceive a world where these bargining chips have been removed by ai. you think the cold hearted capitalist will give two shit about workers?

i am pessimistic. and that is why you certainly have to be on the side of the asset owner, particularly at this time. because the Matthew effect of wealth will definitely be accelerated by ai

nope. too dangerous - i'm personally working for an agent project and i know from personal experience they do collect your session log - especially in china lol. one approach i use for my own agent is that to use keyring to store all secrets. agent will call a tool to request for it, and it will be something like <secret:gmail.password>. the substitution happens at tool execution time so the llm never sees or logs the actual value.