Wie ich über 80% Context-Overhead in meinem Coding-Agenten eingespart habe

Wenn man eine Session in einem modernen AI-Coding-Agenten startet, ist bereits ein gewaltiger Teil des Kontextfensters verbraucht, bevor man auch nur die erste Zeile tippt.

Zwischen System-Prompts, Formatierungsregeln, MCP-Server-Integrationen und dutzenden Tool-Schemas laden die meisten Agent-Harnesses bei jedem einzelnen Durchlauf 10.000 bis über 25.000 Tokens an statischem Overhead in den Kontext.

Die Realität sieht so aus: In 90% der Fälle braucht ein Agent nur vier elementare Datei- und Shell-Werkzeuge (read, bash, edit, write). Spezialisierte Tools wie Browser-Automatisierung, Bildgenerierung, Websuche oder Hintergrund-Aufgaben werden nur situativ gebraucht, manchmal nur einmal pro Woche.

Lässt man 25 bis über 80 Tool-Definitionen permanent im Funktionsschema des Modells aktiv, verschwendet das nicht nur Tokens und Geld, sondern erhöht die Latenz und verschlechtert das logische Denkvermögen des Modells, weil der Aufmerksamkeitsraum mit irrelevanten Parametern überflutet wird.

Ich habe dieses Problem mit zwei Designentscheidungen gelöst:

1. Aktionsbasierte Tool-Konsolidierung: Tools von Tag eins an so strukturieren, dass typische CRUD-Doppelungen im Schema vermieden werden.
2. Dynamische Tool-Aktivierung in Pi: Ein schlankes Basis-Set von 4 Tools aktiv halten, alles andere auf Standby setzen und Werkzeuge bei Bedarf automatisch oder manuell ohne Meta-Tool-Schema zuschalten, inklusive automatischer TTL-Bereinigung.

Status Quo: Turn-0-Kontext im Vergleich

Um das Ausmaß des Problems greifbar zu machen, habe ich getestet, wie gängige Coding-Harnesses mit Tool-Schemas umgehen, wenn man in einer frischen Session lediglich ein einfaches "hi" sendet.

1. Codex: 79 Tools und 14,5k Tokens standardmäßig

In Codex habe ich alle externen Plugins und MCP-Server deaktiviert, sodass nur zwei eigene Skills neben den integrierten Standardfunktionen liefen. Dann habe ich eine neue Session geöffnet und nur "hi" eingetippt.

Das Modell antwortete mit einer simplen Begrüßung ("Hi! How can I help?"). Ein Blick in den Session-Status zeigte: Es waren bereits 14.534 Tokens verbraucht (6% des gesamten 258k-Kontextfensters waren in Turn 0 weg).

Abbildung 1: Kontextverbrauch in Codex nach einem einfachen "hi". 14.534 Tokens verbraucht, bevor echte Arbeit beginnt.

Auf die Frage an den Agenten, welche Tools aktuell aufrufbar sind, lieferte er eine Liste von 79 aktiven Tools.

