Concepts

Runyard is a self-hosted control plane for agent runs. You install workflows into a catalog, start runs from the web app, CLI, HTTP API, MCP, ACP, a schedule, a hook, or a workflow endpoint, and runners claim and execute them. The durable company asks those runs work on are Factory Items: tickets on the Work/Factory board. Anything that needs a human decision surfaces as an approval decision, sensitive values live in the encrypted secrets store, and optional side effects after a run are handled by admin-defined hooks or response endpoints. Access is governed by scoped tokens, and every page in the Hub is a shareable deep link.

The catalog

• Workflows — the unit of the catalog: a named, versioned definition with input/output schemas whose source lives as immutable bundles in the Hub database.
• Agents, skills & knowledge — shared, reusable building blocks (agent roles, skills, knowledge resources) that workflows reference.

Execution

• Runs — a single stable run identity with lifecycle statuses, preflight and run drafts, immutable attempts, events, logs, artifacts, retries, recovery, reruns, usage, and promotion.
• Factory Items — tickets on the Work/Factory board: the durable unit of company work that runs attach to, with a human-legible kanban lifecycle and a per-run execution flow view.
• Factory operating model — how signal becomes a ticket, product decisions revise in place, Ready launches workflows, runs move cards, and shipped work is accepted.
• Runners — the machines that claim queued runs and execute them via the Smithers engine, with tags, capacity, and optional sandboxing.
• Schedules — cron or one-shot triggers that create ordinary runs on a cadence.

Control

• Decisions — declared human decisions: approval cards with an explicit ask, per-kind consequences, optional timers with fallbacks, and web or Telegram resolution paths.
• Hooks — admin-defined post-run side effects (publish, push, webhook) that run after a run's gates pass and never fail a green run.

Platform

• Tokens & scopes — bearer-token auth with the api, mcp, runner, approvals, and admin scopes; browser sessions carry exactly a token's scopes.
• Secrets — an encrypted store whose values are only ever decrypted into a run's child process environment, never returned by the API.
• Deep links — the shareable URL grammar of the Hub web app, plus the deep links the API returns in its payloads.
• CI, usage, and updates — repository checks and dispatch, metered run usage and budgets, audit history, and self-update/release checks are Hub surfaces backed by the same API registry.