Workflow templates explained

A workflow template is a declarative specification of a finance task: what data to read, what the agent does with it, what shape the output takes.

Templates are not scripts. They do not execute line by line. The planner reads a template, sequences the required tool calls, gathers intermediate state, and decides at each step whether to continue, raise a flag, or halt for review. The template specifies the intent; the planner handles execution.

The three parts of a template

Every Yig workflow template has three parts: input shape, tool sequence, output shape.

Input shape. The data sources and parameters the workflow requires. The template will not start if the required inputs are not available.

Tool sequence. An ordered declaration of the tools the agent calls to produce the output. Each tool has a typed contract. If a tool fails, the planner does not silently skip it — it halts and records the failure.

Output shape. The structure of the draft the template produces. The output shape is fixed and typed, so the reviewer knows exactly what to look for.

A worked example: gl_recon

A template is a contract that names its inputs, its tool sequence, and its output shape. The worked example shows all three.

Here is how the GL reconciliation template renders for ACME US Q2 2026.

gl_recon · v3.1
─────────────────────────────────────────────────────────────
INPUT SHAPE
  entity          : "ACME US"
  period          : "2026-Q2"
  primary_source  : connector ref to ERP system of record
  compare_source  : connector ref to data warehouse mirror
  tolerance_pct   : 0.5
  output_dest     : close folder · Q2-2026

TOOL SEQUENCE
  1. ledger-read    · scope = (entity, period, primary_source)
  2. ledger-read    · scope = (entity, period, compare_source)
  3. ledger-compare · primary, compare, tolerance_pct
  4. flag-classify  · differences → [timing, fx, rounding, unknown]
  5. draft-build    · matched, differences, flags

OUTPUT SHAPE
  summary         : line counts (compared, matched, differing)
  matched_table   : collapsed by default · expandable
  differences     : line_id · primary_amt · compare_amt · delta · candidate
  flags           : line_id · reason · what the reviewer needs to decide

A reviewer who has read the template knows which tool produced which row in the draft. A reviewer who has not can still predict the output shape.

How the planner executes a template

A script executes line by line. A declarative template is different: the planner reads the intent, sees the data, and decides which tools to call in which order, halting at the first step where it lacks what it needs.

The planner’s job is to get from the input shape to the output shape. At each step it checks whether it has the data it needs. If it does, it calls the next tool. If it does not — missing, ambiguous, or out of range — it raises a yellow flag and pauses.

The planner does not guess. If a tool returns a result that contradicts an earlier result, the planner surfaces the contradiction rather than resolving it silently. Contradictions are the work.

Templates and the yellow flag

Every template has a set of decision points where the planner cannot proceed without human input. These are declared in the template, not discovered at runtime.

A GL reconciliation template declares that if two sources differ by more than a configurable tolerance, the planner halts and flags the differing lines. The reviewer sees the lines, the amounts, and a plain-language explanation. The reviewer makes the call; the planner continues.

The template’s behaviour under edge cases is predictable. The planner will not make assumptions to get through a flagged step. It always asks.

The same template on three surfaces

One declaration, rendered by each surface. A Yig workflow does not have a Slack version, an Excel version, and a CLI version.

Step	Slack	Excel sidebar	CLI
Invocation	@yig-thinker run gl_recon for ACME US Q2 2026	Sidebar button, entity + period pre-filled	yig thinker run gl_recon --period Q2-2026 --entity "ACME US"
Status updates	Inline thread messages per tool	Progress strip at the top of the sidebar	One → line per tool, with elapsed time
Draft presentation	Structured message · summary · flags · action buttons	Sidebar table; clicking a row scrolls the workbook to it	Formatted block · summary · flags · reviewer prompt
Reviewer action	Reply in thread or click buttons	Cell edits staged as diffs before write-back	accept / reject / comment at the prompt

The agent, the audit log, the reviewer gate are identical across all three. The chrome is the only difference.

Template chaining

Templates compose. The output of one is the input of the next, and the audit trail threads through the chain.

Templates can be chained. The output of one template becomes the input of the next.

A monthly close chain might look like this:

gl_recon → variance-review → management-pack

gl_recon produces a reconciled GL with line-level differences resolved. That reconciled GL becomes the primary input to variance-review, which compares the current period against prior periods and produces a variance schedule with material lines flagged. The variance schedule then feeds management-pack, which assembles the executive summary, key variances, and narrative.

Each step is approved separately before the next runs. The reviewer of gl_recon may not be the reviewer of variance-review. Each approval is its own record in the audit log.

Chaining is declared in a routing rule, not hardcoded. The finance team decides which templates chain and under what conditions. A material variance triggers risk-review; an immaterial one skips it.

Reading the output of a template

Every template output is structured and typed. The reviewer sees the same shape every cycle, regardless of what the data contained. What changes is the content — the amounts, the flags, the narrative paragraphs.

This predictability is deliberate. A reviewer who has read twelve months of variance-review outputs knows where to look for material lines, where the flags appear, and what the narrative structure means. Familiarity accelerates review without reducing rigour.

The output also carries provenance. Every cell or paragraph is traceable to a specific tool call and data source. The reviewer can ask “where does this number come from?” and get a traceable answer.

What templates do not contain

Templates do not contain prompts, model instructions, or tool implementations. They are declarative specifications, not executable code.

This is intentional. A template a finance professional can read — without understanding the agent runtime — is a template they can audit, review, and approve before deployment. Templates that embed implementation details are not auditable by the people who need to approve them.

The template is the auditable surface of the agent. Everything the agent does inside a workflow is determined by the template; everything outside the template is not the agent’s work. The bet is that the operator who can read the template can defend the agent’s actions to an auditor — and an agent whose work cannot be reduced to a readable template has no business inside a close.