Comments URL: https://news.ycombinator.com/item?id=48063085

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47920919

Points: 2

# Comments: 0

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.

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.

Comments URL: https://news.ycombinator.com/item?id=47847897

Points: 3

# Comments: 1

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.

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.

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

let me describe my workflow first - this has been my workflow across hundreds of successful sessions: 1. identify bugs through dogfooding 2. ask claude code to investigate the codebase for three potential root causes. 3. paste the root causes and proposed fixes to claude project where i store all architecture doc and design decision for it to evaluate 4. discuss with claude in project to write detailed task spec - the task spec will have a specified format with all sorts of test 5. give it back to claude code to implement the fix

in today's session, the root cause analysis was still great, but the proposed fixes are so bad that i really think that's how most of vibe coded project lost maintainability in the long run.

there is two of the root causes and proposed fix:

bug: agent asks for user approval, but sometimes the approval popup doesnt show up. i tried sending a message to unstick it. message got silently swallowed. agent looks dead. and i needed to restart the entire thing.

claude's evaluation: root cause 1: the approval popup is sent once over a live connection. if the user's ui isn't connected at that moment — page refresh, phone backgrounded, flaky connection — they never see it. no retry, no recovery.

this is actually true.

proposed fix "let's save approval state to disk so it survives crashes". sounds fine but then the key is by design, if things crashes, the agent will cold-resume from the session log, and it wont pick up the approval state anyway. the fix just add schema complexity and it's completely useless

root cause 2: when an approval gets interrupted (daemon crash, user restart), there's an orphan tool_call in the session history with no matching tool_result.

proposed fix: "write a synthetic tool_result to keep the session file structurally valid." sounds clean. but i asked: who actually breaks on this? the LLM API? no, it handles missing results. the session replay? no, it reads what's there. the orphan tool_call accurately represents what happened: the tool was called but never completed. that's the truth. writing a fake result to paper over it introduces a new write-coordination concern (when exactly do you write the fake result? what if the daemon crashes during the write?) to solve a problem that doesn't exist. the session file isn't "broken." it's accurate.

claude had full architecture docs, the codebase, and over a hundred sessions of project history in context. it still reaches for the complex solution because it LOOKS like good engineering. it never asked "does it even matter after a restart?"

i have personally encounterd this preference for seemingly more robust over-engineering multiple times. and i genuinely believe that this is where human operate actually should step in, instead of giving an one-sentence requirement and watches agents to do all sorts of "robust" engineering.

Comments URL: https://news.ycombinator.com/item?id=47778946

Points: 7

# Comments: 3

1. must isolate context. discuss with your architecture agent, implement with another. you can pass the implementation results back to the architecture agent to check for implementation drift. ai's self check and correction sucks - i guess it is because of the attention mechansim?

2. iterate with your architecture agent to produce a tightly scoped task spec. really need to iterate, ask it your align with you for the key assumption. dont be too ambitious. i myself has a guideline for task spec writing that specify spec cannot cross boundary or work with 2 subsystems in one go

but honestly, ai is only great at diagnosis and implementation. most of my successful runs are on the basis that i know exactly how to code or how to solve the problem. ai just do the dirty work for me.

but i will argue one thing though. the spec approach is good enough with the current model capability. it is the matter of scoping. if you scope the spec correctly and granular enough, the agent will produce replicable implementation. and if i am to look into future, as model capabilities advances, the spec approach will be better and better, allowing for larger spec scope to be implemented at once

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.