apply_patch
codex_app__automation_update
codex_app__create_thread
codex_app__fork_thread
codex_app__get_handoff_status
codex_app__handoff_thread
codex_app__list_archived_threads
codex_app__list_projects
codex_app__list_threads
codex_app__load_workspace_dependencies
codex_app__navigate_to_codex_page
codex_app__open_in_codex
codex_app__read_thread
codex_app__read_thread_terminal
codex_app__send_message_to_thread
codex_app__set_thread_archived
codex_app__set_thread_pinned
codex_app__set_thread_title
codex_app__share_thread
codex_app__wait_threads
create_goal
exec_command
get_goal
image_gen__imagegen
list_available_plugins_to_install
list_mcp_resource_templates
list_mcp_resources
mcp__codex_apps__codex_document_control_execute_document_command
mcp__codex_apps__codex_document_control_get_document_tool_schemas
mcp__codex_apps__codex_document_control_list_document_sessions
mcp__codex_apps__plugin_management_get_app_permissions
mcp__codex_apps__plugin_management_get_plugin_dependencies
mcp__codex_apps__plugin_management_uninstall_app
mcp__codex_apps__plugin_management_update_app_permissions
mcp__codex_apps__safety_settings_get_family_info
mcp__codex_apps__safety_settings_get_parental_controls
mcp__codex_apps__safety_settings_get_trusted_contact
mcp__codex_apps__safety_settings_prepare_parental_control_update
mcp__codex_apps__safety_settings_update_parental_control
mcp__codex_apps__sites_add_custom_domain
mcp__codex_apps__sites_change_site_slug
mcp__codex_apps__sites_create_site
mcp__codex_apps__sites_create_source_repository_write_credential
mcp__codex_apps__sites_deploy_private_site_version
mcp__codex_apps__sites_deploy_site_version
mcp__codex_apps__sites_generate_siwc_bypass_token
mcp__codex_apps__sites_get_deployment_status
mcp__codex_apps__sites_get_environment_variables
mcp__codex_apps__sites_get_site
mcp__codex_apps__sites_get_site_version
mcp__codex_apps__sites_get_site_worker_logs
mcp__codex_apps__sites_list_custom_domains
mcp__codex_apps__sites_list_site_versions
mcp__codex_apps__sites_list_sites
mcp__codex_apps__sites_read_database_overview
mcp__codex_apps__sites_read_database_table_rows
mcp__codex_apps__sites_refresh_custom_domain_status
mcp__codex_apps__sites_remove_custom_domain
mcp__codex_apps__sites_save_site_version
mcp__codex_apps__sites_update_environment_variables
mcp__codex_apps__sites_update_site_access
mcp__codex_apps__sites_update_site_metadata
mcp__node_repl__js
mcp__node_repl__js_add_node_module_dir
mcp__node_repl__js_reset
multi_agent_v1__close_agent
multi_agent_v1__resume_agent
multi_agent_v1__send_input
multi_agent_v1__spawn_agent
multi_agent_v1__wait_agent
plugin_management__uninstall_plugin
read_mcp_resource
request_permissions
request_plugin_install
update_goal
update_plan
view_image
web__run
write_stdin

Aktiviert man zusätzlich nur ein oder zwei typische Erweiterungen wie Security-Scanner oder GPT-Apps, übersteigt die Tool-Liste schnell die Marke von 100 aktiven Werkzeugen.

2. Gemini und Antigravity: Weniger Tools, trotzdem 19,9k Tokens

Man könnte annehmen, dass eine kürzere Tool-Liste das Problem von selbst löst. Das Antigravity-CLI (agy) mit Gemini 3.7 Flash beweist das Gegenteil.

Ich habe denselben Test gemacht: Neue Session, nur "hi" gesendet.

Die Antwort war eine Zeile ("Hello! How can I help you with your project today?"). Die Telemetrie zeigte sofort 19,9k verbrauchte Tokens in Turn 0, wovon 13,8k Tokens alleine auf Tool-Schemas entfielen.

Abbildung 2: Aufschlüsselung in Antigravity nach einem einfachen "hi". 13,8k Tokens entfallen alleine auf Tool-Schemas.

Antigravity hatte nur 17 Tools aktiv, nicht 79. Trotzdem verbrauchten die Schemas 13,8k Tokens.

1. run_command
2. manage_task
3. schedule
4. define_subagent
5. invoke_subagent
6. manage_subagents
7. send_message
8. write_to_file
9. replace_file_content
10. view_file
11. list_dir
12. grep_search
13. find_by_name
14. search_web
15. read_url_content
16. generate_image
17. ask_question

Das Problem mit redundanten Tools

Warum braucht ein Agent eigene Tools für list_dir, grep_search und find_by_name, wenn er bereits run_command (natives Bash) zur Verfügung hat?

Ein Agent mit Bash-Zugriff kann ls, grep, rg oder find direkt ausführen. Eigene Funktionsschemas für grundlegende Shell-Befehle verdoppeln Fähigkeiten, die das Modell ohnehin besitzt, und laden tausende unnötige Schema-Tokens bei jedem Prompt in den Kontext.

3. Claude Code: Basis-Setup und das MCP-Dilemma

Anthropic hat dieses Problem in Claude Code erkannt und eine Funktion namens Deferred Tool Loading eingeführt.

In der Standardinstallation ohne MCP-Server hält Claude Code eine Basis von etwa 8 bis 10 integrierten Werkzeugen (Bash, View/Read, Edit, Replace, Glob, Grep, Agent, WebSearch, NotebookEdit). Zusammen mit System-Prompts und Projektanweisungen liegt der Startverbrauch bei etwa 3.500 bis über 5.000 Tokens.

