Agents and workflows in one runtime.
Workflow definitions and managed agents run on the same engine, drawing on the same skills, credentials vault, MCP servers and memory stores. Invoke either over HTTP or hand it to a schedule. Every execution keeps its step graph, its inputs and its retries.
See one of your own workflows run.
Thirty minutes on a call: we build one real workflow and one agent with you in a hosted workspace, then leave it running under your account.
Define an agent in code
One definition, two surfaces. Configure an agent from the builder or with the SDK — both produce the same definition, so a draft made in the UI can move into version control without being rewritten.
Go SDK
Typed and statically checked. Publish with gh push and the definition runs on our engine immediately.
Publish from CI
Keep definitions under version control and let CI publish them to an environment on merge, with diffs per revision.
Round-trip safe
UI edits emit a pull request rather than drifting from source.
Before you book.
The questions platform teams ask us on the first call — who operates the runtime, where human judgement fits, and how far the definitions stretch. If yours isn't here, bring it to the demo.
Who runs the infrastructure?
We do. GapHarness is fully managed — we host the runtime, the workers and the task queues, so there is nothing for you to deploy, scale or patch. You define workflows and agents; we run them, keep the execution history and absorb the retries.
Can a human approve a step before it proceeds?
Yes. Any workflow can include a human approval step: the execution checkpoints and waits, the reviewer sees the pending step with its inputs, and approving or rejecting resumes the run down the corresponding branch. Waiting costs nothing and holds for as long as you need.
Do agents have to be defined in code?
No — an agent can be defined entirely from the UI, or in code with the SDK, and the two produce the same definition. Teams commonly draft in the UI and move the definition into their repo once it stabilises.
Can workflows and agents call each other?
In both directions. A workflow step can invoke an agent, and an agent can invoke a workflow as one of its tools — including nested ones. Each call appears as a child execution in the parent's step graph, so one trace covers the whole chain.
Can we bring our own MCP servers, skills and memory?
Yes — connect your own MCP servers and their tools become available to any agent, write your own skills to package the tools and prompts your team keeps reusing, and create memory stores scoped to whichever agents should share them. Nothing is a fixed catalogue: the library is yours to extend.
Can both be scheduled?
Yes — schedules attach to workflows and to agents alike, on a cron expression in the timezone you choose, with concurrency caps and a catch-up policy per schedule. The same definition stays callable over the API at the same time.
Which models are supported?
Any provider you hold a key for, plus self-hosted endpoints. Models are bound per agent and per environment, so a revision can be promoted without changing its model, or re-pointed without a code change.
How are long-running workflows handled?
Steps are checkpointed, so a workflow can wait on a human approval or an external webhook for days and resume where it stopped. Retries replay from the last durable checkpoint with the original inputs.
What does it replace?
Typically a queue, a cron box, a bespoke agent harness and three dashboards you maintain yourself. Teams keep their existing orchestrators for data pipelines and move agentic work here.