Agent access isn't workflow trust

The pattern showing up across the industry

Key takeaway: Several platforms now ship agents capable of investigating problems, proposing fixes, and deploying, with real permission models and sandboxing behind them. This is a genuine engineering achievement, not just a demo.

Look across recent platform and harness announcements and a theme repeats: an agent that can read logs and metrics, trace a problem to its root cause, propose or make a fix, and act on production, with a plan you approve first.

It's not just platform vendors either. Ask any engineer which coding agent they use and you'll get a different answer every time. Patrick Dawkins, Upsun’s principal engineer, recently put the number at around 22 major tools currently in circulation, and that count changes by the week. 

Some of this is genuinely well built. Agents run under their own identity, request scoped permissions for a specific plan rather than standing access, and test generated code in an isolated sandbox against real builds and tests before anything reaches a human.

That's a serious answer to a real question: how do you let an agent operate near production without betting the business on it never being wrong. The answer, increasingly, is good infrastructure underneath the agent, not blind trust in the model.

Where that answer runs out of road

Key takeaway: These agents are built to operate one platform's own infrastructure, for the person who already lives in that platform's dashboard. Most real work doesn't stay inside one platform, and most decisions along the way aren't made by an engineer.

Here's the part that doesn't get said out loud: most of these agents operate inside the platform that built them, on that platform's own deployments, logs, and dashboard. They're built for the person already comfortable there, which today usually means the engineer.

But a feature rarely ships through one tool. An issue starts in a tracker your team already uses. Work happens in a repo hosted somewhere. A design review happens in a design tool. Someone in security needs to sign off before it reaches customers. A manager wants visibility without opening a terminal. None of that lives inside any single platform's dashboard, and none of it is solved by making the agent inside that one platform smarter.

The question isn't whether an agent can act safely once it's already inside your platform of choice. It's whether the whole path, across every tool involved and every person who needs to see or approve a step, is something you and your team can actually run and trust together.

We hit this ourselves

Key takeaway: A single-purpose, single-tool agent is genuinely useful. It's also a preview of exactly where that approach stops covering the whole picture.

Before Upsun Dispatch existed, one of our own engineers tuned an internal agent to review pull requests inside GitLab. It works well at what it does: reading a merge request and flagging what needs attention. He also built a second version that scans requests in bulk, sorting which are clean and ready to merge, which are still under review, and which have conflicts.

Both are useful tools. Neither one is a workflow. They live inside one part of the process, on one platform, and they stop there. The rest of what actually gets a change to production, the issue that started it, the discussion around the design, the person in security who needs to sign off, still happens somewhere else, tracked by nothing in particular. Building the review agent didn't remove that coordination work, it just made one piece of it faster. 

What changes when workflow is the primitive, not the agent

Key takeaway: Treating the workflow, not the agent or the platform, as the unit that matters changes what has to be built: the tools it lives in, who gets to participate, and how cost and compliance get tracked.

Upsun Dispatch starts from a different premise: the workflow is the primitive. 

Every team already has its own rituals and ceremonies around delivery, the back-and-forth of getting a pull request reviewed, the conversations that happen before code gets written at all. A few things follow from treating that as the thing worth designing around, rather than any single agent's actions:

• It runs in the tools your team already has, not just its own dashboard. GitHub, GitLab, Linear, Jira, and the rituals your team already follows are the surface, not a separate system to adopt on top of them.
• Anyone on the team can act on a gate, not just the engineer who triggered the run. Approval isn't locked to whoever happens to be at their desk.
• Cost is visible at the team level, not the individual level. Agents spend tokens, and on an individual's laptop nobody can see where that money goes. Upsun Dispatch shows cost per run, per workflow, per team.
• It doesn't bet on one model. Store an Anthropic or OpenAI key, choose a default, and swap it whenever you need to, so the workflow doesn't lock the team into whichever model happened to be best when they set it up.
• Every run is logged against the run as compliance data: the issue, the agent's context, the plan, who approved it, and what it cost.

None of this replaces human judgment about how much rein an agent gets. It just changes where that judgment applies.

Where humans still decide

Key takeaway: Workflow orchestration doesn't mean agents run unsupervised. Upsun Dispatch has a built-in checkpoint today, and more are coming as more of the workflow becomes something Dispatch can run.

A workflow being the unit that matters doesn't mean it runs itself. Today, that means one built-in checkpoint: Dispatch pauses a Jira-triggered implementation after planning and waits for a decision before writing any code. Anyone who can comment on the issue can approve it, send it back with feedback, or stop it there, the same shape of control as a platform-native agent's plan-approval step, just applied before code gets written rather than before it gets merged.

The difference is where that checkpoint is heading, not just where it sits today. A checkpoint built into one platform's dashboard only ever covers the parts of a workflow that happen inside that platform. As Upsun Dispatch takes on more of a workflow, spanning a tracker, a repo host, and a review step, the goal is for human checkpoints to hold at each of those points, not just the one place a single platform happened to build a gate for. Giving an agent more room to work and keeping a person in the loop aren't in tension here. The gate is what makes the room safe to give.

Workflows used to be little more than a tracking mechanism, a record of work a person was doing somewhere else. What's changed isn't that the workflow suddenly matters more. It's that the workflow itself can now do part of the work, which means the question stops being what to track and becomes where a human actually needs to be, and where they don't.

None of this competes with a platform-native agent being good at operating that platform. It answers a different question: not "can this agent act safely here," but "can this workflow, spanning the tools and people it actually touches, be trusted and audited as a whole."

Why this distinction matters now, not later

Key takeaway: The current wave of agent features is solving for the engineer already inside one platform. The workflows that actually ship software involve more tools and more people than that, and that gap is where teams get stuck once they move past a single well-scoped task.

Most teams don't hit this gap on day one. A single well-scoped task, an agent fixing a build or triaging an alert inside a platform it already lives in, works fine with the current wave of platform-native agents. 

The gap shows up once your work spans more than one tool, or once someone who isn't an engineer needs to see or approve a step. That's where "the agent can act safely" stops being the whole answer, because the problem wasn't really about the agent. It was about the workflow it's a small part of.

If your team is already running agent workflows across more than one tool and feeling the coordination strain, Upsun Dispatch is free to try at upsun.com/dispatch.

Frequently asked questions (FAQ)

Isn't a well-guarded platform-native agent enough for AI-assisted software delivery?
For work that stays inside one platform, often yes. The gap appears once a task spans more than one tool, such as an issue tracker, a repo host, and a review step, or once someone outside engineering needs to see or approve part of the process.

What does "workflow is the primitive, not the agent" mean in Upsun Dispatch?
It means the thing being designed and trusted is the sequence of steps and handoffs a team already follows, across the tools they already use, rather than one agent's actions inside one platform's own infrastructure.

Does Upsun Dispatch replace platform-native agent features like GitHub Copilot workspace agents?
No. A platform agent that's good at operating its own platform is still useful for exactly that. Workflow orchestration is a layer above it, for the parts of delivery that were never going to live inside a single platform's dashboard in the first place.

Which teams benefit most from workflow-level AI orchestration instead of a single-platform agent?
Teams where delivery already involves multiple tools, since that's where a platform-bound agent, however capable, stops covering the whole path from idea to production.