"You can build anything on Tinbox" is only a useful promise if you can tell which thing to reach for. There are six lanes. Each is the buyer-facing projection of the platform's four primitives (a Connection is a credential, a Skill is a capability, a Surface is where UI renders, a Plugin is the package that ships them) — the lanes are how you'd describe the job, the primitives are how it's built.

Everything below is code or config you deploy to your own Worker, in your own Cloudflare account. There is no runtime code upload and no drag-and-drop builder — extending Tinbox means writing TypeScript and shipping it, reviewable in a PR.

The six lanes

Lane	Build a…	Mechanism	Ships?
1. Parsers	ingest rule, message widget, field extractor	reactive Skills (`defineSkill`) + the in-app skill-draft playground	Shipped
2. Replies	reply rule, auto-response, drip follow-up	Handbook (org policy) → Agents (inbox-bound) → thread directives (per-send)	Shipped
3. Scripts	ad-hoc mailer, sync job, importer	`tinbox/sdk` (send + typed tRPC) + CLI + `/mcp`, one `tbx_` token	Shipped
4. Plugins	webhook, cron, custom route, private tables	`definePlugin` — routes / scheduled / onEmail / onSend / onSent / `ctx.db` / secrets	Shipped
5. Views	dashboard tile, agent tool, custom card	`plugin.ui` slots (config-registered components) + `plugin.agentTools`	Shipped (config)
6. Agents	sourcing skill, campaign agent	agentic Skills on the outreach seam + the per-inbox agent	Shipped

Which lane do I use for X?

Mail arrives — you want to tag / classify / extract / render a card    → 1. Parsers
Mail arrives — you want to draft or send a reply, now or later         → 2. Replies
Your OTHER app needs to send mail, sync data, or import a list         → 3. Scripts
You need a webhook in, a cron, a custom route, or private tables       → 4. Plugins
You want a dashboard tile, a custom card, or a NEW agent tool          → 5. Views
You want an agent that sources people or runs an outreach campaign     → 6. Agents

Finer cuts within a lane:

Tag vs act on inbound mail. Annotating a message reversibly (tags, flags, a category, a proposed draft, a card) is a Parser (lane 1, a reactive Skill). Acting with side-effects on every inbound mail (write to a CRM, open a ticket) is a Plugin onEmail hook (lane 4). Just POST the raw event somewhere? Use a built-in webhook — no code. A reactive skill's model-time helper may fetch only to read data needed for its verdict; it must not cause a side effect. If a person or agent deliberately invokes the operation, use an agentic/command skill with its approval policy instead.
Who pulls the trigger? A capability the assistant calls is an agent tool (lane 5's data side — plugin.agentTools). A capability a person clicks is a command Skill (lane 2). A step that runs on every mail unconditionally is a Plugin hook (lane 4).
Reply now vs a policy. A one-off "when they reply, draft an answer" rides on the send itself — a thread directive (lane 2). A standing rule for how the whole inbox behaves is the Handbook (lane 2). An inbox that acts on its own is an Agent (lane 2 for inbox replies; lane 6 for outreach).

Two scenes that ship today

A 15-line ad-hoc mailer (lane 3). Your Tinbox audience × your store's data × a per-recipient template, sent idempotently — no platform UI, just the SDK:

import { Tinbox } from "tinbox/sdk";
const tb = new Tinbox({ host: "https://acme.dev", apiKey: process.env.TINBOX_API_KEY });

const { members } = await tb.api.audiences.members.query({ audienceId: "aud_weekly" });

await tb.emails.batch(members.map((m) => ({
  from: "Acme &#x3C;news@acme.dev>",
  to: m.email,
  subject: "Your weekly digest",
  template: "weekly-digest",              // a template you stored, rendered server-side
  data: { FNAME: m.name, TOP_PICK: m.topPick },
  idempotencyKey: `DIGEST-${weekId}-${m.email}`,
})));

An agent-authored parser (lane 1). In Settings → Skills → Playground, paste a real email, describe what to pull out, and watch the skill extract fields live before you activate it — the "agentic-built UI inside the app," scoped to mail classification. No redeploy; the draft is a structured spec, not uploaded code.

What's deploy-time vs runtime

Runtime, no redeploy: autopilot on/off + its brief + tool list, enabling an agent, secrets, model choice, the skill-draft playground, and which surfaces a token may reach.
Deploy-time (a commit you own): a new Parser, a Plugin, an agent tool, a plugin.ui surface, a custom card component. The set of things your inbox can do is a property of your repo.

Read the per-lane page for a complete, copyable example. If you'd rather not write the code, we'll build your extensions for you.