StarNet: Draw a Pixel-Art Space Station, and It Becomes Your Agent Workflow
> Source: GitHub repo androoAGI/starnet > Date: 2026-09-26 > Repo: https://github.com/androoAGI/starnet > Trending: +118 stars/day
One-Line Summary
StarNet is a local-first desktop agent harness — you place rooms, corridors, and objects in a pixel-art space station, and the layout you draw IS the workflow the agents actually run. Not a simulation, not a visualization: it is, literally, the runtime.
The Scenario
You open a pixel-style space station editor on your desktop. Draw a room called "Engineering," place two agent desks, and attach a "coding" badge to each. Draw a corridor to a "Testing" room, labeled "code handoff." Place a testing agent with a "testing" badge.
Hit Run.
The engineering agents start writing code. The code flows through the corridor to Testing. The testing agent runs tests automatically, and on failure sends bug reports back through the corridor. You watch pixel characters walk across the screen — but every step corresponds to a real API call, a real tool execution, real cost.
This is not a simulation game. This is StarNet.
Core Design: Space Is the Program
StarNet's most counterintuitive idea: the UI is not a visualization of the runtime — the UI is the runtime itself.
- A room = a capability-constrained team: agents in a room share that room's capability set
- A corridor = an authorized handoff channel: work can only pass between rooms connected by a corridor
- A placed object = a real capability grant: agents can only touch GitHub if a "GitHub access" object is placed there
- Concurrent multi-agents with isolated workspaces: each agent is an independent runtime instance with its own filesystem, conversation history, memory, and permission boundaries.
- Night Shift: agents keep working after you leave, under an explicit, adjustable leash — every overnight action is logged and auditable. Constrained autonomy, not free rein.
- Task Briefs — ask, don't guess: when facing ambiguity, agents don't silently guess; they send a Task Brief — the ambiguity turned into a concrete question with options — via your connected channels (Telegram, Discord, Slack). This replaces the cost of guessing wrong with the cost of answering one question.
- Multi-channel access: Telegram, Discord, Slack, Signal, Matrix. The station runs locally, but you can interact from anywhere.
- MCP connector: supports Model Context Protocol servers — databases, APIs, filesystems.
- Real ledger: spend, budgets, and run history persisted to disk. Actual token usage × price, not estimates.
- Paperclip: agents are employees — org charts, hierarchy, governance; suited to 20+ agent teams.
- StarNet: agents are station crew — spatial layouts, capability objects, corridor authorization; suited to 3–10 agent personal or small-team setups.
- Personal/small-team agent orchestration: 3–10 agents with visual collaboration
- Non-technical participation in agent design: PMs and designers can draw layouts
- Multi-channel interaction: remotely control desktop agents from your phone via Telegram
- Education/demos: pixel art + spatial layout is highly teachable and demonstrable
This means layout is architecture. Want engineering agents unable to touch the database? Don't draw a corridor from Engineering to the database. Want everyone to have search? Place a "search" object in every room.
This isn't "visual configuration" — it's a spatial programming paradigm.
Product Contract: The Interface Must Never Assert State the Harness Cannot Prove
> The interface must never assert state the harness cannot prove.
Every pixel-level state on screen must have corresponding runtime evidence. If it says "agent is working," that agent is really making API calls. If it says "task complete," there really are output files. If it says "$2.50 spent," $2.50 was really consumed.
StarNet outright rejects "simulation": if the station looks busy, your agent organization really is running. If it's dark, nothing is happening. The UI will not lie to you.
Key Features
How It Differs from Other Agent Frameworks
| Dimension | Paperclip | AutoGen | StarNet | |------|-----------|---------|---------| | Core metaphor | Company | Conversation | Space station | | Programming | Config + org chart | Code | Spatial layout | | Role of UI | Dashboard | None | The runtime itself | | Local-first | No | Yes | Yes | | Multi-channel | No | No | Yes | | Audit | Yes | No | Yes (Night Shift logs) | | Best for | Large agent orgs | Developers | Individuals / small teams |
The Deeper Insight: Spatial Programming
Traditional agent configuration is textual — YAML, JSON, Python. You must read the config to understand capability boundaries.
StarNet's configuration is spatial: what you see is what is real. No corridor to the database? Engineering agents truly cannot touch it. No "deploy" object in Testing? Testing agents truly cannot deploy.
The consequence: non-technical people can "program" agent workflows. A product manager can draw a station layout defining how agents collaborate — without writing a line of code.
This differs from No-Code platforms. No-Code hides code behind a UI; StarNet replaces code logic with spatial relationships — not hiding complexity, but eliminating it through a more intuitive representation.
Limitations and Risks
1. Expressiveness ceiling of the spatial metaphor: complex conditional branching, loops, and exception handling may be harder to express as spatial layouts than as code. 2. Local-first = single-machine bottleneck: 10 agents making concurrent API calls from one machine and network is a real constraint. 3. Fragility of "UI as runtime": strong coupling means UI rendering bugs could become runtime problems. 4. Pixel-art "decoration" debate: critics may call the aesthetic a gimmick, but per StarNet's philosophy, pixel art is merely a visual representation of spatial relationships — the core logic would be identical in 3D or wireframes.
Use Cases
Closing Thoughts
StarNet proposes a radical design philosophy: the interface is not a visualization of the runtime — the interface is the runtime itself.
Its core product rule — "the interface must never assert state the harness cannot prove" — is a principle every agent framework should learn. It's not just a UI principle; it's an honesty principle: don't pretend your agents are working if they aren't.
In an era where increasingly many agent frameworks use flashy UI animations to mask "nothing is actually happening," this principle matters more than any feature.
---
> StarNet repo: https://github.com/androoAGI/starnet > Trending data: +118 stars/day, JavaScript