DEV Community: Mary Khachatryan

Stop Calling an Agent Run “Done”: Model Delivery, Acceptance, Merge, and Deployment Separately

Mary Khachatryan — Fri, 02 Oct 2026 11:24:03 +0000

An agent says the task is finished. A branch exists. CI is green. The ticket moves to Done.

Those four facts often arrive close together, but they are not the same fact. Treating them as one creates an avoidable ambiguity: did the agent finish an attempt, did a person accept the result, did the code land, or did users receive it?

A safer workflow gives each question its own state transition, permission check, and receipt.

This article builds that workflow as a small state machine. The example is intentionally implementation-level: named actors, guarded transitions, idempotent delivery, and repository evidence that cannot silently overwrite review state.

Start with two kinds of truth

The work tracker owns the truth about intent and review. The repository and release system own the truth about integration and deployment.

Do not force them into one status field.

type WorkState =
  | "draft"
  | "open"
  | "claimed"
  | "delivered"
  | "accepted";

type IntegrationState =
  | "not_applicable"
  | "unreported"
  | "branch_reported"
  | "pull_request_open"
  | "merged"
  | "blocked";

type DeploymentState =
  | "not_applicable"
  | "not_deployed"
  | "deploying"
  | "deployed"
  | "failed";

An accepted task can still be unmerged. A merged change can still be undeployed. A non-code task can be accepted without either field applying.

That is not inconsistency. It is accurate modeling.

Define the actors before the transitions

A lifecycle is only useful if the system knows who may move it.

type Role =
  | "requester"
  | "task_owner"
  | "runner"
  | "reviewer"
  | "repository_maintainer"
  | "release_owner";

type Actor = {
  id: string;
  roles: Role[];
};

One person may hold several roles, but the permission check should still name the role being exercised. That keeps an administrator override from looking like an ordinary peer review.

For higher-risk work, require the reviewer to be different from the runner. If self-verification is allowed, record it explicitly rather than presenting it as independent acceptance.

Make the happy path boring

The main workflow can stay small:

draft -> open -> claimed -> delivered -> accepted

Each transition answers one question:

Transition	Question answered	Required evidence
draft → open	Is the task safe and specific enough to offer?	Prepared brief and owner
open → claimed	Who owns this attempt?	Eligible runner and attempt ID
claimed → delivered	What result did the runner produce?	Delivery report and artifacts
delivered → accepted	Does the result satisfy the task?	Reviewer verdict

The state machine should reject shortcuts. A runner cannot accept their own delivery under the ordinary review path. A repository webhook cannot move a work item to Accepted. A successful deployment cannot invent a missing delivery report.

Guard every transition

The transition function should validate both the current state and the actor.

type Ticket = {
  id: string;
  state: WorkState;
  ownerId: string;
  runnerId?: string;
  activeAttemptId?: string;
  revision: number;
};

function assertCanDeliver(ticket: Ticket, actor: Actor) {
  if (ticket.state !== "claimed") {
    throw new Error("Only claimed work can be delivered");
  }
  if (ticket.runnerId !== actor.id) {
    throw new Error("Only the active runner can deliver this attempt");
  }
  if (!ticket.activeAttemptId) {
    throw new Error("Claimed work must have an active attempt");
  }
}

function assertCanAccept(ticket: Ticket, actor: Actor) {
  if (ticket.state !== "delivered") {
    throw new Error("Only delivered work can be accepted");
  }
  if (!actor.roles.includes("reviewer")) {
    throw new Error("Acceptance requires reviewer permission");
  }
  if (ticket.runnerId === actor.id) {
    throw new Error("Independent acceptance requires another person");
  }
}

These checks belong on the server. Hiding a button in the interface is useful feedback, not authorization.

Treat delivery as a report, not a verdict

Delivery means “this attempt is ready for judgment.” It does not mean the work is correct.

A delivery record should be append-only and tied to the active attempt:

