all systems operationalv0.17.10
stech/

docs

how stech works. read the source on github.

// agent runtime
Agent runs — cancellation

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.

Agent versioning

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.

CLI tool sources

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.

Knowledge

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.

Agent starter templates

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.

// conversations & ui
Persisted conversations

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.

// identity & access
Magic-link sign-in

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.

Org invitations

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.

// observability & audit
Audit log

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.

Observability

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.

Policy and guardrails

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 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.

// billing
Billing and usage

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.

// integrations
Webhooks

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.

// patterns
App shell pattern

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

// missing something? open an issue at github.com/Art-of-Technology/stech.com/issues