What shipped.

Workflow runs now actually execute. When a workflow is triggered, the execution engine performs a topological sort of steps, evaluates condition expressions against prior step outputs, builds agent tasks by resolving input_mapping references, and calls each agent via the orchestrator in order. Step results are written back to the workflow_runs row in real time — the UI polls and shows per-step progress.

Six pre-built workflow templates are now available on the Workflows page: Invoice Approval Pipeline, Contract Review & Sign-off, Vendor Onboarding, Monthly Financial Report, New Hire Onboarding, and Sales Deal Qualification. Each template has pre-wired steps, input mappings, and condition guards. Clicking a template card provisions the workflow and drops you directly into the canvas editor.

A persistent topbar now appears across all dashboard pages. It includes a system status indicator and a real-time notification bell that pulls from three sources: pending triage items, failed agent runs, and incoming cross-org delegations. Notifications update via Supabase realtime subscriptions — no polling. Unread count persists in localStorage between sessions.

The API Playground now covers all endpoint groups including the new Workflows API. Endpoint picker is grouped by category (Health, Agent Runs, Triage, Batch, Workflows, Audit). Path parameter inputs auto-populate from selected endpoints. Response panel shows status code, latency, and formatted JSON with a one-click copy.

A Postgres RPC function increments the workflow run_count and updates last_run_at atomically on completion. This avoids a read-modify-write race for high-frequency workflow triggers. The function is SECURITY DEFINER so it works correctly across RLS boundaries.

Chain agents with a drag-and-drop canvas. Each node is a discrete agent type; edges carry the output of one agent as the input of the next. Conditional branching is supported — a node can fan out to different downstream agents based on a runtime predicate. Workflows are saved as JSON and versioned per organisation.

Canvas edges render as smooth SVG bezier curves with directional arrow markers. Branch conditions are displayed inline on the edge label so the logic is readable at a glance without opening a properties panel. True / false branches render in distinct colours.

Workflow runs now stream status updates to the client in real time over SSE. Each agent node emits started, completed, and failed events as it executes. The canvas animates the active edge live — you watch the execution path traverse the graph as it happens.

New /workflows endpoints cover: create, read, update, delete, list, trigger a run, and retrieve run history per workflow. The run trigger endpoint accepts an optional input payload that overrides the workflow's default input. All endpoints are authenticated with the standard API key header.

Clients can subscribe to a run-scoped SSE stream at GET /v1/runs/:runId/stream. Events include node_started, node_completed, node_failed, and run_finished. Each event carries the node ID, timestamp, and a data payload appropriate to the event type. The stream closes automatically when the run reaches a terminal state.

The @eclips/sdk now exports a useRunStream React hook. Pass a runId and receive a live state object containing the current node, elapsed time, and per-node status map. The hook handles SSE connection lifecycle, reconnect on drop, and cleanup on unmount — no manual EventSource management required.

A dedicated email templates package ships five production-ready HTML templates: triage alert, team invitation, run-complete notification, usage warning, and welcome email. Each template is responsive, dark-mode compatible, and includes variable slots for org name, agent name, amounts, and deep-link URLs. Templates are rendered server-side and sent via SendGrid.

The eClips API Postman collection is now published and complete. It covers 20 requests organised into 7 folders: Authentication, Agents, Workflows, Runs, Organisations, Billing, and Webhooks. Each request includes example payloads, expected responses, and environment variable references for base URL and API key.

Enterprise plan organisations can now configure Single Sign-On directly from the Settings > Security screen. Both SAML 2.0 and OIDC flows are supported. Admins supply the IdP metadata URL (SAML) or issuer / client credentials (OIDC). Once saved, the organisation's login page redirects to the configured IdP. JIT provisioning is enabled by default.

Admins can invite team members by email from the Settings > Team screen. An invitation token is generated server-side, embedded in a branded invite email, and expires after 72 hours. Accepting the invite creates the user account (or links an existing account) and assigns the invited role. Pending invitations are listed and can be revoked before acceptance.

The audit log is now surfaced in the dashboard under Settings > Audit Log. Events are displayed in a chronological timeline with colour-coded badges by event category: auth events in blue, agent actions in orange, admin changes in purple, billing events in green. Each entry shows actor, timestamp, IP address, and a structured diff of the changed resource.

The official eClips n8n community node is published to npm as @eclips/n8n-nodes-eclips. It exposes four operations: Trigger Agent Run, Get Run Status, List Agents, and Stream Run Events. Authentication uses the standard API key credential type. The node is compatible with n8n 1.x self-hosted and n8n Cloud.

The eClips Make.com app is available for installation. It ships with 8 modules: Trigger Agent Run, Watch Run Stream, Get Run Result, List Agents, Create Workflow, Trigger Workflow, List Organisations, and Get Usage. OAuth 2.0 authentication is handled via Make's built-in connection flow.

Billing is now fully wired via Stripe. New organisations are directed to a Stripe Checkout session to select a plan. Existing subscribers can access the Stripe Customer Portal to update payment methods, upgrade or downgrade, and download invoices. Usage-based line items (agent runs over the plan limit) are reported to Stripe Billing via the usage records API on a nightly batch.

A new batch endpoint accepts up to 500 document rows in a single request and fans them out to agent workers with a concurrency ceiling of 10. Progress is tracked per item; partial failures do not abort the batch. Results are available via polling or webhook callback when the batch completes. Batch jobs appear in the run history with aggregate success / failure counts.

