Skip to main content

​
Use Cases

connector.json + PTY-for-AI adapts to how you actually work.

​
Solo Developer: Multi-Model Workflow

One person. One machine. Multiple AI models for different tasks. 
Your laptop:
  ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
  │ Claude Opus │ │ Codex       │ │ Haiku       │
  │ "architect" │ │ "reviewer"  │ │ "docs"      │
  └─────────────┘ └─────────────┘ └─────────────┘

{
  "name": "solo-workflow",
  "pipeline": {
    "phases": [
      { "name": "implement", "model": "opus",  "prompt": "Build the feature." },
      { "name": "review",    "model": "codex", "prompt": "Independent code review." },
      { "name": "document",  "model": "haiku", "prompt": "Write docs for what changed." }
    ]
  }
}
Why: Opus for hard thinking ($$$). Codex for a second opinion ($$). Haiku for grunt work ($). One person gets the output of a three-person team.

​
Pair Programming: Two AI, One Codebase

You and two AI agents working the same feature in real-time. 
Your terminal (main session):
  You type. You decide. You merge.

PTY Session 1 — Claude (implements what you describe):
  "Add OAuth to the login flow"

PTY Session 2 — Codex (watches your git diff, reviews continuously):
  "Reviewing latest changes..."

{
  "name": "pair-programming",
  "type": "mesh",
  "agents": [
    { "id": "builder",  "model": "claude", "prompt": "Implement what the user describes." },
    { "id": "reviewer", "model": "codex",  "prompt": "Watch git diff continuously. Flag issues immediately." }
  ],
  "communication": { "topology": "mesh", "broadcast_channel": true }
}
Why: Builder doesn’t review its own code. Reviewer catches mistakes in real-time, not after the PR.

​
Small Team: Shared AI Infrastructure

3-5 developers. Each has a laptop. One shared server. 
Dev A (laptop):   Claude — frontend work
Dev B (laptop):   Claude — backend work
Dev C (laptop):   Gemini — testing
Shared server:    Codex — continuous review + CI integration

{
  "name": "team-infra",
  "machines": {
    "dev-a": "ALICE-MBP.local",
    "dev-b": "BOB-MBP.local",
    "dev-c": "CHARLIE-MBP.local",
    "server": "TEAM-SERVER.local"
  },
  "agents": [
    { "machine": "server", "model": "codex", "prompt": "Watch main branch. Review every push. Report to all." }
  ],
  "communication": { "broadcast_channel": true }
}
Why: The server runs 24/7 Codex that reviews every push. Developers get feedback without waiting for human reviewers. The AI reviewer never sleeps, never forgets to check.

​
Open Source: CI/CD AI Agent

Automated PR review and triage for open source projects. 
GitHub Actions runner:
  niia daemon (always running)
  ↓ new PR arrives
  ↓ connector.json triggers

  Phase 1: Haiku × 3 (cheap, fast)
    "Classify this PR: bug fix, feature, docs, refactor?"
    "Check for breaking changes"
    "Run test suite"

  Phase 2: Sonnet × 1 (if tests pass)
    "Full code review. Comment on PR."

  Phase 3: Opus × 1 (if critical path)
    "Security review of auth-related changes."

{
  "name": "oss-pr-review",
  "trigger": "github.pr.opened",
  "pipeline": {
    "phases": [
      {
        "name": "triage", "parallel": true, "model": "haiku",
        "workers": [
          { "prompt": "Classify PR type." },
          { "prompt": "Check breaking changes." },
          { "prompt": "Run tests." }
        ]
      },
      { "name": "review", "model": "sonnet", "prompt": "Full code review." },
      {
        "name": "security", "model": "opus",
        "condition": "triage.classification == 'auth'",
        "prompt": "Security review."
      }
    ]
  }
}
Why: Haiku triage costs pennies. Most PRs stop at phase 1. Only auth-related PRs get expensive Opus review. Cost-proportional to risk.

​
Remote Work: Follow-the-Sun

Team across time zones. AI keeps working when humans sleep. 
Morning (Seoul, 9 AM):
  Developer starts connector.json
  → Research phase begins (5 Haiku workers)

Afternoon (Seoul, 3 PM):
  Developer reviews research
  → Starts implementation phase (Opus)
  → Goes home

Evening (Seoul → San Francisco wakes up):
  US developer: niia remote read SEOUL-SERVER
  → Implementation 80% done
  → Sends follow-up: niia remote write SEOUL-SERVER "also handle edge case X"

Night (both offline):
  Daemon keeps running on Seoul server
  → Opus finishes implementation
  → Sonnet starts verification
  → Results in scratchpad by morning

Next morning (Seoul, 9 AM):
  Developer reads scratchpad
  → Implementation done, tests passing, PR ready

{
  "name": "follow-the-sun",
  "machines": {
    "seoul": "SEOUL-SERVER.local",
    "sf": "SF-SERVER.local"
  },
  "pipeline": {
    "phases": [
      { "name": "research",   "machine": "seoul", "model": "haiku",  "workers": 5 },
      { "name": "implement",  "machine": "seoul", "model": "opus",   "workers": 1 },
      { "name": "verify",     "machine": "sf",    "model": "sonnet", "workers": 2 },
      { "name": "pr",         "machine": "seoul", "model": "sonnet", "workers": 1 }
    ]
  }
}
Why: The pipeline spans time zones. When Seoul sleeps, SF verifies. When SF sleeps, Seoul reviews. AI doesn’t sleep at all.

​
Data-Sensitive: Air-Gapped Analysis

