Imogen Labs
Start a project

Our delivery system

Fast work still needs proof.

In use daily

An agent can write code quickly and confidently mark unfinished work complete. We built our delivery system around the gap between a claim and something a person can verify. Readiness checks, tool gates, CI and release records give each change a path from a defined problem to reviewable evidence.

Inside Our delivery system
  1. DefineA scoped problem, acceptance criteria and verification plan make work ready.
  2. EnforceTool gates check consequential actions before they run.
  3. VerifyCI, review and delivery evidence show what was actually checked.
  4. AcceptEngineering hands reviewable work to QA; human acceptance remains a separate decision.

The problem

Large requests regularly hid several different jobs. Agents would run out of context, expand scope or deliver one part while treating the whole request as finished. Tracker status made that worse when a green label was mistaken for proof that code had merged or reached a running system. We found finished documentation on unmerged branches because the board and the repository told different stories.

Written instructions were also too easy to overlook. A rule against self-acceptance or unauthorized infrastructure changes is only a policy until the tools enforce it. We needed checks before consequential actions, alongside independent review and evidence after implementation.

Who it’s for

We built it for our engineering and QA, and it is relevant to teams adopting agentic coding or untangling delivery in Jira. The aim is practical: people should know what was authorized, what changed, what checks actually ran and which decisions still require human acceptance. Faster generation should make that chain clearer rather than harder to follow.

What we built

We built a workflow that starts with a scoped story, acceptance criteria and a defined verification plan. Readiness checks reject incomplete work definitions. Tool hooks inspect proposed actions and can block them before execution. The workflow preserves a human acceptance stage, with agents stopping at QA instead of approving their own output.

We also built the integration around delivery: keen provides a consistent command interface to the work tracker, quality and security checks run with changes, release synchronization records what shipped, and documentation freshness checks catch claims that the work made untrue. These mechanisms support our product estate rather than relying on someone to remember every rule in every session.

How it works

A change begins with the problem, the intended outcome and evidence needed to judge it. Implementation stays scoped to that work. Before a restricted action runs, a hook evaluates the action and returns a block with a reason when it violates the boundary. Completed work carries its changes, checks and review evidence into QA for human verification.

The broader control plane gives operators a documented way to choose a machine and control method for authorized work. Command interfaces and graphical sessions have different authentication boundaries. We keep reach separate from authority: access to a fleet is not permission to perform destructive operations, move money, change live edge routing or send mass communications unattended.

What was hard

A guard that recognizes one command spelling can miss the same action in a different quoting form. We corrected gates to inspect meaning rather than a convenient text pattern, and exercised the cases they were meant to refuse. As tools and working rules change, the enforcement has to change with them. A restriction that covers yesterday's interface can leave today's path unguarded.

Even a passing CI badge can be incomplete evidence. In October a shutdown path ended a test run successfully before most checks executed. We added checks that each shard completed its share, alongside coverage floors and a self-check for the gate. The lesson carries through the system: a result only proves what actually ran, and a release claim needs evidence from the delivered work.

Have a similar problem?

Let’s build
what comes next.

Start a project