WorkShip
WorkShip is a workflow-driven automation harness built to replace the usual collection of scripts, scheduled jobs and one-off AI integrations with a reusable orchestration layer.
AI automation · Workflow orchestration · LynchPine product
The problem
Automation engagements keep arriving at the same engineering work: state, retries, tool execution, decision points, model calls, observability, cost, failure handling and testability.
Starting from independent scripts each time means prototypes usually have to be reworked before they are dependable enough to run in production. The harness exists so that rework is not the default.
What we delivered
Four things the harness does that a folder of scripts does not:
- Workflow orchestration. Tasks, tools and decisions are chained as one observable run rather than a loose set of independent scripts.
- Local and simulated development. An offline mode lets a workflow be built and stress-tested without spending a single paid model call, which is why iterating on one is affordable.
- Production continuity. Execution mode is configuration, not a different codebase, so the harness a workflow was built in is the harness that runs it.
- An interface someone can read. A presentation layer makes workflow behaviour inspectable by people who are not going to read logs.
The workflow
Describe the workflow
Tasks, tools and decision points are declared as one workflow. Nothing is wired together by whichever script happens to call which.
Exercise it locally
Simulation and local mode let a run be repeated without consuming live model APIs, which is what makes iterating on it affordable.
Watch the run
Trigger, tool step, decision point and model call are one traced run with the branch taken and the state recorded at each step, so a failure is something you can look at.
Promote it
The same workflow model carries into production execution, so what was tested is what runs.
Engineering decisions that mattered
- Workflow state is explicit and owned by the engine, not scattered across the scripts that happen to run. A run you cannot describe is a run you cannot retry.
- Execution mode is configuration rather than a second codebase, which is the decision that stops a tested workflow being rewritten to become a production one.
- An offline and simulated mode exists so iteration costs nothing. Charging a model call for every loop while a workflow is still wrong is how automation work gets expensive before it gets good.
- Retries and failure behaviour are part of the engine rather than each connector, so a new integration inherits them instead of reimplementing them badly.
- Every run is observable step by step, with the branch taken and the state recorded, because the alternative is inferring what happened from output.
- The orchestration layer has an interface a non-engineer can operate, so the person who owns the process can evaluate the workflow without reading a log.
Operational outcome
WorkShip is a reusable foundation for automation delivery. Instead of rebuilding orchestration mechanics for each engagement, more of an implementation goes on the part that is specific to the customer:
- their workflow
- their integrations
- their controls
- their acceptance criteria
Scope and status
LynchPine-owned proof of concept, moving toward a product. It is not a mature SaaS product and is not described as one.
The capability this draws on
See the thinking behind it
Why we run the evaluation set on a schedule, not at release
If this is your problem too
Other work
Bring the problem, not a specification
Send a paragraph about the workflow that is not working. We reply within two working days with questions, a rough shape, and an honest answer on whether we are the right people for it.
Discuss a problem