Data that cannot leave the building. AI comes to the data. 
Hospital network (no internet):
  niia daemon + ollama/llama3 (fully local)
  → Analyzes patient records
  → Produces: "Ward 3 infection rate anomaly detected"
  → Result only, no patient data

Research office (internet):
  niia daemon + Claude Opus
  → Reads anonymized results from all hospitals
  → Cross-hospital pattern analysis
  → Publishes research paper draft

{
  "name": "air-gapped-analysis",
  "agents": [
    {
      "machine": "hospital-A", "model": "ollama/llama3",
      "prompt": "Analyze infection rates. Output summary statistics ONLY. NO patient identifiers."
    },
    {
      "machine": "hospital-B", "model": "ollama/llama3",
      "prompt": "Same analysis."
    },
    {
      "machine": "research-lab", "model": "claude",
      "prompt": "Read all hospital summaries. Cross-reference patterns. Draft findings."
    }
  ]
}
Why: Patient data never moves. AI runs where the data lives. Only aggregated, anonymized results travel. HIPAA/GDPR compliant by architecture, not by policy.

​
GPU Farm: Hardware-Optimized Deployment

Different hardware for different models. 
Laptop (M4, 32GB):
  Claude Haiku — fast search, classification
  Gemini — broad analysis

GPU Server A (A100 × 4):
  ollama/llama-70b — heavy local inference
  Fine-tuned model — domain-specific tasks

GPU Server B (H100 × 8):
  ollama/llama-405b — largest open model
  Codex — parallel code generation

{
  "name": "gpu-optimized",
  "machines": {
    "laptop": "MY-LAPTOP.local",
    "gpu-a": "GPU-SERVER-A.local",
    "gpu-b": "GPU-SERVER-B.local"
  },
  "pipeline": {
    "phases": [
      {
        "name": "classify",
        "machine": "laptop", "model": "haiku", "workers": 3,
        "prompt": "Classify each module by complexity."
      },
      {
        "name": "simple-modules",
        "machine": "gpu-a", "model": "ollama/llama-70b", "workers": 4,
        "prompt": "Implement simple modules. No API cost."
      },
      {
        "name": "complex-modules",
        "machine": "gpu-b", "model": "ollama/llama-405b", "workers": 2,
        "prompt": "Implement complex modules. Full reasoning power."
      },
      {
        "name": "integrate",
        "machine": "laptop", "model": "claude",
        "prompt": "Integrate all modules. Run tests."
      }
    ]
  }
}
Why: Laptop for coordination (free). GPU servers for heavy lifting (local, no API cost). Claude only for final integration (minimal API spend). Total API cost: ~2insteadof 2 instead of ~50.

​
Startup: Rapid Prototyping

Move fast. Try everything. Keep what works. 
{
  "name": "rapid-prototype",
  "pipeline": {
    "phases": [
      {
        "name": "explore",
        "parallel": true,
        "workers": [
          { "model": "claude", "prompt": "Prototype approach A: microservices + Redis.",
            "session": { "worktree": "approach-a" } },
          { "model": "codex",  "prompt": "Prototype approach B: monolith + PostgreSQL.",
            "session": { "worktree": "approach-b" } },
          { "model": "gemini", "prompt": "Prototype approach C: serverless + DynamoDB.",
            "session": { "worktree": "approach-c" } }
        ]
      },
      {
        "name": "evaluate",
        "type": "meeting",
        "participants": [
          { "model": "opus",   "role": "Evaluate all 3 prototypes. Which ships fastest?" },
          { "model": "codex",  "role": "Which approach has fewest bugs?" },
          { "model": "gemini", "role": "Which approach scales best?" }
        ],
        "agenda": [{ "topic": "Pick one approach", "rounds": 2 }]
      },
      {
        "name": "build",
        "model": "opus",
        "prompt": "Read the meeting decision. Build the chosen approach to production quality."
      }
    ],
    "scratchpad": true
  }
}
Why: Three different AI agents prototype three different architectures in parallel. Then three different AI agents debate which one to ship. Then one builds it. One hour instead of one sprint.

​
Enterprise: Governed AI Deployment

Full control. Full audit. Full compliance. 
connector.json defines what AI CAN do.
Enterprise policy defines what AI CANNOT do.
The daemon enforces both.

{
  "name": "enterprise-task",
  "session": {
    "sandbox": true,
    "worktree": "ticket-1234"
  },
  "models": {
    "primary": "claude",
    "local-only": "ollama/llama3"
  },
  "pipeline": {
    "phases": [
      {
        "name": "analyze",
        "model": "local-only",
        "prompt": "Analyze customer data. Output anonymized summary.",
        "session": { "sandbox": true, "network": false }
      },
      {
        "name": "implement",
        "model": "primary",
        "prompt": "Read anonymized summary. Implement fix.",
        "session": { "sandbox": true }
      }
    ]
  }
}
Why: Phase 1 uses local LLM with no network — customer data can’t leak. Phase 2 uses Claude but only sees anonymized summary. Sandbox ensures no file writes outside worktree. Every keystroke logged for audit. The AI is powerful AND governed.

​
The Pattern

Every use case is the same infrastructure: 
niia daemon (on each machine)
  + headless PTY sessions
  + connector.json (declarative)
  + plugins (worktree, sandbox, policy)
  + remote (cross-machine)

Solo dev?        1 machine, 3 models, 1 connector.json
Small team?      N machines, shared server, broadcast channel
Enterprise?      Governed, audited, sandboxed, compliant
Air-gapped?      Local LLM, data never moves
Global?          Machines in 3 countries, one pipeline

Same daemon. Same spec. Different scale.