Why the customer loop matters more with agentic coding
Coding agents have certainly made one aspect of software delivery a lot cheaper: the act of producing a change. They haven’t in any way made it any cheaper to work out which change is the one that you should make, or to find out whether the change actually worked for the person who requested it.
For any software organization, both of those questions go through the customer. A need comes in, reaches engineering with sufficient context to build the right thing, and the result comes back to the customer who asked. That’s the loop. The faster the middle of the loop is, the more the two ends will decide whether the work was worth doing.
What changes when agents write the code
Two things. First, when code is cheap to produce, building the right thing matters more than building it fast. DORA’s guidance on user-centric focus calls the failure mode the feature factory trap: AI helps a team that’s out of touch with its users ship low-value software faster. Its recommendations include keeping engineers close to users rather than behind a support gatekeeper, and writing user needs down before coding so they become the source of truth an agent works from. Read DORA on user-centric focus.
The second gets less attention. When a customer’s words enter a workflow that agents act on, those words become input, not instructions. OWASP’s 2025 list of risks for LLM applications puts prompt injection first, including instructions hidden in external content that a model reads, and recommends least privilege and human approval for privileged operations. Read OWASP on prompt injection. So the points where people decide aren’t overhead you’d remove once the agents got good enough. They’re also where untrusted input stops and authorized work begins.
That leaves two questions for your own team to answer. From a customer’s request to a confirmed resolution, where exactly do people decide, and where can agents do the work? And can you trace a request all the way through it, in both directions?
Walking one request through the loop
The example is the one on the Blacktops homepage, and the one the first article in this series used to find where a request waits. A customer asks: “Can this export include our Customer ID?” It’s small, and that’s the point. Even a one-column change still has to pass through support, product, engineering, review, and release before the customer can use it.
Illustrative walkthrough. The customer, the people, and the order of steps are invented to show the loop. Your stages will have different names, and some of them will be one person’s afternoon.
Ten steps in four phases (understand, specify, build and review, deliver and confirm). Each step lists what goes on the record. The steps marked Decision require a person (or the customer). All the rest is work that agents and systems can do.
1. The customer asks · Understand
What happens: The customer’s account admin asks from the application’s export screen.
On the record: Their words, their account and role, the report they were looking at, the application version.
Who: The customer asks. The in-app assistant picks up the context.
2. Clarify before building · Understand
What happens: Which report and which format? Which “Customer ID”? The application’s internal ID or the account reference that the customer uses in their own systems? Is it already available as a configurable column? The customer means their account reference and there’s no setting that will expose it.
On the record: The answers and the settings checked.
Who: Agent work. It asks, it checks the config and the docs, and the customer replies.
If a setting had solved it, the loop would have closed there: show the customer the setting, confirm it works, that’s it. That’s a good outcome, not a failure to get to engineering. Lots of requests should end at step 2.
3. Decide whether it becomes work · Specify
What happens: The product owner decides whether this is engineering work and where it sits in relation to all the other work.
On the record: The decision, the priority, and who made it.
Who: Decision, product owner. An agent can draft the case. It doesn’t make the call.
4. Agree the scope · Specify
What happens: The requirement is documented and accepted.
On the record: The approved requirement, its acceptance criteria, and what’s out of scope.
Who: An agent drafts it from the clarified need. Decision, the product owner approves the scope.
| Requirement | Accepted scope |
|---|---|
| Report | Account activity export, CSV and XLSX |
| Change | Add an “Account reference” column after the existing columns |
| Access | Fill it only for records the requesting user can already export |
| Isolation | Never return a value from another tenant |
| Unchanged | Existing column names and order |
| Out of scope | Changing the internal identifier; other reports |
| Confirmed by | The customer’s admin, through support |
5. Build in a workspace · Build and review
What happens: The approved task goes to a coding agent in a workspace with the repository, the tools, and only the access the task needs. An engineer can steer and take over.
On the record: The proposed change, linked to the requirement.
Who: Agent work. The agent works from the approved requirement rather than the customer’s message.
6. Validate · Build and review
What happens: Checks run against each acceptance criterion. The column shows the correct values. A user can’t get a reference for a record they couldn’t already export. No value crosses tenants. Existing columns are untouched.
On the record: The results, the environment used, and what wasn’t tested.
Who: Agent and pipeline work.
The access test matters most. Adding an identifier to an export is exactly the kind of change where object-level authorization slips. OWASP ranks broken object-level authorization first among API security risks and recommends testing the authorization mechanism and not deploying changes that make those tests fail. Read OWASP on object level authorization.
7. Review · Build and review
What happens: A reviewer reads the requirement, the change, and the evidence together, then approves, requests changes, or rejects.
On the record: The decision, the reviewer, and what they looked at.
Who: Decision, an authorized reviewer.
In the first article, review stalled because the identifier decision lived in a support conversation. Here, it’s been on the record since step 2, so the reviewer spends time judging the change instead of understanding why it was made.
8. Release and verify · Deliver and confirm
What happens: The approved version goes out via the team’s normal release process. A check is then performed to confirm that the version is indeed running on the customer’s account.
On the record: The version, the time, and the verification result.
Who: Decision, the release owner, or a release policy that they own. Deploying and verifying is system work.
9. Tell the customer · Deliver and confirm
What happens: An agent drafts an update in terms the customer is allowed to see: what changed and where to find it, nothing internal.
On the record: The update and when it was sent.
Who: An agent drafts it. Decision, whoever owns the customer relationship, or a communication policy they set.
10. The customer confirms · Deliver and confirm
What happens: The admin runs the export and then matches the records to the accounts.
On the record: The confirmation, in the customer’s words.
Who: Decision, the customer.
The loop closes when the customer says it meets the need rather than when the deploy has succeeded. If it doesn’t meet the need, the request goes back to step 2 with all of the learnings so far.
Where people decide
Pull the decisions out, and there are six. Everything else in the loop is work: asking clarifying questions, checking configuration, drafting the requirement, proposing and testing the change, assembling evidence, deploying and verifying, drafting the update. Agents and systems can do that work. The decisions stay with people.
| Decision | Who decides | What they need on the record |
|---|---|---|
| Is this engineering work, and when? | Product owner | The clarified need; the settings already checked |
| Is this the right scope? | Product owner | Draft requirement, access and tenant rules, what’s out of scope |
| Is this change right? | Reviewer | Requirement, change, test results, known gaps |
| Does it go out now? | Release owner, or their policy | Approval, version, rollback step |
| What do we tell the customer? | Owner of the customer relationship | Verified release; the customer’s original question |
| Did it solve the problem? | The customer | The change, working in their own account |
A policy someone owns is still a person’s decision. Someone makes it once, in advance, and everyone can see it. That’s how small, low-risk releases go out without a meeting.
None of the six is a place to take the person out because the agent got better. OWASP’s guidance on excessive agency is direct: enforce authorization in downstream systems instead of trusting the model to decide what’s allowed, and have a human approve high-impact actions before they happen. Read OWASP on excessive agency. Anthropic’s guidance for people building agents makes the same point from the other side: agents should pause for human judgement at checkpoints and when they hit blockers, and for coding work, human review remains essential. Read Anthropic on building effective agents.
Which parts are illustrative? The number of steps, their names, and their order. Your team might merge steps 3 and 4, or run validation and review as one. Keep the six questions. Rename everything else.
Trace it both ways
A loop is said to be traceable if you can walk it in both directions without having to ask anyone.
Forward: from the customer’s question, can you click through to the requirement, the change, the evidence, the approval, and the version that shipped? Backward: from a deployed version, can you find the customer who asked for it, and whether anyone told them?
Most teams will have some of the forward journey managed. On GitHub, if you have a closing keyword in a PR (e.g. “Fixes #123”), that will link it to the issue, and the issue will close when the PR is merged into the default branch. See the GitHub documentation on linking PRs to issues. That closes the issue. It doesn’t close the loop.
The links that break most often are at the two ends. At the start, support turns the conversation into a work item by copy-pasting instead of linking, and the customer’s words don’t survive the trip. At the end, nobody connects the release back to the person who asked. That’s how the customer in the second article’s example lost out: the fix shipped, and support learned about it from the release note.
Trace one request in your own stack
Pick a change that came from a customer and was shipped fairly recently. Half an hour with the person who took the request and the engineer who implemented the change is all that’s required.
- Forward. Start at the customer’s question and follow links to the deployed version. Every time you have to search or ask someone, mark a break.
- Backward. Start at the deployed version and work backwards to the customer. Mark the breaks again.
- Decisions. For each of the six, find out who made it, when, and what they had in front of them. Where there is no record, put “unknown”.
The breaks show where memory carries the context. The unknowns show where someone decided without what they needed, or where nobody decided at all. In most teams, the thinnest records are at the ends: why the work was accepted, and whether the customer was ever told.
The backward trip pays off later. DORA’s guidance on customer feedback is that teams can learn from customer responses only if those responses reach them, and can act on them only if they have the authority to change course. Read DORA on customer feedback.
Where Blacktops fits
You can do everything above by hand, and tracing one request by hand is the best way to see your own breaks.
Blacktops is the Agentic SDLC Platform built to make this loop the default. The AI FDE, our AI Forward Deployed Engineer, works inside the application where the customer asks. It clarifies the need, checks what already exists, and carries the context into the engineering workflow. From there, Blacktops keeps one thread from the customer’s question to the delivered resolution: the approved requirement, the agent’s work in a scoped workspace, the evidence, each decision and who made it, the released version, and the update back to the customer. Agents do the work between the decisions. People make the decisions, with what they need already on the record. We call the operating model Continuous Agentic Software Delivery™, or Blacktops CASD™.
Trace one request first. If your breaks are at the two ends, then that’s the loop Blacktops closes.
Tell us which handoff would matter most to your team.
Related: Why faster coding can still leave a slow release follows this same export request to find where it waits. Find the handoff where progress stops turns those waits into a six-stage checklist.
Continuous Agentic Software Delivery, CASD and Blacktops CASD are trademarks of Blacktops, Inc.