type Delivery = {
  id: string;
  ticketId: string;
  attemptId: string;
  runnerId: string;
  summary: string;
  branch?: string;
  commitSha?: string;
  createdAt: string;
  operationId: string;
};

operationId makes retries idempotent. If a client times out after the server stores the delivery, sending the same operation again should return the original result instead of creating a second delivery.

Use an expected ticket revision as well:

async function deliver(input: {
  ticketId: string;
  expectedRevision: number;
  operationId: string;
  summary: string;
  branch?: string;
}) {
  // 1. Return the existing result for this operationId.
  // 2. Load the ticket and compare its revision.
  // 3. Check state and runner permission.
  // 4. Insert the delivery and transition atomically.
  // 5. Return the new revision.
}

This prevents a stale browser tab or delayed agent process from delivering against an attempt that has already been reopened or reassigned.

Support two different rework paths

Review failure is not one situation.

If the same runner should fix the result, send it back to Claimed and keep ownership. Start a new attempt or revision while preserving the previous delivery as history.

If another runner should take over, reopen it to Open and clear the claim. The previous delivery remains evidence, but it is no longer the standing answer.

type ReviewDecision =
  | { kind: "accept"; note?: string }
  | { kind: "send_back"; feedback: string }
  | { kind: "reopen"; reason: string };

Do not implement both choices as “move the card left.” They differ in ownership, notifications, attribution, and what context the next run needs.

Keep repository updates on a separate rail

When a delivery reports a branch or commit, store that as a claim first. Then verify it against the repository provider.

type RepositoryEvidence = {
  reportedBranch?: string;
  verifiedHeadSha?: string;
  pullRequestUrl?: string;
  mergeState: IntegrationState;
  checkedAt?: string;
};

A repository callback can update mergeState, but it must not set state = "accepted". Likewise, accepting the work must not set mergeState = "merged" unless the repository confirms it.

This separation matters when:

branch protection requires another review;
CI fails after the task review;
the base branch advances and creates a conflict;
a pull request is intentionally left open for batching;
a deployment rolls back after a successful merge.

The UI can present these facts together without collapsing them. For example:

Work: Accepted
Repository: Pull request open
Deployment: Not deployed

That line tells a release owner exactly what remains.

Record events, not just the latest values

Current state is useful for the board. Events explain how the work arrived there.

type TicketEvent = {
  id: string;
  ticketId: string;
  actorId: string;
  type:
    | "published"
    | "claimed"
    | "delivered"
    | "sent_back"
    | "reopened"
    | "accepted"
    | "merge_state_changed"
    | "deployment_state_changed";
  attemptId?: string;
  metadata: Record<string, unknown>;
  createdAt: string;
};

An audit log makes several important distinctions visible: a failed attempt versus a bad task description, self-verification versus independent review, and an accepted result versus a completed release.

It also gives teams data they can improve without inventing a single “agent success” score.

A practical implementation checklist

Before shipping this lifecycle, verify that:

Every mutation checks the current state on the server.
Claim and delivery are attached to an attempt ID.
Mutations use an idempotency key and expected revision.
Delivery stores evidence but does not imply acceptance.
Send-back and reopen have different ownership behavior.
Acceptance records who reviewed the work and whether review was independent.
Branch, pull request, merge, and deployment states come from their actual systems.
Repository and deployment updates cannot overwrite the work-review state.
The event log preserves superseded deliveries and rework reasons.
The interface shows the separate states together in plain language.

If you want to compare this model with a working product lifecycle, Wagglet documents a request-to-delivery implementation for project management software for AI agents. The useful idea is not a particular board layout. It is refusing to let one convenient “Done” label stand in for four different decisions.

When delivery, acceptance, merge, and deployment remain separate, automation becomes safer and human review becomes easier to audit. The workflow gains a few explicit transitions, but the team loses a much larger amount of guesswork.

