| 10 Min. Lesezeit

Von der App zum Agenten: Warum klassische Anwendungen nicht verschwinden, aber anders aussehen

AI Agents MCP Architecture UI

Auch auf Englisch verfügbar: From App to Agent: Why Classic Applications Won’t Disappear, but Will Look Different

Die These

Klassische Anwendungen verschwinden nicht. Sie verlieren aber ihre Rolle als Ort, an dem Menschen Daten eintippen, und werden zum verlässlichen Kern, auf dem Agents und Menschen gemeinsam arbeiten.

„Die Zukunft sind AI Agents und Chat“ höre ich inzwischen in fast jedem Projektgespräch. Die logische Anschlussfrage lautet: Soll man überhaupt noch Formulare, Masken und Dashboards bauen? Meine Antwort nach einigen Monaten mit eigenen Agents im Alltag: ja, aber anders. Die Frage ist weniger „App oder Agent“, sondern: Wer macht die Arbeit, und wo entscheidet der Mensch?

In diesem Beitrag beschreibe ich, wie sich die Architektur dadurch verschiebt, und zeige es an zwei eigenen Beispielen: meinem Belege-Agent für die Buchhaltung und HourPay, das als klassische Zeiterfassungs-App begonnen hat und heute als Agent läuft.

Was bleibt: der deterministische Kern

Agents brauchen etwas, worauf sie handeln können. Das ist genau das, was klassische Anwendungen immer schon gut gemacht haben: ein sauberes Datenmodell, Geschäftsregeln, Berechtigungen, Transaktionen und ein Audit-Trail.

Ein Sprachmodell ist probabilistisch. Eine Buchung, eine Rechnung oder ein Leistungsnachweis müssen deterministisch stimmen. Deshalb wird der Kern nicht unwichtiger, sondern wichtiger: Er wird nicht mehr nur von einem UI aufgerufen, sondern von beliebig vielen Agents, die schneller und öfter zugreifen als jeder Mensch.

Anthropic trennt in seinem Leitfaden zu effektiven Agents bewusst zwischen Workflows mit fest vorgegebenem Ablauf und Agents, die ihren Weg selbst steuern, und empfiehlt, mit der einfachsten Lösung zu beginnen (Building effective agents). Meine Lesart für Unternehmenssoftware: Die Intelligenz gehört an die Ränder, die Wahrheit in den Kern.

API und MCP zuerst, die Oberfläche danach

Wer heute eine Anwendung baut, sollte die Domänenlogik zuerst als saubere API entwerfen und sie zusätzlich als MCP-Server anbieten. Das UI ist dann nur noch ein Client unter mehreren.

Das Model Context Protocol ist inzwischen der De-facto-Standard dafür, wie Agents auf Werkzeuge und Daten zugreifen. Anthropic hat MCP im Dezember 2025 an die neu gegründete Agentic AI Foundation unter dem Dach der Linux Foundation übergeben, mitgetragen unter anderem von OpenAI, Google, Microsoft und AWS (Phoronix). Damit ist es kein Herstellerformat mehr, sondern offene Infrastruktur, vergleichbar mit dem Language Server Protocol für IDEs (MCP-Spezifikation).

Praktisch bedeutet das, die Werkzeuge so zu designen, wie ein Agent sie braucht:

  • Fachlich benannt: leistung_erfassen, nicht POST /api/v2/entries.
  • Idempotent und validiert: Ein Agent wiederholt Aufrufe. Doppelbuchungen muss der Kern abfangen, nicht das Modell.
  • Mit klaren Rechten: Lesen, Vorschlagen und Buchen sind getrennte Berechtigungen.
  • Mit Events statt nur CRUD: Agents sollen auf Ereignisse reagieren können, nicht nur abfragen.

Wer so baut, hat eine Anwendung, die ein Mensch über ein UI, ein Agent über MCP und ein anderes System über die API gleichermaßen nutzen kann. In meinem eigenen Setup ist das kein Zukunftsbild: Meine Agents greifen über MCP-Server auf Postfächer, Dokumente und andere Systeme zu, statt über selbst gebaute Integrationen.

UI on demand: die Oberfläche entsteht dort, wo sie gebraucht wird

Chat ist ein guter Einstieg, aber eine schlechte Ergebnisansicht. „Zeig mir alle offenen Posten über 30 Tage“ tippt man gern in natürlicher Sprache. Das Ergebnis will man aber als Tabelle sehen, sortieren und abhaken, nicht als Fließtext lesen.

Die Antwort darauf ist UI on demand: Die Anfrage kommt als Intent, die Antwort als passende Ansicht. Dafür gibt es inzwischen einen Standard. Mit MCP Apps (SEP-1865) können MCP-Server interaktive Oberflächen direkt an den Chat-Client liefern, die dort in einer abgeschotteten Umgebung laufen (SEP-1865). Die Erweiterung vereint die Ansätze von MCP-UI und dem Apps SDK von OpenAI. Unterstützung gibt es unter anderem in ChatGPT, VS Code Copilot Chat und Goose (morphllm).

