Nigents

Your AI development team for GitLab

Seven specialized agents plan, implement, test, and review on a dedicated task branch, then open a merge request to your default branch. Control everything from Telegram or the dashboard — self-hosted on your infrastructure.

Open dashboard Workflow Studio Technical flow Crazy apps

Product

What you get

Core capabilities — no separate marketing site required.

24/7 operation

Agents run on your server (e.g. PM2 on EC2). Queue tasks overnight and pick up merge requests when you are back.

Telegram control

Text and voice commands, per-user configuration, and status messages when work completes.

GitLab-native

Branches, commits, and MRs on the repository you select. Task branch → default branch merge requests.

Configurable models

Attach the LLM providers and models you trust. Dashboard and bot respect per-user keys when MySQL is enabled.

MCP tools

Filesystem, GitLab, search, and custom MCP servers extend what agents can do during planning and execution.

Live dashboard

Tasks, agents, charts, Workflow Studio, admin tools, and Socket.IO updates in the browser.

The team

Seven roles

Each role is a separate agent in the pipeline. Model names are examples — yours depend on configuration.

Orchestrator

Routes commands, binds task.branch, creates the MR, coordinates the chain.

Model: configurable

Planner

Reads repo structure via MCP or GitLab API; outputs steps and plan.branch.

Model: configurable

Backend Dev

OpenHands sandbox or generated code plus repo-clone-push to plan.branch.

Model: configurable

Frontend Dev

Frontend-only plans; clone, write UI files, push — no OpenHands path.

Model: configurable

QA Tester

Runs tests in the sandbox when available; otherwise simulated or skipped.

Model: configurable

Code Reviewer

Diff default vs task branch; quality and security checks.

Model: configurable

Reporter

User-facing progress lines and the final MR link in Telegram.

Model: configurable

Dashboard

Workflow Studio — agents you wire yourself

Design a graph, not a single line: branch Planner and Frontend in parallel, merge into Backend, add QA and Reviewer, then ship to GitLab. Drag nodes, draw edges between ports, save per project. AI draft can propose a layout from your repo tree; the same roles power meetings and production runs. Click an agent on the diagram (or its LED) to see a mock streamed code/shell panel on the graph — no jump down the page.

Click any agent box on the graph (or its LED) to open a live-style stream panel in place — code and shell lines type in like a socket feed; the page does not jump. The LEDs show who is active; the row below mirrors the same mock data. In Workflow Studio, one node can feed many others: fork after Orchestrator, join at Backend, add QA and Reviewer on their own edges. Link a GitLab project so each graph stays with the repo. Optional: AI draft, team meeting, voice room.

Branches & merges — Parallel paths (e.g. Planner vs Frontend) reconnect where you draw the edge; data follows those edges at runtime.
Persisted per repo — With MySQL, workflows are stored in workflow_projects (legacy workflow-projects.json is migrated on upgrade). On first dashboard start, a default graph is created for each GitLab project visible to your token.
Live run — While a task runs (Telegram or dashboard), a pulsing LED marks the active agent on the canvas; click that card for the full stream. An optional combined log is available in the Live run panel.
Same seven agents — Canvas roles match production; reorder by reconnecting, not just a single line.

Live & data plane

What you see when agents work

The dashboard receives the same real-time events as the Live Monitor: codeEdit (optional project / taskId / kind: shell), agentCommunication (handoffs between agents), and agentStatus (which node is “thinking”). Wire edges on the canvas to express who passes output to whom; the orchestration layer uses that topology alongside the task plan.

Same data as the graph above: the Workflow Studio uses activity LEDs on cards — click a card to read that agent’s stream. Below, each role has a small LED (not a wall of text); click the card to load sample streamed code and shell (codeEdit / agentStatus).

Selected: backend-dev — full streams for this role (same data as dashboard Socket.IO).

Streamed code codeEdit

[backend-dev] write src/api/users.ts
  export async function list() { ... }
— chunk mirrored to dashboard as agents type

Streamed shell kind: shell

[qa-tester] $ npm test -- --runInBand
 PASS  src/auth.spec.ts
Tests: 4 passed

Link the workflow to group/repo and enable Focus linked repo to filter noise. Agents can include project on API posts so streams line up with the GitLab project you care about — the same task you started from Telegram or the task queue.

Ready to ship overnight?

Launch dashboard

Live map

What talks to what

Orange dots move along the paths on a loop. Solid lines: HTTP / APIs. Dashed: WebRTC to Jitsi (browser only). Two Node processes do not share memory.

Top path: Telegram → bot → LLM / GitLab / MySQL; Backend Dev may use OpenHands for real git in a container.
Bottom path: Browser → dashboard server → same GitLab & MySQL; meeting page uses Socket.IO on this server and Jitsi for human audio (dashed).

Product walkthrough

From Telegram to GitLab MR — the full loop

Nigents runs two processes: Telegram bot (src/bot.js) and the dashboard (src/dashboard/server.js). Everything below mirrors the README: plan branch, implementers, OpenHands, Workflow Studio, and the voice meeting room.

Open dashboard README on GitLab Back to About

reporter.log — mock session

At a glance

What ships with the product

Illustrative numbers — your deployment may vary by configuration.

Agent roles

Orchestrator → Planner → Devs → QA → Reviewer → Reporter

MCP tools

Standard + custom servers (filesystem, GitLab, etc.)

Git integration

GitLab only — MR from task branch to default

Processes (typical)

