danieljhkim

Sharing something that I am building right now for this: - https://github.com/danieljhkim/orbit - https://orbit-cli.com/

Any feedbacks are welcome

Hi HN,

I built Local Agent over the weekend to explore a few specific problems in agent runtimes: tool safety and emergent identity.

Most agent frameworks give the LLM broad access. I wanted to experiment with a tiered risk model: Tier 0 (read-only), Tier 1 (unified diff patches with backups), and Tier 2 (side-effects like deletion requiring explicit approval via a YAML policy engine).

The most experimental part is an identity I call 'Nova'. It starts with a minimal system prompt and manages its own long-term memory in a local text file. The goal was to see if an agent could evolve its own 'personality' and continuity through interaction rather than having it hard-coded in a prompt.

Looking forward to hear what you guys think.

The current state of AI engineering is fragmented.

Every "agentic" IDE or CLI tool has its own proprietary way of being "instructed": Cursor has .cursorrules, Claude Code has custom hooks, Copilot has instruction files. As developers, we are now forced to re-implement our repository's "rules of engagement" for every new tool we adopt; or even worse, our codebase becomes cluttered with all these tool-specific "instructions".

The real problem isn't that agents are "bad" at following instructions; it's that we lack a standard interface to communicate what a repository is and how it can be safely operated.

I built devBox to move the source of truth out of tool-specific config files and into a single deterministic execution contract that lives in the ".box/" directory in each repo.

The Concept: One contract, any agent.

Why this matters: This approach allows for a "Write Once, Run Anywhere" workflow for AI agents. Whether you are using Cursor, Windsurf, or a custom LLM script, they should be able to interact with your repo through the same deterministic interface and under the same security guardrails.

I'm curious to hear from others: Are you also feeling the "instruction bloat" of maintaining 5 different .rules files for 5 different tools? How are you centralizing your repo's operational logic?