Disclosure: I’m publishing this on behalf of the Wagglet team. AI assistance was used to structure and edit this article; I reviewed the technical content and final wording.

A Safer Way to Hand Off Game Studio Tasks Between Engineers and Artists

Mary Khachatryan — Thu, 01 Oct 2026 09:10:21 +0000

Small game studios often have the right expertise in the room but attached to the wrong development setup.

An engineer may understand the repository, build commands, and runtime constraints. An artist may be better equipped to judge animation timing, composition, readability, and whether an effect belongs in the game. The work stalls when we treat those capabilities as inseparable.

A useful game studio task handoff between engineer and artist does not ask the artist to become an engineer or ask an AI agent to replace either person. It packages one bounded task so that each participant contributes the judgment they actually possess.

This guide shows how to structure that handoff without sharing accounts, credentials, or vague responsibility.

Disclosure: I work with the team behind Wagglet. This article was prepared with AI assistance and reviewed against the current product documentation. The workflow and limitations described here should still be evaluated against your studio’s own security and review requirements.

Start with a task that has a visible result

Consider a hit-confirm effect for a combat prototype.

The effect already runs, but the team has three concerns:

The burst obscures the enemy silhouette.
The timing feels late relative to the impact animation.
The effect may be too dense on a narrow mobile viewport.

The engineer knows how to check out the correct branch and launch the relevant scene. The VFX artist knows what visual hierarchy, timing, and density should look like. Neither should have to surrender their account or impersonate the other.

This is a promising handoff because the result is observable, the scope is narrow, and an unsuccessful attempt can be discarded.

A poor candidate would be “improve combat effects.” That leaves the agent and artist to decide where the task begins, what files may change, and when the result is acceptable.

A better task is:

Adjust the existing hit-confirm burst in the combat sandbox so the enemy silhouette remains readable at 390×844 and 1920×1080. Do not change damage timing, animation events, or unrelated effects. Return before-and-after captures and the changed files for engineering review.

The second version defines an outcome, a boundary, and evidence.

Divide the handoff into three roles

A safe handoff separates preparation, execution, and acceptance.

1. The engineer prepares the technical boundary

The engineer identifies:

the repository and starting revision;
the scene or test case to open;
the files that are likely in scope;
the command used to run the project;
the behaviors that must not change;
the evidence required at delivery;
the conditions that should stop the work.

This does not require predicting every implementation detail. It means removing ambiguity that could cause the task to expand silently.

2. The artist runs the visual check

The artist uses their own authorized workspace, development tools, and agent account. Their instructions should focus on the human judgment the task needs:

compare the effect at the specified viewport sizes;
check whether the character silhouette remains readable;
inspect the delay between contact and the visible burst;
reject clipping, abrupt cuts, or unrelated visual changes;
capture the specified evidence;
stop if the agent proposes changes outside the named effect.

The artist is not being asked to approve architecture, dependency changes, or production deployment.

3. The engineer accepts or rejects the delivery

The engineer reviews the diff, runs the relevant tests, and confirms that the change remains inside the agreed boundary. Delivery is evidence that the work was attempted; it is not automatic acceptance.

That distinction prevents “the demo looked fine” from becoming the only quality gate.

Write a task contract the agent can follow

A compact task contract makes the boundary inspectable before anyone starts:

task:
  title: Tune the combat hit-confirm burst
  starting_point:
    repository: studio/game-client
    branch: prepared-review-branch
    scene: CombatSandbox
    effect: hit-confirm-burst

scope:
  allowed:
    - Existing hit-confirm effect configuration
    - Effect-local texture or timing values
  prohibited:
    - Combat damage timing
    - Animation event wiring
    - Shared renderer settings
    - Package upgrades
    - Production deployment

human_checks:
  viewports:
    - 390x844
    - 1920x1080
  verify:
    - Enemy silhouette remains readable
    - Burst begins at the visible impact
    - No clipping at either viewport
    - Other combat effects remain unchanged

