How Upsun Dispatch runs workflows, from issue to reviewed code

Upsun Dispatch is generally available to the public as of today. Our previous article explains what it is and why we built it. This round, we take you into the details of how it works, the primitives it consists of, and the functionality available right away. You'll also get a glimpse of our roadmap at the end of the article.

The primitives

Upsun Dispatch has three big primitives: workflow, sandbox, and integrations. The core of our product is workflow. Let's dive into the details.

Workflow is a sequence of steps that takes you from a trigger to a defined outcome. Today, every workflow includes a fixed set of steps that agents or humans can execute. Our goal is to progressively let you edit existing workflows, and even build your own from scratch. To make a workflow work, you need to connect it to an external source it will interact with and define the trigger type that starts execution.

That was a general overview of our main workflow primitive. Now let's explore its sub-primitives.

Trigger, is a starting condition of the run. Triggers can fire automatically when an event is detected in a connected system, such as opening a pull request or a merge request in GitHub and GitLab, respectively. A user can start a run manually; in most cases, it represents a mention of an agent in one of the workflow inputs.

Run, is one execution of a workflow. It includes information such as: who started it, what data the agent had access to, the outcomes and duration of every step, who made the decision, and the final result. You can consult all the runs within your Upsun Dispatch organization. The run is what you open on the run page.

Step, is one action in the workflow. A step has a starting condition, expected inputs and outputs, a timeout, and a retry policy. Each step is either a deterministic step executed by the system, a step handled by an agent, or a step that requires human intervention.

Human gate, is a specific step that requires human intervention. On launch day, there is one gate in the product: plan approval in the Issue to Code workflow. You can turn it on or off, depending on how much you trust the agents. Once the workflow reaches a human gate, the run stops until the user approves moving forward with execution.

Now that we've explored the main primitive and its subprimitives, let's look at two other primitives Upsun Dispatch offers.

Sandbox is an isolated environment, created for one agent step and destroyed after it. The agent has access to the data pulled into the sandbox at its creation. Because the sandbox exists only during one step, a workflow with multiple agentic steps runs each step in its own sandbox.

Integration is a connection between Upsun Dispatch and a tool your team already uses.

The primitives at work: from a Jira issue to a reviewed pull request

Primitives are abstract until you see them in a run. So let's follow one everyday example: a product manager asks for a change in Jira, and a few minutes later a reviewed pull request is waiting on GitHub.

How to trigger the run

A product manager opens a Jira board and sees a well-described issue. It's an important change that users have been waiting for for some time. The product manager decides that it's time to get it done. They open the issue and add a comment: @Upsun Dispatch implement.

That comment is a trigger. Before the actual run starts, Upsun Dispatch checks two things: that the comment addresses Upsun Dispatch in the right way, and that the person has enough rights to trigger Upsun Dispatch on this Jira project. Upsun Dispatch ignores mentions from people without access, and no run starts. A pure mention with no command posts the list of commands the issue accepts, and nothing runs either.

Jira itself is an integration. Each integration translates the events of its tool- a Jira comment, a GitHub pull request, a Linear assignment- into one common format before they reach the workflow. This is why Issue to Code is a single workflow, with input and output sources: it does not know or care which tool the request came from.

As soon as the trigger is accepted, a run appears at the top of the Upsun Dispatch dashboard, visible to everyone in your organization. From now on, everything that happens is attached to it: who asked, what the agent saw, what each step produced, how long it took, who decided, and what it cost.

Step one: collect the context

The first step is deterministic. It fetches the issue, its comments, the linked issues and pull requests, and any mentioned files. It also checks if the ticket body indicates which repo the code should be added to, as Jira issues do not natively have that information.

It saves that data for the run. Whoever approves the plan later can open it and see exactly which inputs the agent received. This is the part most agent tools skip, and it is the part that makes the approval meaningful. You are not approving a plan blind; you are approving a plan with a clear vision of the context that produced it.

Step two: plan

Once we gather the context, we move into our first agentic step. A planning agent reads the context bundle and writes a plan.

It runs in a sandbox: an isolated environment created for this step alone, with the context bundle inside it, and destroyed the moment the step ends. Outbound network access is blocked by default. Whatever the agent does, it does inside that box.

When the plan is ready, another deterministic step posts it as a comment on the Jira issue, because that's where the run was triggered from. Upsun Dispatch records it as well, so you can find all run details in one place later.

The human gate

If your organization turned it on, the run now stops at the human gate. The workflow is paused until a human approves the plan.

The decision is made on the Jira issue, using one of the three commands:

• @Upsun Dispatch plan approve moves forward with implementing what the planning agent suggested.
• @Upsun Dispatch plan reject <reason> ends the run, recording the reason for the rejection on the run.
• @Upsun Dispatch plan revise <feedback> sends the run back to the plan step with your feedback attached. A new plan replaces the old one. Every iteration is recorded.

