Quickstart

In fünf Minuten zum ersten Agenten-Lauf

Fünf Schritte: Zugang, Projekt, ein Werkzeug, eine Policy, ein Lauf. Am Ende haben Sie einen Trace mit Spans, eine Kostenzeile und ein Audit-Log — und wissen, ob Ihnen die Bauform zusagt, bevor jemand über Verträge spricht.

npx @hostspezial/agentctl init

Der Quickstart führt in fünf Schritten zum ersten lauffähigen Agenten: Zugang einrichten, Projekt anlegen, einen MCP-Server registrieren, eine Policy hinterlegen und den Lauf starten. Danach lesen Sie den Trace mit allen Tool-Calls, Latenzen und Kosten — lokal oder in der bereitgestellten Sandbox.

Voraussetzungen

Node.js 20 oder neuer, ein Sandbox-Zugang von uns und ein System, das der Agent lesen darf — für den Anfang genügt eine Testdatenbank. Sie brauchen keine GPU und keine eigene Modell-Infrastruktur; das Model-Gateway ist Teil der Sandbox.

Schritt 1 — Zugang einrichten

Der Zugang wird pro Person ausgestellt und ist an Ihre Organisation gebunden. Das lokale Token gilt acht Stunden.

Terminal
npx @hostspezial/agentctl login --org ihre-org
# Oeffnet den Browser, legt ein kurzlebiges Token unter ~/.agentctl ab.

Schritt 2 — Projekt anlegen

init erzeugt ein Verzeichnis mit Agentendefinition, Policy und einem ersten Testfall. Alles liegt als Datei vor und gehört ins Repository — nicht in eine Web-Oberfläche.

Terminal
npx @hostspezial/agentctl init mein-erster-agent
cd mein-erster-agent

# mein-erster-agent/
#   agent.ts            Definition des Laufs
#   tools.policy.yaml   Wer darf welches Werkzeug, mit welchem Limit
#   evals/first.spec.ts Ein Testfall, damit die CI von Anfang an gruen ist

Schritt 3 — Ein Werkzeug registrieren

Ein Agent ohne Werkzeug ist ein Chatbot. Registrieren Sie einen MCP-Server — hier eine Testdatenbank, ausschließlich lesend.

Terminal
agentctl tools add postgres \
  --url "mcp+https://mcp.hostspezial.de/postgres" \
  --scope "read:orders" \
  --secret-ref "vault://demo/pg-readonly"

# Zugangsdaten liegen als Referenz vor, nie als Klartext im Repo.
agentctl tools list

Schritt 4 — Policy hinterlegen

Die Policy ist die Sicherung, nicht der Prompt. Standardentscheidung ist deny; erlaubt wird, was ausdrücklich erlaubt ist.

tools.policy.yaml
agent: mein-erster-agent
default: deny

tools:
  - name: postgres.query
    allow: true
    constraints: { statements: ["SELECT"], max_rows: 100 }

# Harte Obergrenze. Ohne Cap kann eine Schleife still teuer werden.
budget: { eur: 0.05, tokens: 50000 }

Schritt 5 — Lauf starten und Trace lesen

Jetzt der eigentliche Moment: ein Lauf mit echter Ausgabe, echten Latenzen und einer Kostenzeile.

Terminal
agentctl run --input '{"orderId": 4711}'

# run   r-2b91ef   started
# span  agent.run                            2 100 ms
# span  tool.postgres.query   allow            38 ms
# span  agent.answer                          640 ms
# done  status=completed  tokens=3 480  cost=0,009 EUR

# Denselben Lauf ohne echte Aufrufe wiederholen:
agentctl replay r-2b91ef

Was danach sinnvoll ist

  1. Einen echten Fall aufnehmen. Nehmen Sie einen realen Vorgang aus Ihrem Betrieb als Eval-Fixture auf — das ist der Grundstein Ihrer Eval-Suite.
  2. Ein zweites Werkzeug anbinden. Ab hier wird die Auswahlqualität interessant. Mehr dazu im Tool-Layer.
  3. Den Fehlerfall provozieren. Brechen Sie den Lauf mitten im Tool-Call ab und beobachten Sie die Wiederaufnahme — siehe Durable Execution.
  4. Erst dann schreibende Rechte. Vorher lohnt der Security-Abschnitt zu Scopes und Freigabeschwellen.
Was der Quickstart nicht zeigt

Er läuft gegen eine Sandbox mit unseren Modell-Endpunkten und einer Testdatenbank. Fragen zu Datenresidenz, Aufbewahrung und Auftragsverarbeitung beantwortet er nicht — die stehen auf der Trust-Seite. Und er sagt nichts über Kosten bei Ihrem Volumen; dafür gibt es den Rechner auf der Preisseite.

Weiterlesen

Sandbox-Zugang anfragen

Wir richten die Sandbox mit einem Ihrer Systeme ein und begleiten den ersten Lauf gemeinsam — typischerweise in einem Termin von 45 Minuten. Ohne Vorleistung Ihrerseits.

Oder direkt: 09571 873149 · info@hostspezial.de