SENTINEL AGENT — ein agentischer Ops-App-Builder

Die KI-Befehlsebene für eine Foundry-artige Ops-Ontologie: ein LLM-Agent, der über MCP verbindet, natürlichsprachliche Fragen mit echten abgefragten Daten beantwortet, menschlich genehmigte Aktionen vorschlägt und bei Bedarf operative Dashboards erstellt – ein selbstgebautes, Palantir-AIP-artiges operatives Werkzeug.

Abstammung: Dieses Projekt entwickelt den KI-Site-Generator-Agenten, den ich für Locari (mein Lead-Gen-SaaS – live in Produktion; privates Repo) gebaut habe, von „LLM generiert eine Website“ zu „LLM operiert über eine Unternehmensontologie mit Governance“ weiter: dieselbe Agenten-Loop-DNA, aber jede Fähigkeit ist jetzt typisiert, auf die Whitelist gesetzt, vorschauend, menschlich genehmigt und geprüft. Es paart sich mit PACIFIC SENTINEL (Projekt 1), dessen FastAPI-Ontologie dieser Agent direkt konsumieren kann.

Die 3-Prompt-Demo

Alles ausführen (offline, kein API-Schlüssel nötig):

.venv/bin/python scripts/demo.py

Oder geben Sie diese in die Web-App ein:

Related MCP server: Vela MCP Server

Was ist MCP und wie dies Palantir AIP widerspiegelt

MCP (Model Context Protocol) ist ein offenes Protokoll, das einem LLM eine typisierte, auffindbare, begrenzte Tool-Oberfläche über externe Systeme bietet. Ein Server stellt Tools bereit (Name + Beschreibung + JSON Schema); jeder Client – ein Agent, eine IDE, eine Chat-App – verbindet sich, listet sie auf und ruft sie auf. Die Protokollgrenze ist die Governance-Grenze: Das Modell kann nur das tun, was der Server bereitstellt.

Dieses Projekt ist ein Miniaturmodell der Palantir-AIP-Architektur:

Wie Human-in-the-Loop funktioniert

 user ──ask──▶ Agent (LLM)                 MCP server                FastAPI (operator)
                │  propose_action(...) ──▶ validate params
                │                          run constraint checks
                │                          build before/after PREVIEW   (no mutation)
                │ ◀── proposal + action_id ─┘
 UI shows preview card ──── human clicks Approve ──▶ approve_action(operator_key)
                                                     └─ mints SINGLE-USE token
                                                   execute_action(token)
                                                     ├─ re-validates vs CURRENT state
                                                     ├─ applies the change
                                                     └─ audit log: proposed→approved→executed

Drei Durchsetzungsebenen halten den Agenten auf Vorschlagsbasis:

1. Whitelist — approve_action / reject_action / execute_action werden aus der Tool-Liste des LLM entfernt; die Agenten-Loop lehnt jeden Aufruf eines Tools ab, das ihm nicht gegeben wurde.

2. Fähigkeitssteuerung — die Genehmigung erfordert einen OPERATOR_KEY, der nur im Prozess des Orchestrierungsservers existiert (in die MCP-Subprozess-Umgebung injiziert). Kein LLM-Kontext enthält ihn jemals, sodass ein Agent prinzipiell keine Genehmigungs-Tokens erstellen kann.

3. Token-Mechanik — Tokens sind Einmal-Tokens (secrets.compare_digest, bei erster Verwendung verbrannt) und die Ausführung validiert jede Einschränkung gegen den aktuellen Zustand erneut, sodass eine veraltete Genehmigung kein Depot überziehen kann.

Die gleiche Philosophie gilt für Dashboards: Der Agent gibt eine streng validierte JSON-Spezifikation aus (extra="forbid", 3 Widget-Typen, begrenzte Größen), die feste React-Komponenten interpretieren – niemals HTML, JSX oder ausführbaren Code.

Architektur

 React 18 + Vite + TS + Tailwind          FastAPI (port 8100)              MCP server (stdio subprocess)
 ┌──────────────┬───────────────┐   WS    ┌──────────────────────┐  MCP    ┌─────────────────────────┐
 │ Chat panel   │ Actions cards │ ◀─────▶ │ /ws  agent events    │ ◀─────▶ │ 9 tools over ontology   │
 │ (markdown)   │ Live trace    │  HTTP   │ /actions/{id}/approve│  stdio  │ ┌─ StubOntology (dflt)  │
 │              │ Dashboard     │ ◀─────▶ │ /actions/{id}/reject │         │ └─ HttpOntology ──▶ Project 1
 │              │ canvas        │         │ /audit  /health      │         │    (pacific-sentinel)
 └──────────────┴───────────────┘         │ OpsAgent loop + LLM  │         └─────────────────────────┘
                                          │ (Claude ⟷ MockLLM)  │
                                          └──────────────────────┘

Ausführen

# Backend
python3.11 -m venv .venv && .venv/bin/pip install -e ".[dev]"
.venv/bin/python -m pytest                  # 60 tests, fully offline
.venv/bin/python scripts/demo.py            # scripted 3-prompt demo (mock LLM)
.venv/bin/python scripts/smoke_mcp.py       # raw MCP stdio smoke run

# CLI
.venv/bin/python -m ops_agent.cli --llm mock "Which units are critically low on water?"

# Web app: API on :8100, frontend on :5174
LLM_MODE=mock .venv/bin/python -m uvicorn ops_agent.server:app --port 8100
cd frontend && npm install && npm run dev   # open http://localhost:5174
npm test                                    # 8 Vitest component tests

# Real LLM (claude-opus-4-8; key read from env, never hardcoded)
export ANTHROPIC_API_KEY=sk-ant-...
.venv/bin/python -m ops_agent.cli "Which units are critically low on water?"

# Against Project 1's live ontology instead of the stub
ONTOLOGY_BACKEND=http ONTOLOGY_API_URL=http://localhost:8000 ...

LLM-Modi — LLM_MODE=auto (Standard: live, wenn ANTHROPIC_API_KEY gesetzt ist, sonst Mock) / mock / live. Der MockLLM verhält sich wie ein Tool-aufrufendes Modell (Verankerungsabfrage → gefilterte Abfrage → Antwort; Aktionsparsing; Dashboard-Erstellung), sodass jeder Ablauf – einschließlich Tests und der Demo – offline und deterministisch läuft.

Meilensteine

• M1 MCP-Server: schreibgeschützte Ontologie-Tools über ein austauschbares Backend + Tests

• M2 Agenten-Loop: LLM-Tool-Aufruf über MCP, Whitelist, Audit-Ereignisse, CLI

• M3 FastAPI WebSocket-Streaming + React-Chat/Trace-UI

• M4 Vorschlagen → menschliche Genehmigung (Operator-Key + Einmal-Token) → Ausführen → Audit

• M5 Dashboard-Spezifikationsgenerierung (sicheres JSON) + React-Renderer (recharts)

• M6 Demo-Skript, Screenshots, diese README