Für Anwendungsentwickler verschiebt sich damit die Frage. Nicht mehr: „Welche Masken braucht die App?“ Sondern: „Welche Ansichten braucht ein Mensch, um eine Entscheidung zu treffen?“ Das sind meist drei Arten:

  1. Überblick: Dashboards und Listen, die man mit einem Blick erfasst.
  2. Review: Vorschläge des Agents mit Begründung, bereit zur Freigabe oder Korrektur.
  3. Ausnahmen: Was der Agent nicht sicher zuordnen konnte und eine menschliche Antwort braucht.

Alles andere, also das klassische Erfassungsformular, wird zur Ausnahme für die Fälle, die keine digitale Spur hinterlassen.

Datenerfassung neu gedacht

Am stärksten verändert sich die Datenerfassung. Der Mensch tippt nicht mehr ab, was ohnehin schon als Spur existiert, sondern bestätigt einen Entwurf.

Fast jede Arbeitsstunde und jede Ausgabe hinterlässt Spuren: Kalendertermine, Commits, Tickets, Mails, Rechnungen, Kontobewegungen. Ein Agent liest diese Quellen, baut daraus einen Vorschlag mit Begründung, und der Kern prüft ihn gegen feste Regeln wie Pflichtfelder, gültige Projekte, Tageslimits oder gesperrte Perioden. Erst dann sieht ihn ein Mensch.

Der Agent entwirft, der Mensch entscheidet, das System bucht Signale Mail, Kalender, Git, Kontoauszug Entwurf Agent schlägt vor, mit Grund Regeln Kern prüft deterministisch Freigabe Mensch prüft und bestätigt Buchung System of Record mit Audit-Trail Korrektur geht zurück an den Agenten

Was keine Spur hinterlässt, etwa ein Telefonat oder ein Termin vor Ort, wird frei ergänzt: als Chatnachricht oder Sprachnotiz, aus der der Agent einen strukturierten Eintrag macht. Dasselbe Muster funktioniert für Belege, Reisekosten, Wartungsprotokolle oder CRM-Pflege.

Beispiel 1: der Belege-Agent

Meine monatliche Buchhaltung läuft heute über einen Agenten, der Belege sammelt und zuordnet. Gebucht wird erst, wenn ich bestätige.

Der Ausgangspunkt war klassisch: ein Spesenverteiler als Excel-Datei mit Makros in SharePoint, den ich jeden Monat händisch befüllt habe. Belege kamen aus Gmail, Outlook, Amazon und auf Papier, dazu Bank- und Kreditkartenauszüge zum Abgleich.

Der Agent hat die Tabelle nicht ersetzt. Er hat das Abtippen ersetzt:

  • Signale: Rechnungen aus den Postfächern, Bestellungen, Kontoauszüge, fotografierte Papierbelege. Auf die Postfächer greift der Agent über MCP-Server zu.
  • Entwurf: Ein lokales Modell über ein LiteLLM-Gateway in meinem Homelab schlägt Zuordnungen zwischen Belegen und Kontobewegungen vor und schreibt sie in eine Vorschlagsdatei.
  • Regeln: Der normale Ablauf bleibt deterministisch, als Skripte. Das Modell darf vorschlagen, aber nichts buchen.
  • Freigabe: Ich prüfe die Vorschläge. Erst danach entsteht eine Importdatei, die über einen Button in den Spesenverteiler übernommen wird.
  • System of Record: Der Spesenverteiler selbst wird nie direkt verändert, Backups inklusive.

Das Ergebnis ist unspektakulär im besten Sinn. Die Excel-Datei, die an meine Steuerberatung geht, sieht aus wie immer. Verändert hat sich nur, wer die Arbeit macht.

Beispiel 2: HourPay, von der Timer-App zum Agenten

HourPay hat als klassische App begonnen und läuft heute als Agent. An diesem Projekt sieht man die Verschiebung am deutlichsten.

Die erste Version im Frühjahr 2026 war Lehrbuch-Webentwicklung: React und TypeScript im Frontend, Node.js mit SQLite im Backend, ein Live-Timer, Kunden und Kategorien, ein Monats-Dashboard, Export nach CSV und Excel und am Ende ein Leistungsnachweis als PDF mit Unterschriftszeilen. Die Datenquelle war ich selbst: Timer starten, stoppen, Kategorie wählen, Beschreibung tippen.

Genau dieser Teil war das Problem. Zeiterfassung scheitert selten an der Software, sondern daran, dass man vergisst, den Timer zu drücken.

Die Agent-Version dreht das um. Sie trägt aus den Spuren meines Arbeitstags zusammen, was ich gemacht habe, und baut daraus die Einträge. Aus dem Erfassungsformular wird eine Kontrolle.

