Every step of your process, with its rule. And an engine that runs it end to end.
We model your process as an explicit state machine: each trigger evaluates conditions, decides which step to execute or skip, calls your core via API, and advances the state on its own. Every exception stops, notifies its owner and stays in the trace, with a reversal plan.
0
manual steps
in the orchestrated flow
1
record
per execution, with time and data
L1
by default
prepares and waits for a person
8
industries
same engine running
UNDER THE HOOD
Each step runs when the state allows it.
An automation that fires everything all the time is a time bomb. The engine evaluates the state, business conditions, and available data before executing each step — and shows you why it jumped, waited, or retried.
Sample event
The event comes in
Delivery registered as "delivered" on the driver portal, with complete POD: 3 compressed photos, signature, and "Received By". Inbound order type with linked source PO.
Valid state for transition
on_route → delivered is an allowed transition in the state machine
Preconditions met
Complete POD (photos + signature + recipient) → no missing evidence
Inbound branch detected
order has linked PO → auto-replenish stock to be executed
Idempotency verified
no prior execution with this delivery_id → safe to fire
Score
96/100
Verdict from Claude
Execute: replenish stock + close route + notify client. State → completed.
The event comes in
RCV policy activation: plate crossed against factory inventory OK, but the uploaded ID document failed AI validation (blurry photo, unreadable data).
Blocking step identified
document validation is a precondition of "call insurer API"
Condition not met
unreadable ID → do not advance to issuance, risk of invalid policy
Exception branch
incomplete user input → the system worked as designed
Automatic corrective action
pause flow + WhatsApp to policyholder requesting document re-upload
Score
48/100
Verdict from Claude
Do not advance. Pause at "pending docs", notify policyholder, retry upon receiving valid document.
The event comes in
Webhook to insurer API to issue policy number returned HTTP 503. This is the second failed attempt in 90 seconds. Rest of the flow already validated and approved.
Transient failure, not data error
503 from supplier → retryable, payload is correct
Backoff policy applied
attempts 1-2 failed → third attempt in 4 min with exponential backoff
Escalation threshold
if 3rd attempt fails → no more blind retries, escalate to human
State preserved
flow frozen at "pending issuance", zero context loss
Score
35/100
Verdict from Claude
Retry with backoff. If 3rd fails: alert operations + manual reprocessing queue, without losing the case.
WHAT THE ENGINE DOES IN YOUR PROCESS
Five jobs your team should no longer trigger manually
Each one runs on every event that enters your process, with its rule and its trace. Your team receives results and exceptions, not operational tasks.
flow.trigger(event)
Starts the process only when what matters happens
Postgres trigger, incoming webhook, or state change. The raw event enters and the engine decides whether to start a flow, which one, and with what context — without anyone pressing a button.
› input
event: orders.status → "delivered" (Postgres trigger)
› claude →
event: delivery.completed
chosen flow: post-delivery-inbound
context: order_id, po_id, client_id
idempotency: unique key registered
→ state machine: started
flow.route(state)
Decides which branch runs based on the real state
It does not execute a rigid sequence. It evaluates the state and business conditions to choose the correct branch: advance, skip an unnecessary step, or enter an exception.
› input
state: policy · document validation = FAIL
› claude →
transition evaluated: validate → issue
condition: readable document = false
decision: DO NOT advance to issuance
branch: "pending docs" exception
→ controlled pause + notify policyholder
flow.transform(payload)
Cleans, maps, and normalizes between systems that don't talk to each other
Your core, your ERP, and the third-party API expect different formats. The engine maps fields, normalizes currencies and phone numbers, matches SKUs, and leaves the payload ready for the next step.
› input
payload: supplier invoice (PDF) → purchase order
› claude →
PDF parsing: 14 lines extracted
SKU match: 12 exact · 2 fuzzy ≥0.6
normalize: USD→DOP @ current rate
+58 tel normalized · RIF validated
→ payload ready for ERP API
flow.retry(step)
Survives the API going down without losing the case
Distinguishes transient failure from data error. Retries with exponential backoff, respects idempotency to avoid duplicates, and escalates to human only when the policy is exhausted — never loses context.
› input
step: issue policy → HTTP 503 (attempt 2/3)
› claude →
classification: transient failure
policy: exponential backoff
next attempt: in 4 min
idempotency: no duplicate issuance
→ if 3rd fails: reprocessing queue + alert
flow.notify(channel)
Alerts the right person, through the right channel
Step closure, exception, or escalation. Fires real-time in-app notification, opt-in Resend email, or WhatsApp template with variables — to the correct role, not a group of everyone.
› input
event: opportunity → "won" (energy CRM)
› claude →
action: automatically create project
realtime notif: project team
Resend email: commercial manager (opt-in)
revenue date: registered
→ project ready at "Order" step
LIVE SYSTEM · Grupo Latitud
This is what it looks like inside an AI-operated system — and how it is governed.
A date changes on a carrier portal and the system propagates it under rules: it confirms the datum, recalculates the promises and leaves the customer notice prepared.
Modules in this tour
- 01The exception appears ordered by impact
- 02The event comes in where the datum is born
- 03The full propagation, step by step
- 04Before and after, with name and time
- 05And if something goes wrong, it rolls back
Boosty Standard for Operating with AISimulated AI · demo data
THE SAME ENGINE
One orchestrator. Processes change, the mechanics don't.
We don't build a different engine per industry. The same state machine executes each business's own process. This is already running in production.
Signals specific to the industry
Signals specific to the industry
Signals specific to the industry
Signals specific to the industry
Signals specific to the industry
Signals specific to the industry
THE WORKFLOW, LIVE
Node by node. Running right now.
Each node is a state of the machine. The engine runs it, records its result and passes the context to the next one — with no one pushing it.
orders.status → delivered
pending
evaluates status · inbound branch
pending
match SKU · normalize payload
pending
auto-restock inventory
pending
client + route closure
pending
BEFORE AND AFTER
Six steps by hand. Zero afterwards.
The same process, two realities. On the left, what a person does today. On the right, what the engine runs — and the time that gives back each week.
- 1Review the delivery in the portal and confirm the POD
- 2Copy the order data into the ERP by hand
- 3Find the source PO and cross-check lines
- 4Adjust inventory stock manually
- 5Write and send the closing email to the client
- 6Mark the route as closed in another system
Fragile · breaks on the first exception · not auditable
› flow.trigger(delivery.completed)
› route() → inbound branch
› transform() · match SKU · normalize
› replenish() · stock adjusted
› notify() · client + route closed
✓ completed · status → completed
Time recovered / week
0.0 h
per team · in this process alone
IN THE SYSTEM · TRACEABILITY AND AUDIT
Before and after, field by field.
Every action by a person or an agent is recorded with its name, its time and what changed. It can be filtered, searched and exported.
Real screenshot of the system · demonstration data
THE TRIGGER CHAIN
Trigger → condition → action → webhook.
This is how every automation is chained. An event comes in, a condition decides whether it proceeds, an action runs and a webhook propagates the result to the rest of your stack.
opportunity.status → "won" (Postgres trigger)
weighted value > 0 · BU assigned · no prior project
create project at step "Order" + record revenue date
notify team (realtime) + opt-in Resend email to the manager
IN THE SYSTEM · IN TRANSIT
The carrier moved the date. The system recalculated what was already promised.
Every shipment with its original and current date, and the units already committed against that load. The change reaches the store, the waitlist and the customer notice, and stays in the audit trail.
Real screenshot of the system · demonstration data
CONNECTED STACK
Orchestrates your stack. Doesn't replace it.
The engine connects to what you already use. If your core has a REST API, we orchestrate it; if it's legacy, we bridge it with Make/n8n.
Claude · Anthropic
Claude PartnerDecides which step runs, classifies exceptions, and parses unstructured documents
Supabase
Deno Edge Functions + Postgres triggers: the state engine runs here
Make
Visual orchestration and webhooks to any ERP or legacy core without a modern API
n8n
Self-hosted workflows for processes with sensitive data that stays in your cloud
Kommo CRM
PartnerBidirectional sync: a stage change triggers the correct process
WhatsApp Business
Flow notifications and exceptions go out through the channel where the client responds
Frequently asked questions about process automation
No. Zapier and native automations fire rigid sequences: "if A happens, do B". That breaks on the first edge case. We model your process as an explicit state machine: the engine evaluates the state and conditions before each step, decides to advance/skip/wait, and handles retries and idempotency. It's the difference between a script and an orchestrator.
The flow is not lost. The engine distinguishes a transient failure (HTTP 503, timeout) from a data error. On a transient error it retries with exponential backoff respecting idempotency to avoid duplicates. If the retry policy is exhausted, it freezes the state, alerts operations, and puts the case in a reprocessing queue — never a case "lost in the air".
No. The engine lives ON TOP of your stack. If your core or ERP has a REST API we orchestrate it directly; if it's legacy with no modern API, we bridge it with Make/n8n and webhooks. Your team keeps working where they already work — only the repetitive manual steps disappear.
Every decision is traced: which state was evaluated, which condition was met or not, which branch was chosen, and why it retried or escalated. Every run can be audited. That's why the team trusts activating it without step-by-step supervision.
You define the control points. Low-risk steps (map data, move state, notify) run on their own. Sensitive steps (issue a legal document, execute a payment) can require explicit human approval before advancing. It's gradual: you activate more autonomy as you trust the engine.
There's no practical limit. We've modeled 11-step processes crossing CRM, ERP, AI document validation, third-party APIs, and multi-channel notifications. The state machine scales because each transition is explicit; adding a step is adding a state, not rewriting the flow.
Yes. When data cannot leave your cloud we use self-hosted n8n and Deno Edge Functions inside your Supabase. The engine runs where your data runs, with RLS and Postgres roles respected on every transition.
It is defined in the assessment. The scope — what gets built first and what waits — comes from what we see in your operation, not from a catalog. Book 30 minutes and we give you the range in writing.
A WORD FROM THE FOUNDER
“A well-modeled process runs on rules, and your team is left for the decisions that need it.”
A production line works because every station knows what it receives, what it hands over and what to do when a part arrives wrong. Many administrative processes have those same stations, written only in one person’s head: copying data between systems, chasing whoever has to sign, retrying by hand an API that went down.
Automation starts by modeling that process: explicit states, transitions with conditions, exception branches and a retry policy. With that in place, the system runs the steps that have a rule, the AI prepares the ones that need reading or classifying, and whatever commits money waits for a person. When something fails, it fails in plain sight and with a recovery path.
For the business, that means a process you can audit step by step and a team focused on the exceptions that call for judgment. Book 30 minutes with me: we map your process live and mark which steps can run on rules and which need a person. Which step does someone repeat by hand every day?
Gabriel Montiel
CEO · Boosty Digital
LET'S TALK
Ready for a process that runs on rules?
Schedule a 30-minute assessment. We'll map your process as a state machine live and show you which steps can run on rules and which stay with a person. No corporate presentation.