Agents & deployments

Agents in the Console’s sidebar lists every agent in the active scope. New agent asks for exactly one thing — a name — creates the agent, and lands you on its overview; the definition itself comes from a deploy (the console’s create flow or guuey deploy).

Workspace agents follow workspace roles: members see these pages read-only; editing needs admin or above.

Overview

The overview is the agent’s front door:

• Connect your agent — a guide that walks the required steps (connect a deploy, get a first session), then collapses into a ship-it checklist (embed the widget, publish the listing, configure auth) once the agent works.
• Live endpoint — once the latest deploy is live, its endpoint URL sits at the top of the overview with a copy button, next to a Test in playground shortcut. Build progress lives on the Deployments tab.
• Usage this month — one card, per calendar month (UTC), in the card’s own order: sessions (one per new conversation started with the agent, on any channel), answers (one per completed agent reply, streamed or not — counted when the reply lands), generations (against the plan’s quota), managed LLM tokens (in · out) and widget opens (one per server-side load of the embedded widget page — the page load, not a click; proxy, OG and favicon fetches never count). Sessions, answers and widget opens are display counters — not billed, not metered, no rate-card line; the billed axes are unchanged (see Plans & billing).
• Banners that matter — if the app is on its 7-day trial, a countdown banner shows here (and on the billing panel). At expiry the platform pauses the app — the pod stops serving — and choosing a plan resumes it within a few minutes, with no redeploy. A failed payment shows its own banner pointing at Billing.

Playground

Chat with your deployed agent without leaving the Console. The playground talks to the same live endpoint your users reach, so what you see is what they get.

Behavior

What this page shows depends on how the agent was built.

Created from a brief (no code) — one section, System prompt, over the prompt your live agent runs. Save & redeploy writes your edit into the live build and redeploys it: a new build, live in about a minute. If your live prompt ends with Guuey’s grounding note (the create wizard adds one), the note stays on the end of the new prompt. While a build is still deploying, saving waits until it is live. The box under it, For signed-in users, works the same way for a signed-in override — a full replacement of the base prompt for authenticated sessions; leave it empty to drop the override. The model still comes from the brief you created the agent with; to change it, pull the agent with guuey pull --app-id <id>, edit guuey.json, and run guuey deploy (see the CLI guide) — the same round-trip also edits the prompt, in prompts/system.md. You can also declare the agent in a guuey.json and run guuey agent apply (Agents as code). The Console keeps monitoring, keys, and billing for it either way.

Deployed from code — sectioned configuration for how the agent thinks:

• System prompt — the live prompt comes from your agent’s own code: agent.systemPrompt in guuey.json, inline or as a file path (see Agents as code). The Console edits your draft, with a For signed-in users twin: the connect guide carries the draft to your agent until its first code deploy. After that the deployed snapshot is the live prompt, and editing the draft never changes a running agent.
• Model — the per-app BYOK keys are live: add an Anthropic, OpenAI, or Google key (the CLI’s guuey byok set also accepts OpenRouter). Choosing the model itself from the Console is marked coming soon — the model comes from your guuey.json.
• Generation, Tool use, Guardrails — labelled coming soon, with the honest current state spelled out in each panel: every allowed tool runs automatically (the allowlist is the control), and Guuey adds no content-safety pass of its own — your model provider’s safety layer and your system prompt are what apply.

Users

Who may talk to the agent, and who has:

• Authentication — three modes: Anonymous, Guuey sign-in, or Bring Your Own Auth (your Auth0/Clerk/Firebase/any-OIDC issuer URL and audience; Guuey verifies your users’ tokens against your provider’s published keys, and shows the redirect URI to register at your IdP). See Sign-in on the agent’s page and Sign in your own users for how each mode reaches your users.
• Directory — the real end users who have talked to this agent, aggregated from sessions.

Deployments

The active build sits on top, the full deploy history below. Each build walks queued → building → pushing → deploying → live; older builds become superseded, and failures say failed.

• Redeploy re-runs your most recent deploy server-side — it needs at least one prior deploy, and the button explains itself when disabled (no prior build, or a deploy already in flight).
• Runtime size is chosen on the deploy — guuey deploy --size sm — not in the Console yet.
• Click a build for its detail page: an Overview tab and the build’s Env vars; Logs, Artifacts, and Diff tabs are marked “soon” right in the tab strip.

Sessions, Logs, Memory

• Sessions — every conversation, with summary stats (including error rate), filters by status, identified vs anonymous, and date range. Click a session for its event timeline.
• Logs — live output from the running agent: pick a time range, search, and auto-follow the tail.
• Memory — not in the sidebar: reach it at /apps/<app-id>/memory, or from a session’s thread-id link. It lists the agent’s signed-in end users and, under them, Conversations: every stored conversation, anonymous widget visitors included, newest first, filtered to one user when you pick one. Each row opens the full transcript. What the agent actually remembers is described in State & memory.

Agent Settings

Sectioned like the rest of the Console; the sidebar shows only sections that apply to the agent’s hosting mode:

• General — name, description, default shell, welcome prompt, plus Branding and the Standalone page policy (covered in Design & distribution).
• Deployment — the app’s pod-count limit (live — the runtime converges the running deployment onto it, up to your plan’s ceiling; see Plans & billing) and its environment variables. Runtime size stays a deploy-time flag for now.
• Tools — the browser origins allowed to call your agent’s endpoint. It’s the same list the embed reads, but with two readers: the endpoint’s CORS check treats a bare domain as covering its subdomains, while the widget’s frame check matches it to the apex only — see Allow your site’s domain.
• App ID — the agent’s public identifier, the one you pass to the SDK.
• Adapters — capability labels on the app today; they don’t grant or block device access.
• LLM, Data ownership, Source, Integrations, Webhooks — coming-soon panels, each stating what to use instead today (BYOK lives under Behavior → Model; there is no webhook dispatcher yet, so poll Sessions or read thread history through the SDK).
• Danger zone — transfer the agent to a workspace, or delete it. Deletion stops serving and is reversible for 30 days: the settings page grows a restore card with the deadline, and only after that window is it permanent. Workspace apps: only admins can delete.