AI Decision System
Replayable, offline-verifiable records for AI-assisted go/no-go decisions: experiment promotions, typed model answers and human-approved actions.
A living 2D office floor for your AI employee agents.
Developer toolsTypeScript · HTMLGitHub @kushagra486OnlineOwner unconfirmed
Have you tried it? One tap is enough. No sign-in needed.
No updates detected yet. GitHub releases will appear here.
Owners of public repositories under a personal GitHub account can sign in to verify ownership and manage the introduction themselves. No administrator approval is needed.
Sign in, generate a verification file, and commit it to this repository’s default branch within 30 minutes. Files on other branches or forks do not count. Then check the file below to manage the project without administrator approval. Keep the file to retain your access.
If needed, you will go to sign-in. After signing in, return here and press your chosen verification button again.
Run /nomorevibe verify in your project folder to verify ownership and manage the introduction yourself.
Verify in one minuteAsk about other verification options
Loading the full README. The saved excerpt is shown below.
A single project brief becomes a fully staffed AI office. One orchestrator (Nova) and 10 specialist employees — architect, backend, frontend, design, QA, data, security, docs, DevOps, coordination — decompose it into a task graph, work it in parallel with real file/shell tool access, and commit real results, all visualized as a live office floor you can watch in real time.
Submit one brief — "build a landing page," "write API docs," "audit this repo for security issues" — and:Read the full README ↗A single project brief becomes a fully staffed AI office. One orchestrator (Nova) and 10 specialist employees — architect, backend, frontend, design, QA, data, security, docs, DevOps, coordination — decompose it into a task graph, work it in parallel with real file/shell tool access, and commit real results, all visualized as a live office floor you can watch in real time.
Submit one brief — "build a landing page," "write API docs," "audit this repo for security issues" — and:
It's a real, running multi-agent system, not a mockup — the screenshots below are from the live deployment.
| Office floor (live agent state) | Dashboard (usage, mesh graph, work graph) |
|---|---|
| Agent | Role | Department |
|---|---|---|
| Nova | Orchestrator — decomposes briefs, assigns work, triages escalations | Orchestration |
| Kael | Solutions Architect — system design, schemas, API contracts | Engineering |
| Priya | Backend Developer — server implementation, endpoints, business logic | Engineering |
| Devraj | Frontend Developer — UI implementation from design specs | Engineering |
| Simran | UI/UX Designer — design tokens, component states, UX flows | Design |
| Arjun | QA Engineer — test plans, execution, bug reports | Engineering |
| Meera | Data/Analytics — queries, metrics, aggregation | Data |
| Raghav | Security Reviewer — auth review, vulnerability flags | Engineering |
| Tanya | Technical Writer — docs, READMEs, onboarding guides | Data |
| Farhan | DevOps Engineer — CI/CD, deploy pipelines, infra | Operations |
| Isha | Project Coordinator — task breakdown, dependency mapping | Operations |
Each seat is pinned to a specific LLM provider + model (see shared/src/llm/assignments.ts), so 11 agents working concurrently spread across separate rate-limit buckets instead of all hammering one API.
The system is split across three places, each doing the one thing it's actually good at:
flowchart TB
subgraph Client["Browser"]
UI["Office floor · Dashboard · Status board<br/>(Next.js + Three.js)"]
end
subgraph Vercel["Vercel / Netlify — serverless frontend"]
API["Next.js API routes<br/>/api/tasks · /api/agents · /api/brief · /api/escalations"]
Tick["/api/cron/nova-tick<br/>escalation triage + QA pass"]
end
subgraph GHA["GitHub Actions"]
Cron["nova-tick.yml — 5-min schedule<br/>(Vercel's own cron is daily-only)"]
end
subgraph Railway["Railway — persistent worker"]
Dispatch["dispatch loop — polls for ready tasks"]
Runner["AgentRunner — per-agent tool-use loop<br/>read_file · write_file · run_command"]
Git["single-committer git module"]
end
subgraph Supabase["Supabase"]
PG[("Postgres — tasks, messages,<br/>escalations, memory, usage")]
RT["Realtime<br/>(postgres_changes)"]
end
subgraph LLMs["Multi-provider LLM router"]
Groq["Groq"]
NVIDIA["NVIDIA NIM"]
OpenRouter["OpenRouter"]
end
UI <-->|REST| API
UI <-->|live push| RT
API <--> PG
Cron -->|HTTPS, bearer secret| Tick
Tick --> PG
Dispatch --> PG
Dispatch --> Runner
Runner --> Git
Runner --> PG
RT -.->|subscribes to| PG
Runner --> LLMs
Tick --> LLMs
API --> LLMs
Why split this way: the frontend's API routes are stateless request/response — a perfect fit for serverless. Nova's periodic reasoning (escalation triage, QA) is idempotent against Postgres, so a fresh serverless invocation every 5 minutes is safe — that's /api/cron/nova-tick, pinged by a GitHub Actions schedule instead of Vercel's own cron (which is daily-only on the free tier). But an employee's actual work — editing real files and making real git commits against one working tree — can't be a stateless function call; it needs a long-lived process holding a real checkout. That's the one thing that runs on Railway instead.
sequenceDiagram
actor You
participant Nova
participant DB as Supabase (Postgres)
participant Worker as Railway worker
participant Agent as Employee agent
participant LLM as LLM provider
You->>Nova: Submit brief
Nova->>LLM: Decompose into task graph
Nova->>DB: Insert tasks + dependencies
Worker->>DB: Poll for ready tasks
DB-->>Worker: Task ready (deps satisfied)
Worker->>Agent: Start tool-use loop
loop Until done or escalated
Agent->>LLM: Reason + choose next tool call
Agent->>Agent: read_file / write_file / run_command
end
Agent->>Worker: mark_task_done or escalate
Worker->>DB: Commit result, update status
DB-->>You: Realtime push — office floor updates live
Nova->>DB: (every 5 min) triage escalations, run QA pass
| Layer | Choice |
|---|---|
| Frontend | Next.js 14 (App Router), TypeScript, Tailwind, Three.js (3D office floor) |
| Backend API | Next.js API routes (serverless) |
| Persistent worker | Node.js + TypeScript, Docker, deployed on Railway |
| Database + Realtime | Supabase (Postgres + postgres_changes) |
| LLM providers | NVIDIA NIM, Groq, OpenRouter — routed with per-agent fallback chains |
| Hosting | Vercel (primary) + Netlify (mirror) |
| CI | GitHub Actions |
| Desktop wrapper | Electron (optional, npm run electron) |
| Path | What it is |
|---|---|
/shared | Hive types, agent roster, LLM router/providers/assignments, design tokens — imported by both the frontend and the worker so schema and roster never drift apart |
/frontend | Next.js app — office floor UI, dashboard, status board, all API routes, and the nova-tick cron endpoint |
/daemon | The Railway worker — dispatch loop, AgentRunner tool-use loop, single-committer git module |
/electron | Native desktop wrapper — spawns the frontend and worker locally and shows the frontend in a window |
.github/workflows/nova-tick.yml | 5-minute GitHub Actions schedule that pings /api/cron/nova-tick |
cp .env.example .env
# fill in at least one of NVIDIA_API_KEY / GROQ_API_KEY / OPENROUTER_API_KEY,
# a Supabase project's SUPABASE_URL / SUPABASE_SERVICE_ROLE_KEY /
# NEXT_PUBLIC_SUPABASE_URL / NEXT_PUBLIC_SUPABASE_ANON_KEY, and PROJECT_WORKDIR
npm install
npm run build:shared
npm run dev:frontend # Next.js app at localhost:3000
npm run dev:daemon # persistent worker, polls Supabase for ready tasks
Only one provider is required to run at all; configuring more just adds rate-limit headroom, since every agent's assignment has fallbacks on the other providers (shared/src/llm/assignments.ts).
npm run build # shared + frontend + daemon production builds
npm run electron # spawns the frontend + worker, opens a native window
frontend, vercel.json handles the monorepo build) or Netlify; set the Supabase + LLM provider env vars from .env.example.Dockerfile to Railway (or any Docker host); it only needs outbound HTTPS to Supabase and the LLM providers, plus a writable volume for PROJECT_WORKDIR if you want commit history to survive restarts.APP_URL (your deployed frontend URL) and CRON_SECRET (matching the one set on the frontend) as GitHub Actions repo secrets so .github/workflows/nova-tick.yml can ping /api/cron/nova-tick every 5 minutes.No license file yet — all rights reserved by default until one is added.