Agents & workflows

An agent in Fosnie can do things – edit a document, generate an artefact, run code, post a message – not just answer. Agent runs are durable, gated, and fully audited.

How an agent run works

A run moves through clear states: running → (awaiting approval → approved | rejected) → completed | failed | cancelled, bounded by step and token budgets and cancellable at any point.

Tools split into two classes:

• Read-only and artefact tools run without interruption.
• State-changing or egress tools (editing a document, using a connector, a destructive action) pause the run for human approval.

When a run pauses, the exact pending action is saved. Approve and the approved call runs verbatim – it is never re-inferred. Reject and the run ends without the action. Approvals appear as an in-chat card and in a durable pending-approval inbox, so unattended runs wait safely.

An agent always acts as a real user (the person who started it or the workflow's owner), with that person's permissions – never as an anonymous "system". If a process crashes or you redeploy mid-run, the run resumes from its last checkpoint without losing or repeating an action.

Workflows (event-driven automations)

Workflows are the third way to fire an agent, alongside interactive chat and scheduled runs. They're off by default (features.workflows) and entirely internal – no inbound webhooks, in keeping with zero-egress.

A workflow reads: WHEN <trigger> [IF <condition>] THEN <action>.

• Trigger – an internal event (a document ingested, a chat member added, a user provisioned) or a schedule. The trigger list comes straight from the backend, so it can't drift.
• Condition – a safe structured filter (field op value, AND/OR). No arbitrary code.
• Action – either an agent_run (runs an agent) or a deterministic system_action (post a message, add a label, create a note, notify).

Additive, reversible actions (draft, artefact, note, label, proposed tracked changes) run unattended; destructive or external actions (delete, send, sign, activate a connector) are gated for approval. Output always lands somewhere a human can review it.

Setting one up

An admin enables workflows in Admin → Config (no restart). Authoring needs the workflows.manage permission – admins use the Admin console's Workflows section, power-users the Workflows tab on their team screen. Workflows are created disabled and run as their owner (bounded by that owner's access). Loop guards – depth caps, cycle detection, per-workflow budgets, a coalescing window, and a global pause-all switch – keep automations from running away.