Sobald Entwickler mehrere MCP-Server für Datenbanken, Ticket-Systeme oder Browser anbinden, steigt die Tool-Anzahl schnell auf 30 bis über 40 Werkzeuge. Dadurch wächst allein der Schema-Overhead auf 10.000 bis über 14.000 Tokens pro Turn.

Um dem entgegenzuwirken, teilt Claude Code Werkzeuge in zwei Stufen ein, sobald aufschiebbare Definitionen 10% des Kontextfensters übersteigen:

1. Immer geladen: Kernwerkzeuge für Dateien und Suche plus Infrastruktur (Bash, Read, Edit, Write, Glob, Grep, Agent, ToolSearch, Skill).
2. Aufgeschoben (nur Name): WebSearch, NotebookEdit, Cron-Tools und alle angebundenen MCP-Tools.

Immer geladen:
Bash, Read, Edit, Write, Glob, Grep, Agent, ToolSearch, Skill

Aufgeschoben (nur Namen bis zur Aktivierung):
WebSearch, TodoWrite, NotebookEdit, CronCreate, MCP servers...

Deferred Loading verringert zwar den Ballast bei vielen MCPs, die Auflösung basiert jedoch auf einem Meta-Tool namens ToolSearch:

• Benötigt das Modell ein aufgeschobenes Tool, muss es zuerst ToolSearch("select:ToolName") aufrufen.
• Das Backend injiziert das vollständige Schema erst danach in den Kontext, und das Tool kann erst im folgenden Turn ausgeführt werden.
• Damit das Modell geladene Tools bei Kontext-Kompressionen nicht vergisst, muss die Laufzeit eigene Kompressionsgrenzen und Wiederherstellungslogik verwalten.
• Selbst im Minimalzustand bleiben 9 Tools dauerhaft geladen (inklusive redundanter Suchwerkzeuge und dem Meta-Tool selbst), was mehrere tausend Tokens Grundrauschen verursacht.

*Hinweis zu Claude Code: Da ich Claude Code nicht selbst nutze, basieren diese Zahlen auf technischen Analysen, Nutzerberichten und Community-Daten. Ich habe hier die konservativsten Schätzungen aus Standard-Setups übernommen.

Warum dieser Overhead die Leistung spürbar verschlechtert

Dieser statische Schema-Ballast führt zu zwei klaren Problemen:

1. Token-Kosten und rasche Kontext-Erschöpfung. Wer schon in Turn 0 zwischen 14k und 20k Tokens verbrennt, stößt in längeren Sessions viel schneller an Kontext- und Rate-Limits. Bei jedem Turn werden diese 17 bis 80+ Tool-Schemas erneut mitgeschickt.
2. Verwässerte Aufmerksamkeit und Halluzinationen. Sprachmodelle arbeiten am präzisesten, wenn ihr Entscheidungsraum fokussiert ist. Sieht das Modell dutzende ähnliche Endpunkte (mehrere Thread-Verwalter, Deployment-APIs, Subagenten, doppelte Dateisuch-Tools), verbraucht es Reasoning-Kapazität beim Filtern irrelevanter Optionen und greift eher zum falschen Werkzeug.

Prinzip 1: Aktionsbasierte Tool-Konsolidierung statt CRUD-APIs

Effizienz beginnt nicht erst bei Laufzeit-Tricks, sondern beim Design der einzelnen Werkzeuge.

In der klassischen Softwareentwicklung ist es üblich, für jede Aktion einen eigenen CRUD-Endpunkt anzulegen:

• memory_read
• memory_write
• memory_update
• memory_delete

Für Web-APIs ist das sinnvoll, weil ein zusätzlicher Endpunkt im Code keinen Payload-Aufwand verursacht, solange niemand ihn anfragt.

Für KI-Agenten gilt das Gegenteil: Jedes registrierte Schema wird bei jedem Turn übertragen und belegt Platz im Prompt. Vier CRUD-Tools bedeuten vier JSON-Header, vier Beschreibungen, vier Parameter-Bäume und vier Optionen, die das Modell abwägen muss.

Aktionsbasierte Bündelung

Wenn ich eigene Werkzeuge für Agenten baue, fasse ich Operationen nach Absicht zusammen. Für Memory-Systeme nutze ich maximal zwei Werkzeuge:

