Projects, Workers & GlassHive
The durable work model behind Viventium's sandboxes, resumable workers, and longer-running execution.
Why Chat Alone Is Not Enough
Chat is great for thinking, framing, and deciding.
But some work needs:
- a durable brief
- a clear goal
- visible progress
- resumable execution
- a safer boundary around what the system can do
That is where projects, workers, and GlassHive come in.
Projects
Projects are the durable unit of work.
A project can hold:
- the mission
- context and constraints
- files and references
- outputs and review history
- the current state of the work
That makes it possible to keep work moving across days instead of turning everything into prompt soup.
Workers
Workers are the execution layer attached to projects. Each worker is an AI runtime with:
- A clear responsibility tied to one project
- A controlled sandbox environment — browser, terminal, filesystem, tools
- Full lifecycle control — pause, resume, interrupt, terminate, continue
- Live visibility — you can see what the worker is doing at any time
Workers can be powered by different AI runtimes:
- Claude Code — Anthropic's agentic coding tool
- OpenClaw — open-source agent runtime
- Codex CLI — OpenAI's command-line agent
You choose the right tool for the job. One project might use Claude Code for a codebase migration, while another uses OpenClaw for research synthesis.
GlassHive
GlassHive is the persistent worker runtime — the infrastructure that makes projects and workers real.
The name tells the story:
- Glass — full visibility into what every worker is doing
- Hive — many workers running simultaneously
What GlassHive provides
- FastAPI control plane — manages worker lifecycle, project state, and sandbox orchestration
- SQLite persistence — projects and workers survive restarts
- Workstation profiles — preconfigured sandbox templates (codex-cli, claude-code, openclaw-general)
- noVNC browser view — live visual inspection of what a worker's browser is doing
- WebSocket terminal — real-time terminal access for takeover when needed
- MCP wrapper — compatible with streamable-http, stdio, and SSE protocols
- Bootstrap bundles — portable presets to spin up a new sandbox with the right tools and auth
GlassHive is its own standalone runtime. It does not depend on the chat layer — it exists so long-running agentic work does not have to live inside one chat tab or one product shell.
The Boundary That Matters
One of the cleanest project principles in the source docs is:
1 Worker = 1 isolated environment = 1 Project
That matters because it makes delegated work:
- easier to trust
- easier to inspect
- easier to pause or take over
- less likely to blur into the wrong context
What This Unlocks
- long-running research
- structured drafting and revision loops
- browser-backed project work
- file and spreadsheet analysis tied to a deliverable
- secure autonomous work while you sleep
- multiple workers running in parallel without becoming invisible chaos
Live Visibility And Takeover
GlassHive is not a black box. At any point you can:
- Watch — see the worker's browser, terminal, and file changes in real time through noVNC and WebSocket
- Take over — drop into a worker's terminal and intervene directly
- Pause — stop a worker mid-task and resume later with full state preserved
- Inspect — review outputs, logs, and artifacts without interrupting the worker
This is critical because autonomous AI work needs governance. Delegated does not mean unsupervised. The glass in GlassHive means you always have visibility into what is happening and can steer when needed.
How This Relates To The Rest Of Viventium
Projects and workers do not replace the main assistant.
They extend the same second-brain idea into work that needs more than a conversation:
- longer timelines
- controlled execution
- durable state
- clearer review loops
Auth Patterns
Workers sometimes need access to external services. GlassHive supports two patterns:
- Host projection — the worker inherits local CLI credentials and config from the host machine
- Brokered projection — an external system materializes auth into the sandbox at start time
This keeps authentication explicit and auditable rather than silently sharing credentials.
Keep Reading
- Architecture Overview — Where GlassHive fits in the full system diagram
- Brain-Inspired System — How projects map to the motor cortex analogy
- Scheduling — Use recurring prompts to feed or revive project work
- Browser & Analysis — The kinds of work that turn into artifacts and worker tasks