delivery:
  required:
    - List of changed files
    - Before-and-after captures at both viewports
    - Commands run
    - Test results
    - Known limitations

stop_conditions:
  - Required asset or project access is missing
  - The effect cannot be isolated from combat logic
  - A dependency or shared renderer change appears necessary
  - Existing unrelated changes overlap the target files

acceptance:
  owner: gameplay engineer
  rule: Delivery requires engineering review before merge
~~~

The contract should be short enough to inspect but specific enough to prevent improvisation.

## Keep credentials attached to people

The engineer and artist should each use their own authorized identities. A handoff is not a reason to copy an API key, export a browser session, or send somebody a password.

The task can transfer instructions, repository context, file paths, test commands, acceptance criteria, non-secret sample data, and evidence requirements. It should not transfer another person’s credentials.

If the artist lacks repository access, the task is not ready. If the agent cannot authenticate using the artist’s authorized environment, it should stop and report the missing access. It should not weaken permissions or search for another credential.

## Give the agent stop conditions, not unlimited initiative

Coding agents are good at continuing. A safe handoff also tells them when not to continue.

For this example, the agent should stop if the effect is coupled to combat timing, if the working tree contains overlapping changes, or if the requested visual adjustment requires a renderer-wide modification.

A useful stop report is concrete:

~~~text
Stopped before editing.

The hit-confirm effect reads its duration from the shared combat event.
Changing the effect locally would also change gameplay timing.

Evidence:
- Effect config: effects/hit-confirm.json
- Shared timing source: combat/impact-events.ts
- No files changed

Decision needed:
Confirm whether an engineer should separate visual duration from gameplay timing.
~~~

That report preserves the boundary and gives the reviewer a real decision.

## Ask the artist to produce evidence

“Looks good” is difficult to review later. Require evidence that corresponds to the acceptance criteria.

For the hit-confirm task, a useful delivery contains:

1. Before-and-after captures at both required viewports.
2. A short note identifying the frame used to judge impact timing.
3. A list of changed files.
4. The command used to run the sandbox.
5. Any warning, unsupported setting, or approximation encountered.
6. Confirmation that unrelated effects were sampled and remained unchanged.

The artist’s judgment remains essential, but it becomes easier for the engineer to inspect.

## Review the change from two directions

The artist asks whether the visual hierarchy is correct, the effect feels synchronized, the intended style is preserved, and important gameplay information remains readable.

The engineer asks whether the change stayed inside the allowed files, preserved gameplay behavior, used valid assets and settings, passed the relevant tests, and is safe to merge.

The task is accepted only when both kinds of evidence are satisfactory.

## What this workflow does not prove

A successful handoff does not prove that the artist can independently maintain the rendering system. It does not establish that every visual task can move outside engineering. It also does not measure a productivity improvement by itself.

The workflow is most appropriate when the missing technical skill is narrow, the human runner already possesses relevant judgment, the result is observable, the work is reversible, and qualified review is available.

It is a poor fit when correctness is hidden, access is inappropriate, failure is costly, or the runner cannot recognize an important failure.

The same boundary is emphasized in [Wagglet’s field note on capability-bridging task handoffs](https://wagglet.com/blog/close-team-skill-gaps-with-ai-task-handoffs): agent assistance can help a teammate complete bounded work, but it does not make that teammate interchangeable with a specialist.

## Pilot the pattern with one effect

A studio does not need a company-wide policy to test this workflow.

Choose one low-risk visual task. Record preparation time, clarification requests, work and review time, rework, whether the task was accepted or abandoned, which stop conditions were triggered, and what evidence was missing. Then revise the template.

A good handoff makes expertise easier to apply without pretending expertise no longer matters. The engineer supplies the technical boundary. The artist supplies visual judgment. The agent helps bridge the setup and implementation gap. A separate review decides whether the result belongs in the game.