1. memory_read: Für semantische Suche, Stichwortsuche und das gezielte Abrufen von Einträgen.
2. memory_write: Für das Anlegen, Aktualisieren und Löschen von Einträgen über einen action-Parameter ("create" | "update" | "delete").

{
  "name": "memory_write",
  "description": "Create, update, or delete entries in agent memory.",
  "parameters": {
    "type": "object",
    "properties": {
      "action": {
        "type": "string",
        "enum": ["create", "update", "delete"],
        "description": "The mutation action to perform."
      },
      "id": {
        "type": "string",
        "description": "Memory ID (required for update or delete)."
      },
      "content": {
        "type": "string",
        "description": "Memory content (required for create or update)."
      }
    },
    "required": ["action"]
  }
}

Das Schema für memory_write ist nur etwa 15% bis 20% größer als ein einzelnes memory_create-Schema, ersetzt aber drei separate Tools auf einmal. Man halbiert den Schema-Footprint ohne jeden Funktionsverlust.

Wer noch radikaler sparen will, kann sämtliche Memory-Interaktionen in ein einziges memory-Tool mit einem umfassenden action-Enum packen (search, fetch, create, update, delete).

Moderne Modelle beherrschen solche aktionsbasierten Werkzeuge extrem zuverlässig. Ich nutze diesen Ansatz seit Monaten quer durch alle Workflows ohne Aussetzer bei der Parameterauswahl.

Diese Einsparungen greifen bereits, bevor irgendeine dynamische Aktivierung überhaupt ins Spiel kommt.

Prinzip 2: Dynamische Tool-Aktivierung in Pi

Erfahrungen aus denkr.ai

Dieses Problem kenne ich bereits aus der Entwicklung meiner mobilen App denkr.ai.

Auf Mobilgeräten treibt unnötiger Kontextballast sofort die Latenz und die Betriebskosten nach oben. In Denkr habe ich früh ein dynamisches Routing implementiert, das Werkzeuge erst bei passender Absicht bereitstellt. Es hat sich gezeigt: Modelle haben keinerlei Probleme damit, Werkzeuge dynamisch anzufordern, wenn die Anweisungen eindeutig und die Hürden minimal sind.

Als ich Pi zu meinem primären Coding-Agenten gemacht habe, wollte ich denselben schlanken Ansatz. Da Pi Open Source ist und direkten Zugriff auf Lifecycle-Hooks gewährt, war der Bau des Erweiterungssystems sehr unkompliziert.

Wie die dynamische Aktivierung funktioniert

Die Erweiterung (dynamic-tools) basiert auf vier Mechanismen:

1. Striktes Standard-Set von 4 aktiven Tools (read, bash, edit, write).
2. Standby-Pool mit leichtgewichtigen Markdown-Hinweisen im System-Prompt.
3. In-Process-Abfangen von Bash-Befehlen (pi-tool).
4. Ko-Aktivierungsgruppen und automatische TTL-Bereinigung.

+-------------------------------------------------------------+
|                      User Prompt                            |
+-------------------------------------------------------------+
                              |
                              v
+-------------------------------------------------------------+
|               Pi Hook: before_agent_start                   |
|  - Aktive Tools gesetzt auf: read, bash, edit, write        |
|  - Minimaler Markdown-Standby-Hinweis im Prompt             |
+-------------------------------------------------------------+
                              |
                              v
+-------------------------------------------------------------+
|             LLM will Standby-Tool nutzen                    |
|            Führt Bash aus: pi-tool activate browser_use     |
+-------------------------------------------------------------+
                              |
                              v
+-------------------------------------------------------------+
|                  Pi Hook: tool_call                         |
|  - Fängt Bash-Befehl prozessintern ab                       |
|  - Ruft pi.setActiveTools([...defaults, ...browserTools])   |
|  - Schreibt Bash-Befehl in sicheres Echo um                 |
+-------------------------------------------------------------+
                              |
                              v
+-------------------------------------------------------------+
|                  Pi Hook: agent_settled                     |
|  - Zählt TTL-Zähler für Nicht-Standard-Tools herunter       |
|  - Entfernt inaktive Tools automatisch nach Ablauf          |
+-------------------------------------------------------------+

Die technischen Mechanismen im Detail

1. Minimales Standard-Set (4 Kern-Tools)

Beim Start erzwingt die Erweiterung ein schlankes Schema mit nur 4 Werkzeugen:

