Capability 03 — Automate

Cross-system work that runs itself — safely

A workflow is a declaration, not a script. Each step names the capability it uses, whether it reads, reasons, writes, or waits for a person, and which guardrails it must clear before it proceeds.

Anatomy

Two templates, fully declared

These ship with the platform. Notice that every step declares its mode and its required guardrails — that declaration is what makes the workflow reviewable before it ever runs.

ReportingSchedule-triggered

Daily business briefing

A read-only, evidence-backed summary of material changes across approved business systems.

  1. RetrievereadData access, Privacy
  2. NormalizereasonData access
  3. AnalyzereasonModel input, Model output, Cost
  4. DeliverwriteAction, Privacy
AutomationEvent-triggered

Governed lead follow-up

Enriches an inquiry, recommends priority and ownership, obtains approval, and creates an employee task.

  1. EnrichreadData access, Privacy
  2. RecommendreasonModel input, Model output
  3. ApproveapprovalHuman approval
  4. AssignwriteAction
Classes of work

Not everything deserves the same scrutiny

A read-only report and a workflow that moves money should not clear the same bar. Declaring a class up front means the right controls apply automatically instead of being remembered.

QueryRead-only questions grounded in connected business data.
ReportingScheduled or requested reports and dashboards.
SynchronizationData movement and normalized state refresh.
AutomationCross-system business processes with governed actions.
NotificationInternal or external communication flows.
IncidentDetection, triage, escalation, and recovery flows.
Reliability

What happens when things go wrong

Automation that only works on the happy path isn't automation, it's a demo. This is the machinery that runs when a worker dies mid-job or a vendor times out.

Idempotency you can rely on

Each request is canonicalized and fingerprinted, then atomically claims an organization-scoped key. An identical request in flight returns the original execution identifier instead of running twice.

Crash recovery without duplicates

A failed execution leaves its claim leased until expiry. A later request reacquires the expired lease, increments the attempt, and keeps the original logical execution identifier.

Exact-step resumption

Encrypted checkpoints mean an approval that arrives hours later resumes at the precise step it paused on — using the configuration revision that was in force when the job was enqueued.

Categorized failure handling

Atomic worker leases, capped backoff, and dead-letter handling by category. Failures are audited as coarse categories, never as raw exception messages or vendor response bodies.

An honest limit: this design provides safe request replay and stable downstream keys. It does not claim universal exactly-once delivery — an external vendor must honor the idempotency key it is given, or a connector must reconcile that vendor's state, to prevent duplication after an ambiguous network failure.

Start with one process

Pick the process that eats the most hours

Most teams start with a single recurring workflow that spans two or three systems. Call us and we'll map it end to end — the steps, the approvals, and where it can safely run without you.