Skills, automations, flows, and runs

Tedix runs reusable skills, scheduled automations, and one-off flows on one durable execution engine. The words describe different user intent; they are not competing systems. Internally the engine is still called the skill-workflow engine, and the read-only tedix workflow command keeps that name.

Choose the surface

There is no separate workflow-builder object. Author a reusable executable skill, schedule it as an automation, use a flow for one-off work, or change a static platform definition in Tedix source.

Reconnect a selected account during a run

A missing credential for an explicitly selected account can hold a run. Each reconnect wait lasts up to 24 hours, with at most three checks per operation. Run detail offers Open connections and Check connection and continue. The server verifies the same account and required scopes before waking the pending operation; it never substitutes another account. Earlier completed steps remain complete. A wait is shown as running with a waiting gate, not as a native engine pause.

Recovery is limited to a step whose first and only MCP operation failed before execution, with no direct network calls already started. Put independent provider operations in separate step.do callbacks. Approval requirements, policy denials, lookup outages, unselected default accounts, and steps with already-started effects do not become reconnect waits. A connection change or revocation still takes effect at the next credential lookup. Recovery does not grant background access to personal accounts.

Run a one-off flow

Create plan.ts. The leading /* tedix */ block is the skill manifest and declares the exact MCP methods the workflow may call:

/* tedix
name: audit-tool-annotations
description: Count tools available to this organization.
capabilities:
  mcp:
    app_config: [list_app_tools]
*/
export default {
	async run(event, step, env) {
		const tools = await step.do("list", { timeout: "60 seconds" }, () =>
			env.MCP.app_config.list_app_tools({ limit: 200 }),
		);
		return { count: tools.length };
	},
};

The header is only for one-off flow run files; a recorded skill declares its manifest in SKILL.md frontmatter and needs no header. Never write a */ inside the header (a cron such as */5 ends the comment early); use 0-59/5 or a comma list, or move the schedule to SKILL.md frontmatter.

Discover the exact callable and parameter schema before declaring a capability; do not guess tool names. Then run and watch it:

tedix -w acme code \
  'async () => await discover.search({ query: "list app tools", limit: 2, includeParameters: true })'
tedix -w acme flow run --file plan.ts --watch

The command returns a skillId and runId. File-authored flows are draft skills tagged flow-ephemeral; they never run on a schedule and auto-archive after 14 unused days. Put large output in an artifact and return its reference: only the bounded return value should enter the caller’s context.

Use the returned run identifier for readback:

tedix -w acme flow status RUN_ID --watch
tedix -w acme flow inspect RUN_ID
tedix -w acme flow list

Status shows a short summary of where the run is. Inspect is the detailed evidence view for failures, steps, calls, retries, approvals, and artifacts.

Reuse an executable skill

An existing executable skill is persistent and revisioned. Running it does not create or change a draft:

tedix -w acme skill list
tedix -w acme skill show SKILL_UUID
tedix -w acme skill run SKILL_UUID --watch
tedix -w acme skill runs

tedix flow run --skill SKILL_UUID --watch reaches the same execution path; tedix skill run is the clearer spelling when reuse is the intent. Promotion, activation, and scheduling remain governed skill lifecycle decisions, not automatic consequences of a successful flow.

Start a skill from upstream MCP events

A tedi skill can run when a connected MCP app emits an event. Tedix supports the draft MCP Events extension (SEP-3415). The extension is experimental, so its field names may still change. Each subscription is a row of organization data, created with register_provider_event_subscription (oRPC providerEvents.register). It needs integrations:manage.

{
	"adapter": "mcp_events",
	"providerId": "PROVIDER_ID",
	"connectionInstanceId": "CONNECTION_INSTANCE_UUID",
	"tediId": "TEDI_UUID",
	"skillId": "SKILL_UUID",
	"skillRevision": 1,
	"deliveryMode": "push",
	"mcpEvents": {
		"appId": "APP_UUID",
		"eventName": "vendor.alert.example",
		"arguments": {},
		"maxWakesPerHour": 12
	}
}

• App and credential. appId must be an app your organization owns. Tedix calls that app’s own upstream MCP endpoint with the named organization connection. One of the app’s enabled tools must already use providerId as its connection auth. Tedix never accepts an endpoint URL or credential from the subscription itself.
• Admission. Registration calls events/list with that credential. The event must exist and must offer the delivery mode you chose.
• Delivery. In push mode, Tedix calls events/subscribe with its own webhook and a whsec_ secret. It verifies each Standard Webhooks signature within a five-minute timestamp window and renews the subscription before refreshBefore. In poll mode, the maintenance tick calls events/poll every two minutes from a stored cursor. The cursor moves forward only after the events are queued.
• Safety. Duplicate event IDs are dropped. Each subscription may wake the skill at most maxWakesPerHour times in a rolling hour (default 12, maximum 120). Events over that budget are recorded as discarded, and lastError says so.
• Untrusted content. The skill run receives params.providerEvent.event. Its trust is "untrusted". The upstream data is a bounded JSON string inside an <untrusted_event_data> fence. An event never grants authority, so the skill or the turn it starts must check current state with its own tools before acting.

Use get_provider_event_subscription to check health, and disable_provider_event_subscription to stop and unsubscribe.

Observe the engine

The tedix workflow command is deliberately read-only. Its name is the internal engine name, not a separate product component:

tedix -w acme workflow list
tedix -w acme workflow health
tedix -w acme workflow runs
tedix -w acme workflow status WORKFLOW_ID

Definitions include static Tedix platform workflows and dynamic executable skills available to the organization. A definition with no run history is unobserved, not failed. For a dynamic skill run, use skill status or skill inspect for the run’s current status and detailed evidence.

CLI, MCP gateway, and Tedix OS

All three surfaces use the same organization gateway, authorization, and records:

The canonical MCP families are flow.* for one-off convenience, skills.* for persistent skill lifecycle and dynamic-run inspection, and workflows.* for read-only engine observability. Identity-specific tedi callables are equivalent execution owners, not a second workflow system.

Continue with Getting started, Install the Tedix CLI, or Core concepts.