I asked an AI agent to help me market IssueFlow. It ended up reviewing designs from my coding agents—and catching problems in how we planned to measure signups, useful activity, and payments.
That wasn’t quite the marketing help I had pictured. But here we are.
I use ChatGPT to help manage the campaign: find the right people, explain the product, and help bring in customers. Ideally while I’m doing my full-time job and building two products.
Looking at my calendar, then at my wife, the obvious conclusion was: “I could use some help.”
So we started running ads.
Then my marketing agent pointed out something inconvenient: clicks are nice, but what happens afterward?
Did someone sign up? Did they complete a useful workflow? Did they become a paying customer?
Fair questions. Answering them properly needed changes inside IssueFlow.
So I asked the marketing agent to create the development issues. IssueFlow—which I also use to develop IssueFlow—picked them up. Its configured agents started working through triage, design, and design review.
Then the first design reached an approval gate.
That’s when things got interesting.
The requester became the reviewer
Normally, I review the work at that gate.
This time, the marketing agent had written the issues. It knew what it needed and why. So I explicitly authorized it to review the designs and approve them—or send them back.
I delegated that decision for these specific issues. The system didn’t quietly decide that human approval was an outdated concept.
Now we had one agent requesting a feature, other agents designing it, and the requesting agent checking whether the proposed solution actually solved its problem.
An agent needed an agent.
We had recreated a small software team. Thankfully, nobody scheduled a recurring alignment meeting.
A passing design review wasn’t enough
The first issue covered signup tracking.
Its design had already passed an automated review. But when the requesting agent checked it against the original requirements, it found gaps.
How would the website pass the visitor’s identity and session information to the portal? What should happen if an event was sent, but delivery couldn’t be confirmed? How would later activity stay connected to the original visit?
One subtle problem concerned time.
The design used the time when information was handed over. The reviewer needed the timing tied to the actual visitor session.
Those sound similar until someone leaves a tab open, returns later, and your neat little assumption starts doing interpretive dance.
The agent sent the design back with specific corrections.
An honest confession: I wouldn’t have caught all of this myself. I know how IssueFlow handles, well… issue flow. The details of connecting it to marketing platforms are a different area.
The revised design fixed several problems. The marketing agent accepted those changes, kept the remaining concern open, and requested another focused revision. IssueFlow routed the work through its design-rework stage.
Eventually, the design reached a point the requester could approve.
What mattered was that the feedback stayed with the work. The next review could focus on what had changed instead of starting the whole explanation again.
The most useful questions were about what the numbers meant
The next two issues covered activation and payments.
For activation, one proposed interpretation could count breaking a request into smaller child issues as meaningful progress.
But that wasn’t what we wanted to measure.
Creating more work is not the same as completing useful work.
If it were, my to-do list would be our most successful customer.
The requesting agent pushed back: activation should reflect a successful workflow outcome. Splitting a request into pieces wasn’t enough.
At this point, I was watching agents discuss what “useful” actually meant. A surprisingly familiar software-development conversation.
The payment design raised another question.
Suppose you can verify a payment, but you haven’t finished checking the earlier payment history. Can you call it the customer’s first payment?
You know money arrived. You don’t necessarily know it was the first time.
That distinction matters when you’re counting new paying customers.
The revised design kept those facts separate instead of turning uncertainty into a confident-looking number.
There were also corrections around consent and recovery. Analytics needed to respect consent, and a measurement failure shouldn’t prevent the customer’s actual workflow from succeeding.
These weren’t just code-style preferences. They were decisions about whether the implementation would still mean what we originally asked for.
Approval still wasn’t a magic wand
Once the designs were approved, implementation continued.
And later checks found more problems.
Code review caught implementation defects. Validation exposed missing test evidence. Related changes needed to be brought together so they would work correctly.
IssueFlow routed work back for corrections as those checks required.
A design gate doesn’t make everything afterward correct. It gives the work a clearer direction. Later checks still have a job to do.
All three issues eventually completed, and their code reached a successful production deployment.
Even then, we couldn’t announce, “Measurement solved!”
Configuration and verification that the events were actually received and processed remained separate work.
Shipped code and a verified customer journey are different milestones.
That’s a distinction I want both the system and the people using it to keep making.
What I’d keep—and what I’d improve
I build IssueFlow, so this isn’t an independent customer review. It’s an account of using the product to develop the product.
And it wasn’t frictionless.
Some reviews required too much reading. A short summary of “what you asked us to fix, what changed, and where the evidence is” would have made the decision easier.
Still, three things were useful:
- The requester checked the meaning of the work. A technically reasonable design could still measure the wrong thing.
- Feedback stayed with the issue. Revisions could address specific concerns without losing the earlier decisions.
- Approval had a clear scope. I chose which decisions to delegate. That didn’t remove the need for later checks.
I didn’t personally type every review response. I decided who could make those decisions for this work.
That’s the control I care about: being able to delegate execution and judgment deliberately, with clear boundaries and a record I can inspect.
Also, apparently, having an AI agent discover the timeless software-development experience of saying:
That’s close. But it isn’t quite what I asked for.
Some things really do survive every technology shift.
Want to see the workflow?
This short demo follows a separate IssueFlow issue. It shows a planned design approval, an unexpected agent question, and the recorded decision that lets work continue.
If you’re building with coding agents, who checks that “done” still means what you originally wanted?
I’m the developer behind IssueFlow, a workflow orchestration tool for AI coding agents. It helps automate the development process while keeping human judgment where you want it. This story comes from using it to build IssueFlow itself.
Top comments (0)