Bot + dashboard (e.g. PM2 on EC2)

Runtime map

Same topology (detailed)

No shared memory between bot and dashboard. Both use MySQL (when configured), GitLab API, and LLM providers. Meeting room uses Socket.IO on the dashboard server only.

Client

Long-poll API

Process

bot.js

/plan /approve voice

External

GitLab

Repos & MRs

External

LLM APIs

OpenAI, Anthropic…

Data

MySQL

Tasks & user_config

Client

Browser

Dashboard + meeting

Process

server.js

Express + Socket.IO

Optional

OpenHands

Docker sandbox :3000

Voice

Jitsi

WebRTC (humans)

Meeting room: meeting-room.html?token= — same token = same AI thread via join-meeting / meeting-sync. HTTPS + WebSocket proxy required in production (see repo docs/EC2_NETWORK_MEETING.md).

Entry points

URLs & surfaces

Surface	Path / address	Purpose
Telegram bot	`api.telegram.org` (outbound)	`/plan`, `/approve`, `/meeting`, voice, per-user config
Dashboard	`PUBLIC_DASHBOARD_URL` :4000	Login, tasks, agents, Workflow Studio, admin
This page	`/how-it-works.html`	Public product flow (no login)
Workflow Studio	Dashboard → sidebar	Canvas, AI draft, roundtable, shareable voice link
Voice meeting	`/meeting-room.html?token=…`	Jitsi + shared AI roundtable (Socket.IO)
OpenHands	`OPENHANDS_URL`	Clone, edit, test, push in container

End-to-end

Task flow: plan → MR

All work stays on the selected GitLab repo and plan.branch (task branch). Mock values below show what a real run looks like.

1 — Plan

User sends /plan with a task (text or voice). Bot may ask for project. Planner returns steps, file paths, plan.branch, and primaryStack (frontend / backend / fullstack).

plan.branch = nigents/task-202503171430
project = acme / web-app
primaryStack = backend

2 — Approve

User sends /approve. Orchestrator sets task.branch = plan.branch and queues Backend Dev or Frontend Dev based on stack.

3 — Implement

Backend + OpenHands: clone in sandbox, checkout -b plan.branch, edit plan files, commit, push.
Without OpenHands / Frontend: generate code → repo-clone-push to same repo & branch; fallback GitLab Commits API if needed.

Reporter: Pushing branch nigents/task-202503171430 to GitLab…
→ ok (HTTP 201)

4 — QA & review

QA runs tests (OpenHands workspace or simulated). Code Reviewer loads diff: default ↔ task branch via GitLab compare API.

5 — Merge request

Orchestrator creates MR: source = task branch, target = repo default (main). User receives the MR link in Telegram. Pipeline status refers to your app repo, not Nigents.

MR !142
https://gitlab.com/acme/web-app/-/merge_requests/142

Dashboard (logged in)

With MySQL enabled, tasks and agents load from the database — no stale in-memory lists. Socket.IO pushes live updates to the browser.

Example

Telegram conversation (mock)

You

/plan Add password reset email flow

Planner

Branch nigents/task-202503171430 · 3 steps · files: src/auth/reset.ts … Reply with /approve

You

/approve

Reporter

MR ready: acme/web-app !142 (source → main)

Data plane

How each agent sees the repo

Agent	Sees	Source
Planner	File list, relevant paths, up to 5 file excerpts	MCP `list_directory` / `read_file` or GitLab API
Backend (OpenHands)	Full clone under workspace	`executeCommands` + `implementWithPrompt`
Backend (no OH)	Plan steps only → generated files	repo-clone-push temp clone
Frontend Dev	Plan steps → generated UI files	repo-clone-push
QA	Same workspace as OpenHands when present	`npm test` etc. in workDir
Code Reviewer	Git diff default ↔ task branch	`getCompareDiff`

Sandbox

OpenHands vs fallback

With OpenHands

HTTP service (often port 3000). Backend Dev runs real git, installs deps, edits files in /workspace/<project>, then pushes plan.branch.

GET /health — availability
POST /api/execute — shell commands
POST /api/agent/run — prompt + working_dir

Without OpenHands

AI-generated file contents are written into a fresh clone of the same GitLab repo, same branch name, then pushed. If clone fails, GitLab Commits API can still create branch content for review.

Dashboard

Workflow Studio & voice meeting

Workflow Studio

Projects persist to MySQL workflow_projects when configured (else data/workflow-projects.json). Drag agents, wire ports, link group/repo, run AI draft from tree + README; Live run streams code/shell/events over Socket.IO.

GET /api/gitlab/repos
POST /api/workflow-projects/draft-from-repo
POST /api/meeting/roundtable — same engine as Telegram roundtable

Voice room

POST /api/meeting/sessions (auth) issues a token. Browser opens Jitsi (people) + Socket.IO roundtable (AI). Events: join-meeting, meeting-roundtable, meeting-sync, meeting-clear.

Stack

npm dependencies (summary)

Area	Packages
Web	`express`, `socket.io`, `cookie-parser`
AI	`openai`, `@anthropic-ai/sdk`, `axios`
DB	`mysql2`
Telegram	`node-telegram-bot-api`
Git / Docker	`simple-git`, `dockerode`
MCP	`@modelcontextprotocol/sdk`
Utilities	`uuid`, `dotenv`, `winston`, `node-cron`, `nodemailer`, `fs-extra`, `lodash`, `date-fns`, `form-data`, `gtts`