How Wishfleet works.

Three strategic principles.

Two components, one control plane.

The workflow service is the data and constraint layer. It stores definitions, runs instances, enforces transition rules, tracks activities, and captures evidence. It is a managed state machine backed by your database — no separate runtime, no replay-based history. State is a row you can query.

The decision engine is the logic layer. It reads workflow state and determines what should happen next. In deterministic mode, it evaluates rules declared in the workflow definition. In agentic mode, it loads a Skills bundle and runs it against an LLM. Both modes write back through the workflow service’s control plane — no privileged path, same audit trail.

You can use the workflow service alone — bring your own decisioner, and the platform holds state, constraints, and audit. Or use both together and let the decision engine handle routine calls and judgment-heavy transitions.

Three-layer application object model.

Work items flow through three composable layers. Each layer serves a different purpose in modeling how real-world work actually proceeds.

Workflows run concurrently against a work item — one for the physical turn, one for the financial reconciliation, one for compliance review. Processes run sequentially within a workflow — the instance is in exactly one process at a time, and re-entry on recovery is normal. Activities run concurrently within a process — an inspection, a phone call, a document request, each with its own lifecycle.

Message taxonomy.

The platform communicates through four message classes, organized along two axes: direction (inbound vs. outbound) and intent (event vs. request). This taxonomy defines the integration surface between Wishfleet and customer systems.

Signals arrive from external systems or internal timers. The decision engine evaluates them, and the workflow service enforces constraints. Events flow outward when state changes, and control calls arrive when an external actor has already decided what should happen.

The decision engine controller loop.

When a signal arrives or a workflow event fires, the decision engine enters a tight loop: read state, enumerate legal moves, decide, apply, repeat. The loop exits when the engine decides to wait. Every decision is persisted as a reasoning trace in the activity log.

Most decisions never reach an LLM. When only one transition is ready and the workflow declares it as deterministic, the engine auto-advances. Only genuinely ambiguous decisions — multiple legal transitions, judgment required — route to the agentic decider.

Verifiable results — every decision, every step.

Every transition, every activity, and every decision produces a persisted trace: who decided, why, what evidence informed it, what alternatives existed. The audit story is built into the data model, not bolted on after the fact.

The activity log is a read view over the rows the workflow service already records — transitions, activities with status history, evidence with validation state. When the decision engine makes a call, the reasoning trace captures the decider, the candidates considered, the selection, and an excerpt of the reasoning.

Operational metrics, free from the data model.

Because the platform tracks sequential processes, timestamps every state change, and records reasons for every closure, a full set of operational metrics is derivable with no separate analytics pipeline and no instrumentation work.

The data underlying these metrics is fully captured in v1. A packaged metrics query API and pre-built dashboards are on the roadmap — today, query the workflow tables directly or feed them into your existing BI stack.