Connecting Yig Thinker to Slack

Yig Thinker’s Slack integration is a surface, not a product. It presents the same agent and the same workflows that are available from the CLI — in the place where the finance team’s conversations already happen.

The reviewer does not open a new tool to review a draft. The draft comes to them, in the thread where the work is being discussed, and they respond in that thread.

How the Slack surface works

A dashboard-with-Slack-notifications treats Slack as a notification channel. The work lives in the dashboard; Slack announces that something happened and links back. A Slack-as-seat-of-work architecture inverts this. The Slack DM is where the controller asks for the reconciliation, sees the draft, and approves it. The thread holds the audit history of the close. Yig’s Slack integration is the second. The principle is set out in the surface contract: Slack is not where the agent reports out, it is where the agent works.

The Slack integration connects to a workspace via an incoming webhook and an app bot. When a user messages @yig-thinker in an authorised channel, the message is routed to the agent at L2. The agent processes the invocation — running the requested workflow, producing a draft, or responding to a review action — and posts the result back to the originating thread. The entire review cycle happens in the thread.

A run from invocation to approval

A Yig run lives in a Slack thread from invocation to approval. The thread is the record.

Day 4 of March close, the controller for ACME US opens #fin-close and types:

@yig-thinker run gl_recon for ACME US Q2 2026

The agent acknowledges in-thread within a second and begins the workflow. As each step completes, the agent posts a status update — reading source, reading comparison, running comparator. When the draft is ready, the agent posts a structured message in the thread:

@yig-thinker · gl_recon · ACME US · 2026-Q2
─────────────────────────────────────────
1,244 lines compared · 1,241 matched · 3 differences · 3 flagged

Differences:
  • Line 412 · accrual not posted · $42,100 (candidate: timing)
  • Line 718 · FX rate mismatch  · $14,200 (candidate: rounding)
  • Line 904 · missing in WH      · $128,000 (candidate: unknown)

Flags requiring judgment:
  ⚑ Line 904 — large variance with no counterpart
  ⚑ Line 718 — FX delta exceeds the 0.5% band
  ⚑ Line 412 — accrual outside expected calendar

[Accept all candidate explanations]  [Reject]  [Reply per line]

The controller replies to flag 412 first — “Cleared 2026-04-02 post-period accrual; not adjusting.” The agent records the resolution. For 718 the controller types “Reprice at month-end closing rate”, and the agent updates the candidate. For 904 the controller pulls up the GL, finds the entry was misposted to a sister entity, and comments “Misposted to DE-001; reclass next cycle.”

The controller clicks [Accept all candidate explanations]. The approval record is written. The draft ships to the Q2-2026 close folder. The whole flow — from invocation to approval — lives in one thread. A reviewer picking up the close mid-cycle reads the thread top-to-bottom and knows the state.

For longer drafts — a full management pack — the agent posts a summary in the thread and a link to the full draft in the configured document destination.

What the reviewer sees in Slack

A Slack draft is structured so the reviewer can act on it inside Slack — no second app, no second context.

The draft message in Slack contains:

• A summary of the workflow result — what was produced, how many lines, headline numbers.
• The differences or flags that require reviewer action — displayed as a numbered list in the thread.
• For each flagged item: the agent’s plain-language explanation of why it was flagged and what the reviewer needs to provide.
• Action buttons or reply instructions: how to accept, reject, or comment on each item.

The reviewer replies in the thread. Each reply is recorded in the audit log as a reviewer action with the Slack user identity, timestamp, and the specific draft item it applies to.

The reviewer identity

Slack identity becomes Yig reviewer authority only when the operator has mapped one to the other. Before a user can approve an output via Slack, the operator must have authorised that Slack user as a reviewer for the relevant workflow.

An unauthorised user who responds to a draft in Slack will receive a message indicating they are not authorised to approve this workflow. Their response is not recorded as an approval. It does not block the draft — it simply has no effect on the gate.

This mapping is configured by the operator in the Slack app settings, not per-thread. The authorisation check is applied every time a reviewer action is submitted, not only at initial setup.

Slack actions and their audit records

Every Slack interaction that touches a draft produces an audit record. Slack is not a notification surface; it is a transactional one.

Every Slack interaction produces an audit record. Each action has a specific shape:

Slack action	What gets recorded in the audit log
DM invocation (@yig-thinker run ...)	Run record: invoking Slack user, channel ID, timestamp, workflow + scope parsed from the message
Channel mention with reply thread	Same as DM invocation, plus parent thread anchor for the run trail
Thread reply with reviewer comment	Reviewer action record: action type (comment, flag-resolve, accept-with-edits), reviewer identity, target line or flag, comment text
Button click (Accept / Reject / Resolve)	Reviewer action record: action type (accept, reject, flag-resolve), target draft version, reviewer identity, timestamp

The audit log does not record the full text of Slack messages outside of structured reviewer actions. It records that a specific authorised reviewer approved a specific draft at a specific time, plus any free-text comment they attached to the action.

What the Slack surface cannot do

The Slack surface shares the same gate as every other surface. A reviewer cannot approve a draft via Slack without being authorised for that workflow. A workflow cannot skip the review gate because it was invoked from Slack.

The Slack surface also cannot be used to install or modify workflows, change reviewer authorisations, or access the audit log. Those are operator-level actions, available via the CLI or the deployment configuration. The surface exposes workflow invocation and review — not configuration.

Latency and availability

Connectivity interruptions do not relax the reviewer gate. Slack delivery depends on the Slack API and the Yig deployment’s network availability. If the agent runtime is unreachable — because the deployment is offline or the network is interrupted — the invocation will fail and the user will see an error message in Slack.

Drafts produced before a connectivity interruption remain in the agent’s staging area and can be retrieved once connectivity is restored. A draft that was produced but not approved before an interruption does not auto-approve.