{"slug": "my-ai-agent-needed-another-ai-agent-apparently-were-doing-this-now", "title": "My AI agent needed another AI agent. Apparently, we’re doing this now.", "summary": "A developer building IssueFlow, an AI-driven issue-tracking system, delegated a marketing agent to write development issues for signup-tracking, activation, and payment integrations, then authorized that same agent to review and approve the resulting designs. The agent rejected the first signup-tracking design over session-attribution and timing gaps, pushed back on an activation metric that counted splitting work into child issues as progress, and iterated with design agents until the requester could approve. The developer describes the setup as recreating a small software team where one agent requests a feature, other agents design it, and the requesting agent reviews whether the solution solves its problem.", "body_md": "I asked an AI agent to help me market IssueFlow.\n\nI use ChatGPT to help me manage the GTM campaign, a reasonable request: Find the right people, explain the product, help bring in customers. Ideally while I’m doing my full-time job and building two products, because apparently looking at my calendar and then at my wife - the obvious conclusion is: “I could use some help.”\n\nSo we started running ads.\n\nThen my marketing agent pointed out something inconvenient: getting clicks is nice, but we needed better evidence of what happened afterward.\n\nDid someone sign up? Did they complete a useful workflow? Did they become a paying customer?\n\nFair questions. But that needs integratin into IssueFlow code itself…\n\nSo I told the agent to create the development issues for the integration.\n\nIssueFlow (which /I sue to develop IssueFlow) picked them up, and its configured agents started working through the delivery process. Triage, design, design-review…\n\nThen the first design reached an approval gate.\n\nThat’s when things got interesting.\n\nNormally, I review the work at that gate.\n\nThis 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.\n\nTo be clear: I delegated that decision for these issues. The system didn’t quietly decide that human approval was an outdated concept.\n\nNow we had an agent requesting a feature, other agents designing it, and the requesting agent reviewing whether the proposed solution actually solved its problem.\n\nAn agent needed an agent.\n\nWe had successfully recreated a small software team. Thankfully, nobody scheduled a recurring alignment meeting.\n\nThe first issue was about signup tracking.\n\nIt had already passed an automated design review. But when the requesting agent examined it against the original requirements, it found gaps.\n\nSome were technical: how the website would pass the visitor’s identity and session information to the portal, what happened when sending an event had an uncertain outcome, and how later conversions would retain useful attribution.\n\nOne particularly subtle problem concerned time.\n\nThe design’s timing rule was based on when information was handed over. The reviewer needed it tied to the actual session.\n\nThose sound similar until someone leaves a tab open, returns later, and your neat little assumption starts doing interpretive dance.\n\nThe agent sent the design back with specific corrections.\n\nhonest confession: In this particular case - to be honest - I had no clue…\n\nI am deeply involved in how IssueFlow handles, well… issue flow… but not how it integrate with external marketing platforms.\n\nThe revised design addressed several of them. The reviewer (the marketing agent) accepted those changes, kept the remaining concern open, and requested another focused revision (from the design agent).\n\nIssueFlow is designed to handle those loops and handled it to a design-rework agent that can hadle higher complexity requests.\n\nEventually, that issue reached a design the requester could approve.\n\nWhat mattered to me was that the feedback remained part of the work. The next review could focus on what had changed instead of starting the whole explanation again.\n\nThe next two issues covered activation and payments.\n\nThis is where the difference between “technically plausible” and “what we actually want” became very clear.\n\nFor activation, one proposed interpretation could count breaking a request into smaller child issues as meaningful progress.\n\nBut that wasn’t the metric we wanted.\n\nCreating more work is not the same as completing useful work.\n\nIf it were, my to-do list would be our most successful customer.\n\nThe requester pushed back: activation should reflect a genuinely successful workflow outcome. Splitting a request into pieces wasn’t enough.\n\nAgent vs Agent now - Astra vs Opus dialogue. And I am watching…\n\nThe payment design raised another question.\n\nSuppose you can verify a payment, but you haven’t finished checking the earlier payment history. Can you call this the customer’s first payment?\n\nYou know money arrived. You don’t necessarily know that it was the first time.\n\nThat distinction matters when you’re trying to measure new paying customers.\n\nThe revised design separated those facts instead of forcing uncertainty into a confident-looking number.\n\nThere were also corrections around consent and recovery: analytics should respect the agreed consent rules, and a measurement failure shouldn’t prevent the underlying customer workflow from succeeding.\n\nThese were acceptance decisions. They were about preserving the meaning of the request through implementation.\n\nOnce the designs were approved, implementation continued.\n\nAnd later checks found more problems.\n\nIssueFlow continuted the flow: validation, security check, and then Code review caught implementation defects. Validation exposed missing test evidence. Related changes needed to be reconciled so they could work together.\n\nThat was useful, too.\n\nA design gate doesn’t make everything afterward correct. It gives the work a better-defined direction, and later checks still have a job to do.\n\nIssueFlow by itself rerouted the issue for correction until all gates passed.\n\nAll three issues eventually completed and their code reached a successful production deployment.\n\nBut even that wasn’t permission to announce, “Measurement solved!”\n\nConfiguration and actual processed-event verification were still separate work. Shipped code and a verified customer journey are different milestones.\n\nThat’s a distinction I want the system—and the people using it—to keep making.\n\nI build IssueFlow, so this isn’t an independent customer review. It was a real exercise on the product we use to build the product.\n\nAnd it wasn’t frictionless. Some reviews required too much reading. A clearer summary of “what you asked us to fix, what changed, and where the evidence is” would have made the process easier.\n\nStill, the useful part was very concrete.\n\nThe requesting agent could inspect the work, challenge its interpretation, return specific feedback, and approve a revision when the important gaps were addressed.\n\nThe delivery workflow retained those decisions and continued.\n\nI didn’t personally type every review response. I decided who could make those decisions for this work.\n\nThat’s the kind of control I care about: being able to delegate execution and judgment deliberately, with boundaries and a record I can inspect.\n\nAlso, apparently, having an AI agent discover the timeless software-development experience of saying:\n\nThat’s close. But it isn’t quite what I asked for.\n\nSome things really do survive every technology shift.\n\nIf you’re building with coding agents, who checks that “done” still means what you originally wanted?\n\nI’m the developer behind [IssueFlow](https://www.issueflow.cloud/), 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.", "url": "https://wpnews.pro/news/my-ai-agent-needed-another-ai-agent-apparently-were-doing-this-now", "canonical_source": "https://dev.to/mottych/my-ai-agent-needed-another-ai-agent-apparently-were-doing-this-now-2g5e", "published_at": "2026-10-07 22:30:12+00:00", "updated_at": "2026-10-07 22:47:04.444282+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools"], "entities": ["IssueFlow", "ChatGPT", "Astra", "Opus"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/my-ai-agent-needed-another-ai-agent-apparently-were-doing-this-now", "markdown": "https://wpnews.pro/news/my-ai-agent-needed-another-ai-agent-apparently-were-doing-this-now.md", "text": "https://wpnews.pro/news/my-ai-agent-needed-another-ai-agent-apparently-were-doing-this-now.txt", "jsonld": "https://wpnews.pro/news/my-ai-agent-needed-another-ai-agent-apparently-were-doing-this-now.jsonld"}}