Agent Mode Quickstart: First Managed LLM Call in 2 Minutes

Every LLM gateway ships with a quickstart page. Sign up, click a button, copy a curl, paste it into your terminal. If the HTTP 200 comes back, you have made your first call. The page celebrates. The problem is that the call you just made has nothing to do with how you will actually use the gateway in production.

Production calls come from named agents. They are scoped to an organization. They show up in an observability dashboard with a name you recognize, not a random key fingerprint. They enforce budgets, model restrictions, and content policy. The typical quickstart skips all of that — it validates the HTTP path and the auth header, nothing more. You are already a step away from your real integration before you have even started.

The Gap Between First Call and First Managed Call

Watch a developer sign up for any LLM gateway and you see the same sequence. Create an API key named 'test' or 'temp'. Paste a curl from the docs. Get a response. Then realize the key is not scoped to anything meaningful, the request did not originate from a named agent, and the cost dashboard shows a single row labeled 'unknown'. To make it real, they have to navigate back into the product, register an agent, create a new key, swap it into their code, and re-run.

Every one of those steps is a place where people drop off. The quickstart proves the HTTP layer works. It does not prove the product works. It is the integration equivalent of compiling hello world and calling the project shipped.

A quickstart that does not reach your observability dashboard is a curl command with extra steps.

Agent Mode — Named, Scoped, Observable

Agent Mode is the new default quickstart in Dobby's Agentic Gateway. Instead of minting a throwaway key and a hardcoded model, you register an agent first. The form takes a name, a description, and a default model. When you submit, the gateway does four things at once: creates the agent in the catalog, mints a service key (gk_svc_*) scoped to that agent, pre-fills curl / Node / Python snippets with your key and model, and enables a one-click Send a Test Request button that fires through the real pipeline.

• A named agent in your catalog — searchable, editable, auditable
• A gk_svc_* service key with 500 RPM limits and org scope
• OpenAI-compatible snippets for curl, Node, and Python, pre-filled with your values
• A one-click test request that runs the full 13-hook PRE pipeline (auth → budget → policy → DLP → LLM) plus the POST hallucination check
• A live row in your observability dashboard within seconds

From signup to seeing your agent make a real LLM call under budget and policy enforcement — two minutes. No sidebar navigation, no second key, no swap. The quickstart is the real integration.

Service Keys vs User Keys — Why It Matters Here

Dobby's gateway uses three key tiers: user keys (gk_user_*) for individual developers at 100 RPM, service keys (gk_svc_*) for backend services at 500 RPM, and temporary keys (gk_tmp_*) that auto-expire. Agent Mode deliberately picks gk_svc_* — because an agent is a service, not a person. Rate limits match production workloads. Scopes are narrower. And crucially, the key is attached to the agent record, so every request logs against a real identity instead of a random user who happens to hold the key.

When you rotate the key, the agent keeps existing. When you offboard a developer, their user keys get revoked but the service key that powers the agent stays live. This is the same separation that cloud platforms made decades ago between human IAM users and machine service accounts — and the reason it matters for LLM traffic is identical: humans come and go, workloads should not break because of it.

What Happens on Send a Test Request

Clicking the button in the UI posts to an internal proxy endpoint, which forwards to the gateway with your service key. The request then flows through the full lifecycle: authentication, key validation, org plan lookup, rate limiting, budget check, model whitelist, prompt injection scan, content shield DLP, profile merge, provider routing, streaming handler, cost capture, audit log, and a POST-response hallucination check. A typical test lands in under a second.

# The exact curl that the UI pre-fills for you
curl https://dobby-ai.com/api/v1/gateway/chat/completions \
  -H "Authorization: Bearer gk_svc_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-4-20250514",
    "messages": [
      {"role": "user", "content": "Reply with a single word: ready"}
    ]
  }'

The response comes back in OpenAI-compatible JSON. A second later, a row appears in your LLM Observability dashboard with the agent name, model, input tokens, output tokens, cost in cents, and a trace ID. That row is identical to the ones your production traffic will produce — because it is production traffic. There is no sandbox and no mock. The only difference is that the prompt is a canned 'say ready' string.

Try It in 2 Minutes

Head to the Dobby dashboard, open the Gateway section, flip the mode toggle to With agent, and fill in a name. The first snippet will be there waiting. Run it, open Observability, and you will see your agent in the fleet. From there, the next step is the one that matters for your product: swap the model for the one you actually want to ship with, point your code at the snippet, and let the gateway do its job — budget, policy, and audit on every call.