Agentic Ventures Workplace — Standard-Stack-Vision

Status

Brainstorm 2026-05-18. Phase 1 ist als eigenes Projekt im Bau (_index). Phasen 2-4 leben hier als Vision bis der Pilot Adoption beweist.

Kern-Idee

KMU-Standard-Stack als modulares Paket auf Hetzner pro Kunde, mit zentralem Cockpit als Steuerungs-Layer. Open-Source-Tools verbunden mit Sonnet/Haiku ueber MCP-Schicht, statt einem ERP-Brocken. Self-Host wo DSGVO + Architektur-Souveraenitaet wichtig, SaaS wo Kompatibilitaet vorgeht (Buchhaltung, Mail).

Marvin’s Pitch wird konkret: „Wir verbinden bestehende Tools intelligent — und geben Andre + Christoph endlich einen Blick auf wo das Unternehmen steht.”

Zwei-Saeulen-Sicht

Der Stack hat zwei Kern-Saeulen, nicht eine:

Saeule A — Operative Tools (wo Mitarbeiter taeglich arbeiten)

Twenty (CRM, Open Source, modern UI)
Plane (PM, Linear-Klon, Open Source)
Nextcloud (Dateispeicher + Doku-Preview)
Baserow (Daten-Tabellen, Airtable-Style, statt Excel-Ersatz)
Cal.com (Booking)
OWUI (Chat als Cross-Tool-Hub)
Optional: Jitsi (Video), InvenTree (Pro-Tier Lager)

Saeule B — Steuerungs-Cockpit (wo Geschaeftsfuehrer Lage sieht)

Cockpit (Multi-Tenant-Variante von av-cockpit, Next.js + Tailwind + Recharts)
Datenquellen: Saeule-A-Tools via MCP + externe SaaS (lexoffice, mailbox.org, TicketPay/Zettle je nach Branche) + Bank ueber Buchhaltungs-Tool
Cron-Snapshot-Pipeline: aggregierte Daten in zentraler Postgres-Tabelle
Sichten: Liquiditaet, Pipeline, Heute-Tun, Agent-Activity-Log

Saeule B ist die wichtigere fuer Geschaeftsfuehrer-Adoption. VF-Phase-1 baut zuerst Saeule B (sichtbarer Wert in 2 Wochen). Saeule A kommt erst wenn Saeule B Vertrauen aufgebaut hat.

Vier-Schichten-Architektur

