SMELT

Execution & Monitoring

When you run a workflow, SMELT executes blocks in dependency order with real-time status updates streamed to your browser via SSE. Every run is recorded for later inspection.

Running a workflow

The toolbar’s primary control starts the run, and its wording follows the trigger the workflow carries. A manual trigger shows Run. A schedule shows Run now, which runs it once without touching the schedule. A webhook or chat trigger shows Test, which sends your sample body through the real trigger so you see what an actual caller would get.

Workflows that wait on an outside event have no start button at all. Gmail, Slack, GitHub and form triggers fire when their event arrives, and the toolbar says so instead of offering a control that would not represent a real run. To fire a form workflow, open its form URL from the trigger settings.

Once started, SMELT validates the workflow graph, resolves block dependencies, and begins execution.

Blocks with no upstream dependencies start immediately. Downstream blocks begin as soon as their inputs are available. Parallel branches are dispatched together rather than one after another.

Dispatched together is not the same as finished together. Agent work runs on a fixed pool of workers, one task at a time per agent type, so branches that need the same kind of agent queue behind each other. A wide fan-out of research steps takes about as long as running them in order; a fan-out across different agent types does not.

Block status indicators

Each block on the canvas shows a colour-coded status ring during execution:

  • Grey - pending. Waiting for upstream blocks to complete.
  • Amber - running. The block is actively processing.
  • Amber - awaiting approval. An approval gate is waiting for human input. The ring is the same amber a running block uses; the trace panel and the block’s Output tab tell the two apart.
  • Green - completed. Click the block to inspect its output.
  • Red - failed. Click to see the error message and stack trace.

Agent tool-call limits

An agent that uses tools works in turns. It calls a tool, reads the result, then decides what to do next. Each agent step gets a fixed budget of turns so a stuck agent cannot loop forever.

If an agent spends its whole budget without reaching an answer, the step fails and names the limit it reached. Its half-finished working notes are discarded rather than passed to the next block, because a truncated answer that looks complete is worse than a clear failure.

If you hit this limit, give the agent a narrower task or attach fewer tools, so it can finish in fewer turns.

Trace panel

Toggle the trace panel from the toolbar. It shows a chronological event log for the current run:

  • Each event includes a timestamp, block name, event type (started, completed, failed, approval_waiting), and duration.
  • Click any event to highlight the corresponding block on the canvas and scroll it into view.
  • Delegated sub-agent calls report the credits they used, so you can see which part of a run spent the most.

The trace persists after execution completes. Switch between runs using the run selector dropdown.

Live counters

The toolbar displays two counters during execution, updated in real time:

  • Duration - wall-clock time since execution started.
  • Credits - credits used by this run so far. BYOK calls are billed by your own provider and use no credits.

Cost is shown in credits rather than tokens, because credits are what your allowance is measured in. See Billing & Limits.

Run history

Every execution is stored and accessible from the workflow view. The history table shows status, duration, credits, and timestamp for each run.

Click any past run to replay its trace, inspect block outputs, and compare results across runs.

Runs are kept for 30 days. After that they are deleted, along with their inputs, block outputs, and error messages. Your monthly usage and credit totals are held separately and are not affected, so billing history stays intact. If you need a run to outlive the window, have the workflow write the result somewhere you control.

Approval gates during execution

If a workflow contains an approval gate, execution pauses at that block until a team member approves or rejects. The block shows an amber status ring and the trace panel logs an approval_waiting event.

Approve or reject from either the Pending approvals list on your Studio dashboard or the Output tab of the inspector, reached by clicking the amber gate block. The trace panel records the wait but carries no buttons. A rejected gate stops execution and the run is recorded as cancelled, not failed.

Next steps