An agent can inspect a repository, modify files, run checks, and revise its work. That makes the quality of the surrounding workflow consequential: a vague task can become a broad change before anyone examines the assumptions.

A practical production workflow gives the agent a bounded engineering problem and gives a human explicit decision points. The following sequence uses a hypothetical inventory reservation feature. It is a worked example, not a report of a client engagement.

1. Define the behavior and the stop conditions

Suppose a checkout must reserve stock for ten minutes. Write down what happens when inventory is insufficient, when two customers request the last unit, and when payment arrives after expiration. Identify which decisions are settled and which need a product owner.

A useful task brief contains:

  • The desired user outcome and explicit acceptance criteria.
  • The service that owns inventory and the contracts that must remain compatible.
  • Allowed files or modules, relevant repository instructions, and commands for validation.
  • Constraints on dependencies, database changes, credentials, and external systems.
  • Conditions that require escalation, such as an ambiguous payment policy or a destructive migration.

The agent can inspect implementation details independently. It should not invent a commercial policy for late payment. Resolve that uncertainty before dependent work proceeds.

2. Establish a baseline and an isolated branch

Record the starting commit and check the working tree. Preserve unrelated changes. Create a dedicated Git branch; use a separate worktree when simultaneous work would otherwise interfere.

Run the relevant baseline checks. If the inventory tests already fail, capture the failure before changing code. This distinguishes a pre-existing condition from a regression and prevents the agent from silently expanding scope to repair unrelated modules.

Give the agent access to local fixtures and test services. Production credentials are not needed to implement a reservation state machine. Any production operation should have its own explicit authorization and accountable operator.

3. Inspect before implementing

Ask the agent to trace the current stock update path and identify the authoritative transaction boundary. Review its proposed approach before a change that affects data integrity.

For the last-unit race, a read followed by an unguarded write is insufficient. The implementation needs an appropriate atomic operation or transaction strategy for the actual datastore. Require the proposal to explain the invariant: available stock cannot become negative through concurrent reservations.

Expiration introduces another boundary. A scheduled worker can release expired reservations, but checkout must also define what happens between the expiration timestamp and the worker’s next run. That behavior belongs in the design, not in an accidental timing dependency.

4. Implement in reviewable increments

Separate the reservation model, API behavior, and interface changes where doing so makes each step easier to assess. Keep the branch focused on the agreed outcome. Do not combine a checkout feature with a framework upgrade.

Ask for tests that challenge the design: concurrent attempts on the last unit, repeated reservation requests, worker retries, and payment after expiration. Use a controllable clock for time-sensitive tests rather than real waiting. Include database integration coverage when correctness depends on transaction semantics.

An agent’s command log should record the commands and their results. Reviewers need to distinguish tests actually executed from tests suggested in a final explanation.

5. Open a pull request with evidence

The pull request should explain the before-and-after behavior, data changes, compatibility assumptions, and recovery procedure. Include known limitations. If concurrency behavior was tested only against a substitute datastore, say so and resolve that gap before treating the evidence as sufficient.

A human reviewer follows the invariant through the code and checks at least one failure path independently. Review the diff for broadened permissions, secrets, dependency changes, and unrelated edits. The review decision belongs to someone who understands the affected system.

If the agent revises code after review, rerun the checks affected by that revision and review the resulting diff. Approval of an earlier version does not automatically establish correctness of the final one.

6. Release with a recoverable data plan

A database change may require an additive rollout: introduce a compatible schema, deploy code that can coexist with the old version, and remove obsolete fields later. Decide the sequence from the actual compatibility requirements.

Define a rollback boundary. Disabling new reservations may be safe while deleting reservation rows is not: those rows may be needed to reconcile payment and stock. Document what a code rollback can and cannot reverse.

Use a feature flag or limited rollout when it gives the team a meaningful way to contain risk. Name the person responsible for enabling the feature and observing its initial behavior.

7. Verify production and close the task

Verify that reservations appear, expire, and reconcile as intended. Observe errors and operational signals that correspond to the feature, such as failed expiration jobs and reservations stuck beyond their expected lifetime. Avoid logging customer or payment details to obtain those signals.

Link production verification to the pull request. Record unresolved observations as owned follow-up work, with a clear decision about whether they block rollout.

The workflow succeeds when another engineer can reconstruct the decisions and operate the feature. Agent autonomy is useful within those boundaries: it can carry implementation forward while humans retain control of product policy, architecture, approval, and production consequences.