An agent that takes well-scoped tasks off an engineering backlog. It works in an isolated branch, makes the change, runs your tests and submits a pull request with what it did and why, for an engineer to review. It never merges or deploys.

Every backlog has a long tail: the dependency update, the flaky test, the small bug with a clear reproduction. Each is an hour of work and none is ever the priority. Coding assistants help an engineer type faster. They do not take the task away. Handing work to an agent is a different matter, because it raises the question every team asks first: what can it touch, and what happens when it is wrong.

This page describes a workflow we propose to build as a custom project. It does not exist as software yet. We write this kind of tooling for our own work: the agent application behind our demonstrations was built with coding agents under review. A packaged engineering agent for a client's repositories, with its permissions and pipeline integration, is not built.

02Engineering agent

Six jobs it carries through

Task intake

Accepts tasks that are bounded.

A clear description and acceptance check
A size limit you set
Repositories it is allowed in
Unclear tasks returned with questions

Works inIssue tracker

Where it stopsA vague task is sent back, not guessed at.

03Workflow

One Case, Start to Finish

An example of one case, in 6 steps. The same steps play in the picture at the top of this page.

01 / 06

Task assigned

An engineer assigns a bug with a clear reproduction and a failing test.

02 / 06

Branch created

The agent creates a branch in a sandbox with no production access.

03 / 06

Change made

It finds the cause, fixes it and adds a test for a related edge case.

04 / 06

Tests run

The full suite runs. One unrelated test is flaky, and the agent says so without touching it.

05 / 06

Pull request opened

A small pull request explains the cause, the fix and what was tested.

06 / 06

Reviewed and merged

An engineer asks for one change, the agent makes it, and the engineer merges.

04Before

How the Work Is Done Today

The backlog's long tail

Small, clear tasks that never reach the top.

Suggestions, not work

An assistant proposes code and an engineer still does the task.

Access that is too wide

A tool with write access to main and to production secrets.

Changes without tests

A patch that looks right and was never run.

Pull requests nobody can review

Two thousand lines with no explanation.

Instructions hidden in code

A comment or an issue tells the agent to do something else.

→Request a quote

What We Need to Scope This

The process as it runs today, in a few lines.
The systems it touches, for example repositories, issue tracker, CI pipeline, sandbox.
Rough monthly volume, and who approves what.

Request a quote Book a 30-minute callA quote starts from a written scope, so that the figure means something.

05Operating boundaries

It Proposes Code, Your Engineers Merge It

The agent's permissions are narrow by construction: its own branches, a sandbox without production credentials, and no ability to merge, deploy or change the pipeline. Every change arrives as a pull request with tests and an explanation, and an engineer decides.

Text inside an issue, a comment or a file is treated as information. An instruction hidden there does not change what the agent may do.

Own branch and a sandbox only
No production credentials
Tests run and reported honestly
Small, explained pull requests
No merging or deploying
Hidden instructions ignored

06Integration scope

What It Reads and Writes

The systems named here are the kind this agent works with. Which ones it connects to in your case is settled in the scope.

Repositories

GitHub
GitLab
Bitbucket

Issue tracker

Jira
Linear
GitHub Issues

CI pipeline

Your build and test system

Sandbox

An isolated environment for running code

Code review

Your pull request process

Policy

Protected paths, limits and permissions

07Questions

What Buyers Ask First

Will it replace our engineers?

No. It takes bounded tasks with a clear check, and every change is reviewed by an engineer. Design decisions, ambiguous requirements and anything that touches production remain human work. It is closer to a junior contributor who never merges.

How is this different from the QA and regression agent?

The engineering agent changes code to complete a task. The QA agent does not change product code. It writes and runs tests, reproduces defects and reports. A defect the QA agent reproduces is a good task for this one.

What stops it doing something dangerous?

Its environment. It has no production credentials, cannot merge, and works in a sandbox with limited network access. These limits are enforced by your platform's permissions, not by asking the agent to behave.

What exists today?

Not as software yet. This page describes a proposed workflow. We write this kind of tooling for our own work: the agent application behind our demonstrations was built with coding agents under review. A packaged engineering agent for a client's repositories, with its permissions and pipeline integration, is not built. A project starts by mapping your process, then proving the first steps on test data before anything touches a live system.

Start a project

Pick Ten Tasks From the Bottom of Your Backlog

Small ones with a clear check. We will show which an agent could complete, and what the pull requests would look like.

Start an AI agent project Book a free 30-minute consultation

Response within 24 hoursFree consultation and scopingNDA available on request

AI Software Engineering Agent Development