HourPay als AppHourPay als Agent
Wer erfasstich, per Timer und Formularder Agent, aus vorhandenen Spuren
Rolle des MenschenDaten eingebenEntwurf prüfen und freigeben
HauptoberflächeTimer und EingabemaskeReview vor dem Monatsabschluss
Datenmodell und RegelnKunden, Kategorien, Rundungunverändert
ErgebnisLeistungsnachweis als PDFunverändert

Die letzten beiden Zeilen sind der eigentliche Punkt. Was der Kunde am Ende sieht und unterschreibt, ist gleich geblieben. Weggefallen ist nur die Oberfläche, auf der ich Daten eingetippt habe.

Ein Thema für sich: Model Routing

Wenn jeder Arbeitsschritt ein Modellaufruf sein kann, wird die Modellwahl zur Architekturentscheidung. Welche Aufgabe löst Code, welche ein kleines lokales Modell, welche ein großes Frontier-Modell, und wer entscheidet das zur Laufzeit? Beim Belege-Agent ist die Antwort heute bewusst einfach: zuerst Skript, das Modell nur dort, wo das Skript keinen eindeutigen Treffer findet, und Finanzdaten bleiben in meinem Netz.

Dahinter steckt ein eigenes Thema mit Gateways, Kosten, Datenschutz und Fallbacks. Dem widme ich einen eigenen Beitrag.

Wo die Grenzen liegen

Nicht jede Anwendung wird zum Agenten, und nicht jeder Agent ist eine gute Idee. Vier Grenzen sehe ich in der Praxis.

Klassische UI bleibt, wo Tempo und Routine zählen. Kassa, IDE, CAD oder Disposition leben von Hochfrequenz und Muskelgedächtnis. Ein Chat davor macht sie langsamer, nicht besser.

Viele Agent-Projekte scheitern. Gartner erwartet, dass bis Ende 2027 über 40 Prozent der Agentic-AI-Projekte wegen Kosten, unklarem Nutzen oder fehlender Risikokontrolle eingestellt werden. Trotzdem rechnet Gartner damit, dass bis 2028 rund ein Drittel der Unternehmenssoftware agentische KI enthält (Gartner). Beides passt zusammen: Agents lohnen sich dort, wo sie echte Arbeit abnehmen, nicht als Etikett.

Datenschutz und Arbeitsrecht. Für mich als Einzelunternehmer ist es unproblematisch, wenn ein Agent meinen Kalender und meine Commits auswertet. Im Unternehmen ist das schnell eine Kontrollmaßnahme. In Österreich brauchen Systeme zur Kontrolle von Arbeitnehmern, die die Menschenwürde berühren, die Zustimmung des Betriebsrats in Form einer Betriebsvereinbarung (§ 96 ArbVG). Ohne Betriebsrat braucht es die Zustimmung der Mitarbeiter (§ 10 AVRAG). Dass auch Zeiterfassung darunter fallen kann, zeigt die OGH-Entscheidung zu biometrischen Fingerscannern (OGH).

Nachweisbarkeit. Abrechenbare Stunden und gebuchte Belege müssen nachvollziehbar bleiben. Deshalb gibt es bei mir kein automatisches Absenden: Jeder Eintrag trägt seine Begründung, welche Signale ihn stützen, und ein Mensch gibt frei.

Ausblick und Faustregeln

Die nächsten Jahre gehören nicht dem Chat statt der App, sondern Anwendungen, die sauber trennen, wer die Arbeit macht und wo der Mensch entscheidet.

Gartner beschreibt diese Entwicklung in Stufen: von eingebetteten Assistenten über aufgabenspezifische Agents in einzelnen Anwendungen hin zu Agent-Ökosystemen, die anwendungsübergreifend zusammenarbeiten (Gartner). Die Richtung sehe ich im eigenen Alltag bestätigt.

Bei mir geht es als Nächstes in Richtung Themen-Agents: je ein Agent pro Bereich, der alles über sein Thema weiß, etwa für das Homelab oder die Belege. Jeder davon spricht mit seinen Systemen über APIs und MCP, und überall gilt dasselbe Muster.

Wer heute ein neues Projekt startet, kann sich an sechs Regeln halten:

  1. Kern solide bauen: Datenmodell, Regeln, Rechte und Audit klassisch und deterministisch.
  2. API und MCP als primäre Schnittstelle: fachlich benannte, idempotente Werkzeuge mit getrennten Rechten für Lesen, Vorschlagen und Buchen.
  3. Erfassen durch Finden ersetzen: vorhandene Spuren nutzen, statt Menschen tippen zu lassen.
  4. UI on demand: schlanke Oberflächen für Überblick, Review und Ausnahmen, Chat als Einstieg.
  5. Modelle über ein Gateway routen: Code vor kleinem Modell vor großem Modell, Rollen statt fest verdrahteter Modellnamen.
  6. Kein Auto-Submit: Der Agent schlägt vor, der Mensch gibt frei, das System bucht.

Quellen

Transparenz: Dieser Beitrag entstand mit KI-Unterstützung. Ich habe ihn geprüft und verantworte den Inhalt. Mehr dazu unter KI-Transparenz.