docs

A run is one user-turn → assistant-turn cycle on a deployed agent. Cancellation kills an in-flight run mid-stream. This doc covers the contract, the three surfaces (chat shell, API, webhook), the server-side lifecycle, and how cancellations show up in observability.

The versioning surface lets operators promote, canary, and roll back agent deployments without re-provisioning the underlying Fly machine. A stech deploy mints a new immutable version; channel pointers (stable / canary) decide which version takes traffic. Rollback is a row-update on the channel pointer, not a re-deploy — the previous version's machine keeps running and traffic flips back instantly.

A CLI source plugs a command-line binary into an agent the same way an MCP source plugs in a server. The runtime forks the binary at tool-use time and feeds stdout back to the model.

The knowledge platform turns org-curated text into retrievable context that agents can search at runtime. A customer-support bot that answers "how do I reset my SSO?" by looking up the org's onboarding guide is the canonical use; the dashboard is where humans see what got ingested, what got cited, and what didn't match.

stech init --template=<id> scaffolds a new agent project from a curated starter so a fresh user can get a working agent in one command instead of filling out TODO stubs from an empty agent.ts. Templates are static tarballs published to releases.stech.com on every CLI release tag, SHA-pinned in a manifest the CLI verifies before extracting.

The agent detail page's "test the agent" panel keeps history. Each chat is a named conversation, scoped per user, that you can switch between, rename, or delete. Replaces the old stateless prompt box where every turn started fresh.

Passwordless sign-in via a one-time link emailed to the user. Lives alongside the original email + password flow — both work, pick whichever you prefer per sign-in. No account migration; the same user can use either path interchangeably.

Add a member to your organization by sending them a link. The recipient clicks → previews the invite → accepts → lands inside the org. Works whether they already have a stech account or not.

Org-scoped, read-only view over every privileged action, every SCIM call, and every webhook delivery in your org. Three event sources, three tabs, one CSV export, one filter convention. Cursor-paginated, default 30-day window, RFC 4180 export.

Customers running agents in production need to answer three questions: is it working, how fast is it, how much is it spending. The observability surface is a read-side view over agent_messages — every assistant turn the runtime persisted — aggregated three ways: per-org, per-agent, and per-run.

Agent authors declare guardrails as an array of strings on defineAgent(). The platform parses them at deploy time, refuses unknown shapes with a 400, and enforces every parsed entry in both the dev runtime and the cloud runtime. A hosted deployment run that fires a guardrail terminates with a blocked:<kind> stop reason, a structured blocked envelope on the response, a row in the guardrail_violations audit table, an audit.flagged webhook, and a parallel agent_run.blocked webhook on the dedicated SIEM channel.

Per-org caps, soft / hard cap behavior, and Stripe overage billing for agent runs. The cost-control surface lives between the run-stream entry gate, the usage-aggregator worker, and the billing dashboard — three moving parts that share one rolled-up table.

Outbound HTTP notifications when something happens in your org — deployments, agent runs, SCIM identity changes, admin actions. Replaces polling: subscribe once and receive a signed POST per event. Stripe-shape signing, six-step exponential-backoff retry, auto-disable on sustained failure.

Every authenticated page in app/ renders the same chrome: NavBar with brand, ThemeToggle, UserMenu, and the persistent application sidebar. When you add a new authed route group, wrap it in <AppShell>.

This adapter adds three health reads to automatic company-agent answers. It is unconfigured by default. No credential, trust file, mount or infrastructure change is created by this source change. Ordinary automatic answers keep working without the diagnostic connection.

Company agents can consult selected entries from the existing organization knowledge store before answering a request. The workspace owner chooses the entries and approves their current revision for private answers or channel answers. This applies to generic agents, including Code Reviewer, as well as the bound Network Doctor profile.

Automatic requests use the existing Anthropic provider and organization key resolver (organization key, otherwise the configured platform key). Existing organization caps and token accounting and guardrail policies apply. The model is claude-sonnet-4-6. The server owns the tool list; no original native session or organization-wide MCP tools are loaded. Missing model credentials, a cap refusal or a policy block produce a failed request. These requests do not create hosted run history, guardrail audit rows or run webhooks.

Stech accepts Maestro Connect as an optional OIDC sign-in provider. Standalone password and magic-link accounts continue to work. A connected organization keeps its Stech ID, workspaces, local roles, billing and settings.

Settings → Connections belongs to the currently selected company. Owners and admins can install Slack, reconnect it, assign a published company agent to a channel, remove assignments and disconnect. Members can see connection metadata without credentials or management controls. Destination metadata is manager-only until verified channel membership is available, so private channel names are not exposed to other company members. A company can have multiple Slack workspaces; each workspace belongs to one company, including after disconnection. This release has no automatic workspace transfer.