The @eclips/sdk package is published to npm. It wraps all API endpoints with full TypeScript types, including request bodies, response shapes, and a typed error class hierarchy: EClipsError (base), AuthenticationError, RateLimitError, ValidationError, AgentError, and WorkflowError. The SDK handles retries with exponential backoff on 429 and 5xx responses by default.

Circuit breakers are now backed by Supabase rather than in-memory state. This means all running API instances share a single circuit state — a tripped breaker on one pod is immediately visible to every other pod. Previously, a single slow downstream integration could trip one pod while other pods kept retrying it, creating thundering herd conditions.

Reach now runs a visual classifier against every screenshot before presenting an approval gate. The classifier checks for destructive UI patterns (delete dialogs, confirmation modals, irreversible action indicators) and upgrades the action risk tier accordingly — even if the DOM analysis missed it. This closes a class of edge cases where auto-save systems rendered form fields without explicit Save buttons.

The wakeup engine now covers 73 distinct trigger patterns — up from 20 in April. New contexts include: supplier payment term expiry, PO line-item quantity variance, contract renewal window detection, and approval queue age threshold. Each context can be independently enabled per organisation.

Adding a new agent type previously required modifying 4 files and registering in 2 separate configs. After the refactor, a new agent type is a single entry in the agent registry: `{ id, schema, handler, trustLevel }`. Existing agent types have been migrated. This unblocks rapid expansion of the agent library.

Enterprise customers can now define outcome contracts as custom SQL functions, executed via Supabase RPC with SECURITY DEFINER — meaning they run with the privileges of the defining role, not the calling session. This allows complex outcome logic (cross-table joins, materialised view reads) that would otherwise require application-layer assembly.

Agents no longer have a binary supervised / autonomous mode. They now operate on a trust scale of 1–5. Level 1 agents require human approval on all non-trivial actions. Each successful run contributes to a trust score. Once an agent accumulates enough successful runs within a scope, it is promoted to the next level — and the approval gates for that level are lifted. A streak of failures demotes the agent.

Trust state is stored in a new `agent_trust_profiles` table with per-org-per-agent granularity. This means the same agent type can be at Level 4 for Organisation A (high document volume, clean track record) and Level 1 for Organisation B (new account, no history). Trust does not transfer between organisations.

The new TrustDashboard (accessible under Observatory > Trust) shows every agent type in your organisation: current trust level, current streak, runs to next promotion, and a sparkline of approval rate over the last 30 days. Admins can manually override trust level (with an audit log entry) for agents that have passed internal review.

The AgentHarness wrapper now checks trust level before routing to the triage queue. Level 4 and Level 5 agents processing document types within their trained scope skip the triage gate entirely and go directly to execution. The audit log still records the bypass and the trust level that authorised it.

Reach ships as a production-ready browser automation layer for Workforce agents. The five tiers — Observe, Navigate, Fill, Submit, Destructive — gate actions based on side-effect severity. Tiers 1 and 2 are always safe. Tiers 3–5 require approval. The tier classification runs in the orchestrator wrapper, below the LLM context, so the model cannot misclassify an action to avoid an approval gate.

When Reach encounters a Tier 4 or Tier 5 action, it captures a full-page screenshot of the browser state at that moment and surfaces it in the approval gate UI. Approvers see exactly what the agent is about to do — not a text description of it. Approval and rejection are one click from the dashboard or a Slack notification.

Sessions are initialised with a declared scope (allowed domains and URL patterns). Playwright request interception blocks all navigation outside that scope at the network level — not the application level. Auto-save aware forms (Notion, Salesforce, modern ERPs) are detected by pattern matching against known auto-save selectors and DOM mutation observers, and Fill-level approval is applied before the first keystroke.

Every Reach session is visible in the Sessions tab: status, current action, screenshot, and approval queue. Approval requests can be acted on from the dashboard, from Slack (via the eClips Slack app), or from the mobile-responsive dashboard view. Sessions that sit in an approval queue for more than the configured timeout are automatically paused and flagged for review.

Agents can now be configured with outcome contracts — SQL-level assertions that must evaluate to true before an action is committed. Example: an invoice approval outcome contract might assert that the GL code exists in the chart of accounts and the vendor is on the approved supplier list. If the assertion fails, the action is rejected and the exception surfaces in the triage inbox.

Native BC connector supporting invoice posting, GL entry creation, vendor lookup, PO matching, and approval workflow submission. Authenticated via OAuth 2.0 client credentials. Rate limiting and retry logic built in.

XML-RPC and JSON-RPC connectors for Odoo 17. Supports: vendor bill creation, purchase order read, journal entry posting, partner lookup, and account.move state transitions. Tested against Odoo 16 and 17 Community and Enterprise.

Triage alerts, approval requests, and exception notifications now render with fully branded HTML email templates. Templates are per-organisation configurable. Variables include: agent name, document type, vendor, amount, confidence score, and a direct link to the approval gate.

The Context Book is a structured knowledge store per organisation. Upload SOPs, vendor lists, GL code mappings, approval hierarchies, and policy documents. Agents retrieve relevant Context Book sections at inference time using semantic search — the book is the difference between a generic extraction and one that knows your specific vendor taxonomy and business rules.

A dedicated vendor registry table allows pre-registering known vendors with their expected document patterns, typical amounts, and GL mappings. When an agent extracts an invoice from a registered vendor, the confidence score is boosted and the routing rule fires faster.

Two-column invoice layouts from certain legacy accounting software were being read left-to-right across both columns rather than column-by-column. Fixed by adding a layout analysis pass before line extraction. Accuracy on affected templates improved from 71% to 96%.