The full inventory
All themoving parts.
You've watched the company run. This is everything it runs on - six engines, a real org, a work ledger, workflows with human gates, and the triggers that wake them. Every window below shows the real interface doing it.
npm install -g jinn-cliView on GitHub01 / Engines
The models behind your team.
Opus 4.8, GPT-5.6 Sol, Fable 5, Gemini 3 Pro, and more. Jinn discovers them through the model CLIs already on your PATH. Pick engine, model, and effort per employee or per session. Switch mid-conversation; the context comes along.
Opus 4.8GPT-5.6 SolFable 5Gemini 3 ProGrok 4Gemma 3
- subscription
- Opus 4.8 can run through the Claude Code CLI in a real terminal, so work bills to your flat-rate plan - not an API meter.
- discovery
- Models are discovered from each CLI at boot. New model in your CLI, new option in the picker.
- effort
- Effort dials from low to max, resolved per engine, per employee, per session.
- honesty
- Engines whose binary isn't installed are simply hidden. Nothing pretends to be available.
02 / Employees
Employees are files.
Personas, ranks, departments, and reporting lines of any depth - each employee is one YAML file in ~/.jinn/org. Describe a role in chat and the COO drafts it; edit the file and the org rebuilds live.
- ranks
- Executive, manager, senior, employee - rank sets the default reporting line; reportsTo overrides it to any depth.
- delegation
- Any session spawns child sessions that report back on completion - with a contract that nudges stalled work exactly once.
- lateral
- Employees can message each other directly, hop-capped so a conversation loop can't run away.
- map
- The org chart is a live spatial map - pan it, zoom it.
03 / Todos
Done means reviewed.
Every piece of work is a Todo with an owner, a status, and an audit trail. A session can't mark its own work done - a reviewer does. And when a call needs a human, it waits in Needs you until you decide.
- states
- Eight honest states, backlog to done - including blocked and escalated. Nothing hides in "in progress."
- sources
- Work arrives from you, delegation, cron, workflows, sessions, connectors - every item stamped with where it came from.
- review
- A verify policy per item - trust, verify, or thorough - with bounded review rounds that auto-escalate at the ceiling.
- spend
- Cost per item is summed live from its sessions. Never stored, never stale.
- audit
- Every transition, note, and decision appends to an immutable event log.
04 / Workflows
Process you can see.
A workflow is a real graph - steps, branches, gates, waits - drawn on a canvas and run by the gateway. The Executions lens replays every run on the same geometry. When a gate needs a human, the run parks. Nothing polls you; nothing fakes done.
- nodes
- Six node types: trigger, step, gate, switch, fail, wait.
- gates
- Three gate kinds - artifact, flag, approval. An approval gate holds the run until a person decides.
- resilience
- Per-step retries with named causes, timeouts that stop the spend, and error lanes that route failure instead of hiding it.
- sop
- Or skip the canvas: write a plain SOP - steps and a wake-up - and Jinn compiles the graph.
- mid-run
- Edit a pending step's prompt while the run is live; every edit is versioned on the run record.
05 / Triggers
Work starts without you.
Five ways a workflow wakes: a schedule, a todo changing status, a token-authenticated webhook from the outside world, a poll watching for changes - or you. Schedules become managed cron jobs with no model in the trigger path.
- webhooks
- Every webhook binding carries its own secret token - hashed at rest, verified timing-safe.
- filters
- Event triggers filter on payload paths: equals, exists, match.
- polls
- A poll trigger must be approved before it may ever fire.
- cron
- Cron jobs hot-reload from a JSON file, keep run history, and alert you through a connector when they run slow or fail.
06 / MCP
Forty tools. Every hand.
Jinn ships its own MCP server - one tool surface for todos, workflows, sessions, org, knowledge, and cost. Every employee works the company through the same hands, whatever engine they run on. Allow-list servers per employee; bring any external MCP server you already use.
- surface
- 40+ tools: create_work_item, delegate_task, start_workflow_run, decide_work_item_approval, search_knowledge, cost_report…
- allow-lists
- Per employee: all servers, none, or exactly the ones you name.
- external
- Attach outside MCP servers over stdio or URL from one config block.
07 / Connectors
The company, wherever you are.
Slack, Discord, Telegram, WhatsApp. Threads become sessions, a reaction on a decision card is enough to act - and a Telegram voice note is transcribed on your machine before it reaches an employee.
- threads
- A Slack thread maps to a session - the conversation and the work stay in one place.
- reactions
- React to a decision card and the agent acts on it. Approval from your pocket.
- voice
- Voice and video notes transcribed by local Whisper - no cloud transcription service ever hears them.
08 / Dashboard
You've been looking at it.
Every window on this page is the dashboard at localhost:7777 - chat-first, streaming everywhere, with a raw terminal view one toggle away. The org map, the todo board, the workflow canvas, cron, activity logs, live engine-quota meters, a skills catalog. And it all fits your phone.
ChatCLITodosWorkflowsOrganizationCronActivityLimitsSkillsSettings
- terminal
- Chat ↔ CLI: the same session rendered as chat or attached as a live terminal.
- meters
- The Limits page shows each engine's real quota windows - watch your rate limits, not an invoice.
- input
- Slash commands, @employee mentions, attachments, push-to-talk dictation - Whisper and the voice run locally.
- mobile
- A native-feeling phone layout with its own tab bar. Run the company from the sofa.
09 / Skills & knowledge
Institutional memory.
Skills are markdown playbooks every engine follows natively - one folder, one SKILL.md, synced into each CLI automatically. Knowledge is plain files every employee searches through the same two tools. Teach the company once.
---
name: support-triage
description: How we answer tickets - tone, refunds, escalation.
---
1. Read the ticket and the customer's history.
2. Refunds over $25 → request approval first.
…
- sync
- Auto-symlinked into every engine's native skills directory - watched, re-synced the moment a file changes.
- catalog
- Browse and edit every skill in the dashboard.
- community
- Find and add community skills with one command.
- knowledge
- search_knowledge and read_knowledge: deterministic search, no model in the loop, scoped so secrets are unreachable by construction.
10 / Local-first
Yours. Actually yours.
The gateway binds to 127.0.0.1. State is SQLite and plain files under ~/.jinn - all of it readable, editable, committable. No telemetry, no cloud dependency, MIT-licensed. Give an employee a monthly budget and Jinn pauses them at the line.
~/.jinn ├── config.yaml # the gateway, hot-reloaded ├── org/ # employees, one YAML each ├── skills/ # playbooks, one folder each ├── cron/jobs.json # schedules, hot-reloaded ├── knowledge/ # what the company knows └── sessions/ # history, SQLite
- access
- Remote dashboard access requires pairing - short-lived codes, hashed device tokens.
- budgets
- Per-employee monthly budgets - hit the line and Jinn pauses the employee.
- cost
- One cost_report tool sums real spend by employee or by day.
- license
- MIT. The whole company is open source.
All of it.One command.
npm install -g jinn-cli