If nobody answers for seven days, the gate expires and the run ends.

Whether the gate is on or off is a decision your organization makes. Teams that trust the planning agent on small changes turn it off. Teams that want a person in the loop on every change leave it on. Either way, the decision and who made it are recorded on the run.

Step three: code

Our product manager approves. The coding agent starts in a fresh sandbox, with the repository cloned and the approved plan as input. Two things about this sandbox are worth knowing.

The repository token the agent uses is read-only and scoped to that one repository. It is injected at the network layer, so the agent never holds it. And the agent cannot push a branch or open a pull request from inside the sandbox. A later, deterministic step does that. The agent writes the change as the step output.

Step four: critique

Before anything reaches GitHub, a third agent, the critic, reads the diff the coding agent produced. It runs in its own sandbox, as its own step, and it sees the diff only, not the entire repository. Think of it as the first reviewer, one that reads the change before anyone else does.

It asks two kinds of questions. Did the change do what was asked? The critic reads the diff against the approved plan and flags a goal that was skipped, only half done, or quietly narrowed. And is what was built sound? Logic bugs, missing error handling, secrets or injection risks in the new code, crashes on empty input, a changed signature that will break its callers. Style nits are out of scope on purpose. An empty list of findings means the change looked sound.

The findings are written into the pull request description, so the human reviewer opens the pull request with the critic's notes already there. However, if the critic sees a change that will not even compile, a syntax error in an added line for example, it does not let the pull request open. The run stops and says why on the Jira issue, and you decide whether to try it again.

Step five: the pull request

A deterministic step pushes the branch and opens the pull request on GitHub. The commit author is the person who asked for the implementation. Dispatch is the committer and a co-author. Git history shows who wanted this and who did the work. A comment lands on the Jira issue with the link.

The branch name is stable per issue, so a second run on the same issue pushes to the same pull request instead of opening a competing one.

One last step checks that a pull request was actually opened. If it was not, the run reports as failed, not completed.

Step six: the review

The push is a trigger for another workflow. Code review starts on the new pull request, as it does on every pull request in that repository, including the ones Dispatch opens. It reads the diff and the linked issue, checks CI, and posts a review on GitHub. It never merges. Your branch protection decides what reaches production, as it did before.

What you get on launch day

Now that we've explored all the primitives, let's see what is available in Upsun Dispatch as of today.

You start with three workflows.

Code review runs on pull requests on GitHub and merge requests on GitLab. It reviews the diff against the linked issue, flags architecture problems and breaking changes, and posts a review in the tool. It runs automatically on every change, or on request with @upsun-dispatch review.

Issue to Code is the workflow we just followed. It starts from a mention in a GitHub issue, a mention in a Jira issue, or an assignment in Linear, and opens the change on GitHub or, from Linear, on GitLab. Plan approval is the organization setting described above.

CVE scan checks a repository's dependencies against known vulnerabilities and reports what it finds.

In addition to the workflows, you also have GitHub, GitLab, Jira, and Linear integrations. Reviewers and approvers act from the tool they already use; write access there is enough. Everyone in the organization sees every run. Agent time and tokens are shown per run, and the Usage page groups them by workflow and by repository. You bring your own model key, Anthropic or OpenAI, and tokens stay on your provider bill. Agent time is paid from a prepaid wallet, with no per-seat price and no repository limit. And there is a free plan: 20 agent-minutes a day, no card needed.

A glimpse of the roadmap

We built the primitives before we built the features, and the next months are about opening them up.

Today, workflows are fixed. You can turn the gate on or off, set the trigger to automatic or manual, and set options per repository, but you cannot add a step or write your own. Editable workflows, using the same step and gate vocabulary you just read, are the next thing we ship.

Today each run collects its context fresh. Persistent project knowledge, visible and editable by your team, comes after that.

Today the review is advisory and does not fix what it finds. An auto-fix workflow is coming, and it will open a change for a person to approve, not merge one.

Today, triggers are events in connected tools, plus manual runs. Scheduled runs are coming soon.

The part only a platform company can add is verification: standing up a real environment for a change, running it there, and tearing it down. That is the capability we are building toward, leveraging our Upsun Cloud heritage.

Try it on an issue you already have

Don't start from the pull request; start from the issue. Ask Upsun Dispatch to implement the change, then go to Runs. Open the context bundle and check whether the agent had what a colleague would have needed. Read the plan before the diff. Then read the review Upsun Dispatch posted on its own pull request. If that chain makes sense, the product is doing its job. If a link in the chain is missing, tell us, because the chain is the product.

Ready to begin? Sign up, connect a repository, add your model key, and mention Upsun Dispatch in an issue you already have.