Auth-Layer (SSO): Cloudflare-Access als Vor-Gate + Authentik (Open-Source-OIDC-Provider) auf der VM. Alle Tools sprechen OIDC mit Authentik. EIN Login fuer User, alle Tools offen.
Direkte APIs: Twenty (REST + GraphQL), Plane (REST), Baserow (REST), Cal.com (REST), Nextcloud (WebDAV + OCS), OWUI (REST), lexoffice (REST), Papierkram (REST), TicketPay (REST), Zettle (REST).
Workflow-Layer (Cron, nicht n8n): Code-Workflows im Repo unter workflows/*.ts, Cron-Runner-Container auf der Tenant-VM. Nutzt Marvin’s agents-platform-Pattern. n8n bewusst weggelassen — eine Sorge weniger pro Tenant.
Chat-Layer (OWUI + MCP-Mono): Universal-Interface fuer Cross-Tool-Queries und ad-hoc Workflows.

Stack-Komponenten pro Profile

core (immer aktiv):
  ├── postgres, redis, traefik, authentik
  ├── backup-sidecar (nightly S3-Sync)
  ├── cron-runner (Code-Workflows fuer Tool-Sync)
  └── cockpit (Multi-Tenant-Modus)

Feature-Profiles (pro tenant.yaml waehlbar):
  ├── crm        → twenty
  ├── pm         → plane
  ├── files      → nextcloud + collabora-im-Hintergrund
  ├── data       → baserow
  ├── booking    → cal.com
  ├── chat       → owui + litellm + mcp-mono
  ├── pos        → zettle-mcp (Zettle selbst extern bei PayPal)
  ├── inventory  → inventree (Pro-Tier, optional)
  └── video      → jitsi (optional)

SaaS extern (per MCP angebunden, kein Container):
  ├── lexoffice  oder Papierkram (Buchhaltung — Pflicht-SaaS wegen GoBD)
  └── mailbox.org (Mail)

Repo-Struktur (skizziert)

agentic-ventures-workplace/
├── docs/architecture.md, feature-matrix.md, integration-map.md
├── infra/
│   ├── pulumi/             (Hetzner VM, Cloudflare Tunnel, DNS, S3-Backup)
│   └── docker/
│       ├── compose.base.yml
│       └── compose.<profile>.yml pro Feature
├── workflows/              (Cron-Code: twenty-won-to-plane.ts, calcom-to-twenty.ts, ...)
├── prompts/                (OWUI-System-Prompt-Template)
├── scripts/                (onboard-tenant.sh, enable-feature.sh, update-tenant.sh)
└── tenants/
    └── kunde-xy.yaml

Plus separates Repo agentic-ventures-cockpit (= refactored av-cockpit, Multi-Tenant-Mode + Marvin-Mode).

Phasen-Plan

Phase 1 — VF-Liquiditaets-Cockpit (laeuft). Saeule B als Single-Tenant-Erweiterung im av-cockpit. Datenquellen: Papierkram + TicketPay. Ziel: 2-3 Wochen live, Adoption-Beweis. Siehe _index.

Phase 2 — VF-Pipeline (wenn Phase 1 adoptiert). Twenty als Stammdaten + Cockpit-Erweiterung um Pipeline-Sicht. „Du hast 3 Kunden mit ueberfaelligen Followups”. Erst jetzt CRM.

Phase 3 — VF-Operationen. Plane fuer Projekt-Tracking, Nextcloud + Baserow + Cal.com als Stack-Komponenten. Komplette Saeule A live.

Phase 4 — Multi-Tenant-Refactor. Wenn zweiter Kunde wirklich kommt: av-cockpit auf Tenant-Mode + Pulumi-Provisionierung + Standard-Stack-Repo. Vorher nicht.

Onboarding-Pattern (Phase 4)

Pro Kunde eine tenant.yaml:

tenant: kunde-xy
domain: kunde-xy.agenticventures.de
features:
  crm: true
  pm: true
  files: true
  data: true
  booking: true
  chat: true
  pos: false
  inventory: false
  video: false
admins:
  - andre@kunde-xy.de
  - christoph@kunde-xy.de
branding:
  primary: "#2D4A3E"
  logo: "https://..."

Wrapper-Script onboard-tenant.sh kunde-xy.yaml macht:

Pulumi up → Hetzner VM, Cloudflare-Tunnel, DNS-Records, Object-Storage-Bucket
SSH zu VM → docker-compose mit richtigen Profilen, Authentik konfigurieren, OIDC-Apps registrieren
Cron-Runner-Container mit den Workflow-Code-Files starten
Branding aus tenant.yaml in alle Tools injizieren
Cockpit-Build mit TENANT_ID=kunde-xy npm run build, statischer Export auf S3-pro-Tenant
Smoke-Test

Zielzeit pro Onboarding: 30-60 Min nach Phase-4-Build.

MS365-Tier-Frage

Zwei Sub-Tiers im Standard-Stack je nach Kunden-IT-Stand:

„MS365 behalten” — Kunde nutzt schon MS365, m365-MCP drueber, Marvin reduziert Lizenz-Plan auf nur-Excel-Outlook-Sharepoint (~6 EUR/User/Mo statt 12-15). Kein Nextcloud, kein eigener Mailserver.
„MS365 raus / nicht da” — Kunde hat nichts oder will weg. Nextcloud + mailbox.org + Baserow als Stack-Komponenten. Falls Excel-Power-User existiert: 1 einzelne MS365-E1-Lizenz fuer den.

Realistisch: Marvin kommuniziert ehrlich „Wir bauen euch eine Suite die 95% von MS365 ersetzt — die 5% Excel-Power-User behalten ihre eine Lizenz.”

Vertikal-Saeulen pro Branche

Branchen-spezifische Komponenten fliegen rein wenn der Kunde es braucht:

Event-Veranstalter (z.B. VF): TicketPay-MCP, Event-Forecast im Cockpit
Retail/Gastro: Zettle-MCP (POS), Baserow als Stock-Cockpit (Light-Tier), InvenTree (Pro-Tier)
Berater/Agentur: Papierkram als Buchhaltung (mit Zeit-Tracking)
Telefon-getrieben: receptionist-Pattern (WhatsApp-/Telefon-Hub)

Agent-Activity-Log (querschnittlich)

Alle drei Agent-Typen (Chat-Agent in OWUI, Cron-Agents im agents-platform, Event-Agents in n8n falls vorhanden) schreiben in EINE agent_activity-Tabelle in der zentralen Postgres. Schema:

agent_activity (
  id uuid PRIMARY KEY,
  timestamp timestamptz,
  agent_type enum (chat | cron | n8n),
  agent_name text,
  user_id text nullable,
  trigger text,
  action text,
  tool_calls jsonb,
  status enum (success | error | pending_review),
  duration_ms int,
  cost_usd numeric,
  classifier text,         -- VFClassifyRouter-Output
  model text,              -- claude-haiku-4-5 etc
  error text nullable,
  raw_log_url text nullable
)

Cockpit hat eine /activity-Page mit Filter, plus „letzte 5 Aktionen”-Tile auf Homepage. Sichtbarkeit + Trust-Layer fuer Geschaeftsfuehrer.

Retention 90 Tage default, per Tenant erweiterbar.

Offene Fragen / TBD

Jitsi ja/nein — Self-Host-Vibe vs „Google Meet via Cal.com reicht eh”
Naming — agentic-ventures-workplace vs cockpit vs anderer Name (Marvin’s Entscheidung)
Lager-Default-Tier — Light-Tier (Baserow + Zettle-Stock) als Default, Pro-Tier (InvenTree) on-demand?
Cockpit-Modes-Aufteilung — eigene Subroutes /marvin/* und /tenant/<id>/*, oder ENV-basierte Build-Modes
n8n-Add-On — wenn ein Kunde unbedingt Klick-Workflow-Builder will, koennen wir nachschieben — aber Default raus
VF-Cockpit-Wireframe — vor Phase 2 mit Andre/Christoph durchgehen statt selbst-spekulieren

Pflegerealitaet (ehrlich)

Self-Host pro Kunde = du hostest 6-9 Apps. Twenty in Version 2.0 = pro Kunde Migration. Plane in Major-Version = pro Kunde Migration. Bei 5 Kunden = 5x dieselbe Update-Arbeit.

Mitigation:

Pre-Prod-Tenant (Marvin selbst nutzt es) → Updates dort zuerst, dann Kunden
CI-Pipeline fuer Tool-Updates: Container-Versionen gepinnt, Update via PR → Test im Pre-Prod → Rollout
Monatlicher Patch-Slot in Marvin’s active-work
Skalierungs-Limit ehrlich: max 10-15 Tenants Solo. Daruber: Hire oder hoeher-Preis-Tier mit weniger Pflege-Aufwand.

Wann diese Vision wieder hochkommt

Wenn VF-Phase-1 live ist und Adoption > 3x/Woche erreicht
ODER wenn ein neuer Kunde explizit das volle Paket nachfragt
Bis dahin: Vision-Doku, nicht Bauplan

Agentic Ventures Wiki

Explorer

Agentic Ventures Workplace — Standard-Stack fuer KMU-Suite