const DEFAULT_CONFIG = {
  defaultTools: ["read", "bash", "edit", "write"],
  groups: {
    web_search: ["web_search", "web_fetch"],
    browser_use: [
      "browser_open",
      "browser_observe",
      "browser_preview",
      "browser_diagnostics",
      "browser_act",
      "browser_wait",
    ],
    loops: ["loops_report", "loops_create_definition", "loops_create_job", "loops_inspect"],
  },
  autoResetOnSessionStart: true,
  toolTtlRuns: 2,
};

Jedes weitere in Pi registrierte Werkzeug (über Plugins, MCP oder lokale Skripte) bleibt intern geladen, wird aber über pi.setActiveTools(...) aus dem aktiven LLM-Schema herausgehalten.

2. Kein Meta-Tool: Prompt-Injektion statt Schema-Ballast

Ein häufiger Fehler bei Tool-Managern ist das Erstellen eines eigenen LLM-Meta-Tools (wie activate_tool({ name: string })).

Ein Meta-Tool bringt wieder eigenes JSON-Schema, Parameter-Dokumentation und Funktionsaufruf-Overhead mit sich.

Stattdessen nutze ich Pis before_agent_start-Hook, um eine winzige Markdown-Zusammenfassung an den System-Prompt anzuhängen:

pi.on("before_agent_start", async (event, _ctx) => {
  await loadConfig();
  applyActiveTools();

  const standby = getStandbyTools();
  if (standby.length === 0) return;

  const standbyLines = standby.map((name) => {
    const group = findGroupForTool(name, config.groups);
    return group ? `- \`${name}\` (part of group: **${group}**)` : `- \`${name}\``;
  });

  const injection = [
    "## Dynamic Tool Activation",
    `Default active tools: ${config.defaultTools.map((t) => `\`${t}\``).join(", ")}.`,
    "Standby tools (not currently in your active schema):",
    ...standbyLines,
    "",
    "To activate a tool or group, run in bash: `pi-tool activate <name>`",
  ].join("\n");

  return {
    systemPrompt: `${event.systemPrompt}\n${injection}`,
  };
});

Eine Textliste mit 20 Tool-Namen benötigt etwa 100 Tokens. 20 vollständige JSON-Tool-Schemas mit Typen und Beschreibungen schlucken dagegen zwischen 4.000 und 10.000 Tokens.

3. In-Process-Abfangen über Bash

Da der Agent ohnehin Zugriff auf bash hat, braucht er kein neues Werkzeug, um andere freizuschalten. Er führt einfach aus:

pi-tool activate browser_use

Die Erweiterung fängt diesen Aufruf direkt im Node.js-Prozess über pi.on("tool_call") ab:

pi.on("tool_call", async (event, _ctx) => {
  if (event.toolName !== "bash") return;
  const command = event.input?.command;
  if (typeof command !== "string") return;

  const piToolMatch = command.trim().match(/^(?:pi-tools?|activate-tool)(?:\s+(.*))?$/i);
  if (!piToolMatch) return;

  // Tools im Speicher aktivieren
  const result = activateTools(targetArgs);
  const outputMessage = `[dynamic-tools] Activated tool(s): ${result.activated.join(", ")}`;

  // Befehl umschreiben, sodass Bash ein sauberes Echo mit Exit-Code 0 ausgibt
  const escaped = JSON.stringify(outputMessage);
  event.input.command = `node -e 'console.log(${escaped})'`;
});

Es wird keine externe CLI-Binary auf dem System benötigt. Pi registriert den Befehl, aktualisiert pi.setActiveTools(), schreibt die Shell-Ausführung auf ein Bestätigungsecho um und liefert das Ergebnis an das Modell. Im nächsten Turn stehen die aktivierten Werkzeuge im JSON-Schema bereit.

4. Ko-Aktivierungsgruppen

Tools werden selten isoliert benötigt. Braucht der Agent Browser-Automatisierung, benötigt er Navigation, Inspektion und Interaktionswerkzeuge im Verbund (browser_open, browser_observe, browser_act, browser_wait).

Über die Konfiguration werden zusammenhängende Werkzeuge gebündelt. Ein Aufruf wie pi-tool activate browser_use aktiviert das komplette Paket auf einen Schlag.

5. Automatische TTL-Bereinigung

Ist eine Spezialaufgabe erledigt, sollten diese Werkzeuge nicht den restlichen Tag im Kontext verbleiben.

Jedes aktivierte Standby-Tool erhält einen Time-To-Live-Zähler (Standard: 2 Durchläufe).

pi.on("agent_settled", async (_event, _ctx) => {
  let changed = false;

  for (const [tool, ttl] of Array.from(toolTtlMap.entries())) {
    const nextTtl = ttl - 1;
    if (nextTtl <= 0) {
      activeToolNames.delete(tool);
      toolTtlMap.delete(tool);
      changed = true;
    } else {
      toolTtlMap.set(tool, nextTtl);
    }
  }

  if (changed) {
    applyActiveTools();
  }
});

Benutzt der Agent ein aktiviertes Tool aktiv, wird dessen TTL erneuert. Kehrt er zu normalen Programmieraufgaben zurück und lässt das Tool 2 Runden lang ungenutzt, läuft die Frist ab und das System fällt automatisch auf das 4-Tool-Basisset zurück.

6. Echte Telemetrie in CircaCode

So sieht das Ergebnis in der Praxis bei einer einfachen Begrüßung ("hi") aus:

Abbildung 3: Turn-0-Kontextverbrauch in Pi innerhalb von CircaCode. Nur 3,6k Tokens verarbeitet (3,5k Input, 1,3% des 272k-Fensters), inklusive System-Prompt, Persona, Skills und Standby-Hinweisen.

Hinweis: Dieser Screenshot stammt aus meiner eigenen Desktop-App CircaCode, die Pi als Agent-Engine nutzt.

7. Slash-Befehle für die manuelle Steuerung

Für die manuelle Kontrolle stellt die Erweiterung native Slash-Commands bereit:

• /activate-tool <name>
• /deactivate-tool <name>
• /tool list
• /tool reset

Mit Autovervollständigung und interaktiven Auswahlmenüs (ctx.ui.select) haben Mensch und Agent jederzeit die volle Kontrolle über den aktiven Werkzeugkasten.

Der direkte Vergleich

So schneiden die vier Agent-Umgebungen bei einem simplen "hi" in Turn 0 ab:

*Claude Code Zahlen stellen konservative Schätzungen aus Entwicklerberichten und technischer Dokumentation dar, keine eigenen Messungen.

Fazit und Erkenntnisse

1. Denkvermögen und Aufmerksamkeit des Modells schonen

Sprachmodelle arbeiten spürbar sauberer, wenn ihr Kontextfenster schlank bleibt. Sobald sich das Fenster über 40% bis 50% füllt, lässt die Aufmerksamkeit nach: Anweisungen werden übersehen, Syntaxfehler schleichen sich ein und falsche Tool-Aufrufe nehmen zu.

Wer jede Session mit 15k bis 20k Tokens an statischen Tool-Schemas startet, verschenkt diesen Leistungsbereich leichtfertig. Mit nur 3,6k Tokens zum Start bleibt das Modell bei komplexen Programmieraufgaben deutlich länger in Bestform.

2. Werkzeuge bauen und anbinden ohne Kontext-Panik

Vor der dynamischen Aktivierung war jedes neue Tool ein architektonischer Kompromiss. Man musste sich bei jeder Funktion fragen: „Ist dieses Feature wichtig genug, um dauerhaft 500 Schema-Tokens an jeden einzelnen Prompt anzuhängen?“

Mit dynamischer Aktivierung ist diese Hürde weg. Ich kann so viele Erweiterungen und Tools bauen und verbinden, wie ich will, egal ob Browser-Steuerung, Loop-Aufgaben, Scraper, Sprachausgabe oder Datenbank-Helfer.

Auf Standby belegt ein Tool kein JSON-Schema, sondern nur eine Textzeile im Prompt-Hinweis (ca. 5 bis 10 Tokens). Man bekommt die volle Flexibilität eines riesigen Ökosystems, ohne dafür bei einfachen Code-Änderungen den Kontextpreis zu zahlen.

3. Offene Agent-Laufzeiten gewinnen

Harnesses, die den LLM-Kontext als offene, erweiterbare Laufzeit begreifen, machen solche Optimierungen erst möglich. Direkter Zugriff auf Lifecycle-Hooks (before_agent_start, tool_call, agent_settled) erlaubt es, das System exakt an die eigene Arbeitsweise anzupassen, anstatt an starre, überladene Schemas gebunden zu sein.