Workflow automation
Workflow automation with real approvals and an audit log.
We model your process as a workflow template: which states exist, who or what may move work between them, and which gates must pass. Then we run it, on our runners or yours.
Start a project- governed states in the delivery template
- 9
- human gates that stop the run
- 2
- actor types in the audit log
- 4
What a governed workflow gives you
-
States, not statuses
A status is a label someone chose. A state is a position in a template with defined transitions out of it. Work cannot skip a step because no transition exists.
-
Approvals that actually stop things
A gate halts the run until a named person acts. The audit log records who, when and against which artifact.
-
Jobs where the work is
Each transition can start a job on a runner: an agent, a script, a deployment. The result comes back as an artifact.
-
Escalation built in
Failures move to an escalated state instead of silently retrying or being closed by hand.
-
One log for compliance
Every transition, job and artifact with its actor, in one place, exportable.
-
Templates you can change
The workflow is data. Add a state, add a gate, change who may transition, and the next run uses it.
When a workflow needs to be governed
Most processes already exist. The question is whether anything enforces them.
- 01
Approvals happen in chat
A thumbs-up in a thread is the only evidence something was signed off.
- 02
The board does not match reality
Tickets sit in Done while the work is not deployed, or in Progress while nobody is working on it.
- 03
Nobody can say who moved it
Status changes are unattributed, undated or overwritten.
- 04
Handoffs lose information
Each step re-asks for context the previous step already had.
- 05
Automation is a pile of scripts
Cron jobs, webhooks and bots that nobody has a map of, and that fail quietly.
- 06
An auditor is coming
You need to show the path every change took, and the people who approved it.
Do two or more of these apply? Tell us which ones and we reply with how we would run it.
What we automate
-
Software delivery workflows
Feature request to release through design, approval, development, QA and review, with agents doing the work.
Read more -
Approval and review processes
Design sign-off, change control, release approval, content review: gated, attributed, logged.
-
Operations runbooks
Incident, onboarding and release procedures as workflow templates with jobs on runners instead of checklists in a wiki.
-
Document and request pipelines
Intake, classification, drafting and sign-off for the documents your business produces repeatedly.
-
Scheduled and event-driven jobs
Work that starts on a timer or a webhook and writes what it did back to the record.
-
Integrations between systems
Transitions that call the systems you already run and record the result.
Read more
How we model and run a workflow
- 01
Map the process
We draw the states, transitions and gates with the people who run the process today, including the exceptions they handle by hand.
In the record feature_request, process map
- 02
Write the template
The workflow becomes a template: states, allowed transitions, who or what may trigger each one, which gates block.
In the record workflow_template, design_package
- 03
Design approval
You approve the template before a single run uses it.
In the record design_approval transition
- 04
Attach the jobs
Each transition that does work gets a job: an agent, a script, a call to a system. Jobs run on managed or self-hosted runners.
In the record implementation_package
- 05
Verify with real runs
Recorded cases are replayed through the template. QA reports what passed; a person reviews the edge cases.
In the record qa_report, review_report
- 06
Run it, watch the log
The template goes live. The audit log becomes the single account of what happened, and the next change is the next run.
In the record released, audit log
Governed workflow against the usual tools
| Item | Ticket board | Automation tool | Sydeso workflow |
|---|---|---|---|
| What enforces the process | Convention | The flow you drew | A template with explicit transitions and gates |
| Approvals | A comment | A step, if you add one | A gate that halts the run until a named person acts |
| Who did what | Activity feed | Run history | Audit log with actor: user, agent, system or runner |
| Where jobs run | Nowhere | Vendor cloud | Managed or self-hosted runners |
| AI in the loop | A plug-in | A node | Bounded agents as jobs, with outputs in the record |
| Ownership | Subscription | Subscription | Hosted, or self-hosted free |
Three ways to work with us.
-
For a team that needs the application built and run
Partner engagement
We own the application end to end: discovery, PRD, design, build, QA, release and operation. You hold the approval gates.
- Priced per project, scoped at discovery
- Your gates, our runs
- We operate production after launch
-
For a team that wants to run AI-driven delivery itself
Hosted platform
Your team and your feature requests on the Sydeso platform, with managed runners, storage, backups and upgrades operated by us.
- Per workspace, monthly
- Managed runners
- Support from the people who built it
-
For a team that keeps everything on its own infrastructure
Self-hosted
Clone the repository and run the same platform on Postgres, Redis and S3-compatible storage. Free under BUSL-1.1, AGPL-3.0 from 2030.
- Free
- Your runners, your data
- Community support on GitHub
Questions
- Is this a replacement for Jira or Linear?
- It replaces the part where a board stands in for the truth. Your tickets can stay; the workflow run is the record of what actually moved, who approved it and what was produced.
- Can a transition call our existing systems?
- Yes. A transition starts a job on a runner, and a job can call anything your runner can reach. The response comes back as an artifact.
- Who can change the template?
- Whoever you allow. Templates are data with their own approval, so a change is itself a logged, gated transition.
- What happens when a job fails?
- The run moves to an escalated state and a person decides. Nothing retries silently, and nothing is closed by hand without a logged transition.
- How quickly do you reply?
- By email, with how we would run the work, not a call to book a call. Send one paragraph about what should ship first and you get a written answer.
- Do we have to use the Sydeso platform?
- Every partner engagement runs on it, because the record it keeps is how we work. You can host it yourself from day one or move to self-hosting later; the platform is public under BUSL-1.1.
- What happens to the work if we stop?
- Everything is in the record as artifacts: requirements, design packages, implementation packages, QA and review reports. You keep all of it, and the platform that reads it is yours to run.
Show us the process.
Describe the steps and the approvals as they happen today. We reply with the template we would write and where the gates would sit.
Start a project