Taskflo is in development and talking with enterprise teams in regulated industries about their first workflows. Product status

Explore Taskflo

Talk to us

PLATFORM / DESIGN → SEAL → RUN

Two halves. The split is the point.

Taskflo Studio is where workflows are designed. Taskflo Execution (TFX) is where they run, inside your own cloud account. Studio produces a sealed bundle. TFX runs the reviewed version.

Architecture specification, in development. Automated proof panels, System Cards and the runtime are planned capabilities. Current product status ↗

THE CENTRAL CONSTRAINT

Your cloud is the runtime boundary.

The architecture separates authoring from execution. Runtime data, credentials, keys and model access belong in the customer-controlled plane. Validate your exact deployment and cloud-service terms during review.

WE HOST THE DESIGN PLANE

Taskflo Studio

Design the work.
Declare its authority.
Review its bounds.

workflowpinned componentspolicy packsignature
Sealed bundlePublished to your registry.
Pulled by your engine.
YOUR CLOUD ACCOUNT

Taskflo Execution (TFX)

The engine runs the reviewed version.

Identity & policy
Your keys
Your systems
Audit ledger

Authorise → Comply → Execute → Attest

Studio publishes a signed design bundle. TFX, model access, credentials and runtime systems sit within the customer-controlled boundary. Optional, redacted run metadata is a separate opt-in channel.

TASKFLO STUDIO / THE BUILDER

Design the work. See the risk.

  • A visual canvas for business, security and compliance.
  • Declared tools and effects, visible in the design.
  • Cost, reach and approval requirements calculated before promotion.
  • Policy authoring alongside workflow design.
  • New edits produce a new version, not a changed approval.
REFERENCE WORKFLOW / 01 Invoice triage
INPUT Invoice received
  1. Invoice triaged
  2. Separate approval above $500
  3. Post to ERP
  1. ExtractInvoice fields
  2. ValidateSchema & vendor
  3. Triage agentClassify exception
  4. CheckpointDurable state
  5. BranchAbove $500?
  6. ApproveSeparate approver
  7. Post to ERPDeclared action
Below threshold: Branch → Post to ERP
Above threshold: Branch → Approve → Post to ERP
BOUNDS BEFORE EXECUTION
Maximum cost per run
$2.50
Reachable systems
3
Irreversible action
1
Human approval
1
Illustrative design values for Taskflo's invoice-triage reference workflow. Not a live run or a customer result.

TASKFLO EXECUTION / THE ENGINE

Run the version your reviewers approved.

  • Pull signed bundles from a registry you control.
  • Verify components and signatures before loading.
  • Use Temporal for durable execution.
  • Bind model access and keys to your cloud services.
  • Share redacted run metadata only when enabled.
SEALED BUNDLE / ILLUSTRATIVE STRUCTURE
workflow
invoice-triage
components
version-pinned
policy pack
version-pinned
authority
declared effects
signature
checked on load

An explanatory manifest, not an actual signed artefact or verification result.

Design. Seal. Run.

  1. 01 / DESIGN

    Make authority explicit.

    Describe the process, its tools, limits and human decisions.

  2. 02 / SEAL

    Review one version.

    Calculate bounds and bind the workflow to its components and policy.

  3. 03 / RUN

    Enforce every action.

    Run the signed bundle in your cloud and retain its evidence.

AT EVERY ACTION

Authorise. Comply. Execute. Attest.

  1. 01

    Authorise

    Is this agent allowed to act?

    Check the actor, resource and declared authority. Deny by default.

    Cedar · access policy
  2. 02

    Comply

    Is it within your rules?

    Evaluate residency, purpose, retention and content at the moment of action.

    OPA / Rego · policy packs
  3. 03

    Execute

    Act within the agreed bounds.

    Use a short-lived credential for this action and a reserved budget.

    Scoped credentials · hard caps
  4. 04

    Attest

    Record it before returning it.

    Append the decision and its evidence to a tamper-evident audit ledger.

    Hash-chained record

Denied at any check? Stop the action. Name the rule. Record the decision.

PROOF BEFORE IT RUNS

Bounds you can review before go-live.

The design declares each node’s effects, reach and maximum work. Bounds account for the most expensive permitted path, including iteration caps.

The System Card accompanies each version: purpose, data handled, models, autonomy, oversight, bounds, evaluations and controls.

REFERENCE WORKFLOW

Invoice triage

DECLARED BOUNDS / BEFORE GO-LIVE
$2.50
Maximum cost per runA declared ceiling, calculated from the workflow design.
3
Reachable systemsThe systems this workflow is designed to contact.
1
Irreversible actionNamed before promotion, with recovery requirements reviewed.
1
Human approvalA separate approver for invoices above $500.
Illustrative design values for Taskflo's invoice-triage reference workflow. Not a live run or a customer result.

HUMANS AMPLIFIED, NOT REPLACED

People decide where it matters.

APPROVAL LIFECYCLE

Open → Reminded → Escalated → Resolved

Timeout is an explicit outcome. The initiator cannot also be the approver.

  • Separation of duties checked in the workflow and policy.
  • Decisions bound to what was approved.
  • Timeouts and escalation paths declared before promotion.
  • Intervention controls scoped to agents, workflows and environments.

Approvals are durable workflow steps, not a notification that can be missed. The design binds a decision to a version and a specific action. A changed payload or policy must not silently inherit an old approval.

Declare who can approve, who substitutes if they are absent, what the reviewer sees and what happens when the time limit is reached. Rejection and timeout have explicit paths; neither means permission to continue.

Intervention and autonomy are separate controls. A named operator can pause or stop work within their authority; increasing an agent’s authority requires a reviewed change, not a wider prompt.

Plan for the failure that actually happens.

  • Validators check outputs before the next step.
  • Checkpoints provide durable resume points.
  • Model fallback stays inside policy.
  • Evaluation suites are bound to workflow versions.
  • Spend, tokens, tool calls and time have hard caps.
  • Recovery is reviewed. Compensation is not always reversal.

Durable execution preserves where the workflow is, including long human waits. It does not make an external effect safe to retry. The action’s effect class, idempotency and recovery plan must be declared together.

A compensation step can address a failed sequence, but cannot unsend an email or undo every external write. Irreversible actions belong in the proof panel and promotion review, with a named owner for recovery.

Evaluation suites test a particular workflow version and policy combination. Validators and hard budgets remain execution controls even when an evaluation passes. A fallback model must satisfy the same residency, data and authority requirements as the primary.

CLOUD BINDINGS / PROPOSED ARCHITECTURE

Your services. Your account.

Architecture targets. Confirm availability for your deployment.
ResponsibilityAWSAzure
Model accessAmazon BedrockAzure OpenAI / AI Foundry
Encryption keysAWS KMSAzure Key Vault
Workload identityIAM rolesEntra Workload Identity
Write-once audit storageS3 Object LockBlob immutability policy
Untrusted code isolationgVisorKata Containers
OrchestrationAmazon EKSAzure Kubernetes Service

Primitives your engineers can inspect.

  1. Temporal

    Durable execution, human waits and deterministic replay.

  2. Cedar

    Authorisation policies that can be statically analysed.

  3. Open Policy Agent

    Versioned compliance rules in Rego.

  4. Signed OCI artefacts

    Content-addressed bundles with pinned components and signatures.

Technical dependencies, not partnerships or endorsements.

An exit, with the boundary made clear.

Studio’s intended eject path exports an idiomatic Temporal Python project. Ejected workflows leave Taskflo’s governance envelope. Export is not a promise that the exported code retains Taskflo’s enforcement.

FIVE PRINCIPLES, FIVE MECHANISMS

Not values on a wall. Mechanisms.

The architectural choices and the review value behind each principle.
PrincipleQuestionMechanismWhat it gives your review
SecurityCan this agent or person access and act on this?Declared authority. Per-action credentials. Default-deny networks.A smaller, reviewable attack surface.
ComplianceIs this workflow operating within the rules?Versioned policy packs, evaluated at every action.Rules that can stop an action, not just describe it.
AuditabilityCan we prove exactly what happened?Tamper-evident records, exported to storage you control.A record your reviewers can independently inspect.
GovernanceWho is allowed to do what, under which rules?Named owners, risk-scaled approvals and separation of duties.Named accountability as the workflow expands.
ReliabilityCan we trust this workflow to behave correctly?Durable execution, validation, recovery and hard limits.Recovery and cost limits operations can plan around.

ONE WORKFLOW. A CLEAR NEXT STEP.

See your workflow’s proof panel before you commit.

Tell us about the process, the systems and the people. Let’s work through what it would take to run it.

Talk to us about your workflow