Beyond the Single Prompt: Building a Multi-Agent Engine That Closes 2 Tickets an Hour

By Michael Mifsud

#ai-agents#software-engineering#devops#bdd#system-architecture

The Failure of the Single-Prompt Developer

Over the past two years, the software industry’s approach to AI-assisted coding has primarily focused on standard autocompletion and single-prompt generation. Engineers open an IDE extension, highlight a block of code, type a prompt, and hope the output doesn’t subtly break a dependency three directories away.

While impressive for boilerplate creation, single-prompt tools fail at true feature implementation. They lack structural context, cannot run feedback loops independently, and suffer from cognitive fatigue when faced with real-world edge cases.

To move from “AI assistance” to genuine autonomous software delivery, we spent months testing, failing, and refining a distributed multi-agent system. The result? A team of specialized sub-agents running asynchronously in parallel, bound by Behavior-Driven Development (BDD) specs and automated test runners.

Today, this machine consistently closes two full Jira/GitLab tickets per hour. And surprisingly, the bottleneck in our software development lifecycle (SDLC) is no longer code generation or test execution—it is the human engineer trying to keep up with reviewing every change.

Telemetry Log 
                       ┌────────────────────────────────────────┐
                       │           ORCHESTRATOR NODE            │
                       │       (Goal Decomposition & State)     │
                       └───────────────────┬────────────────────┘
                                           │
         ┌─────────────────────────────────┼─────────────────────────────────┐
         │                                 │                                 │
         ▼                                 ▼                                 ▼
┌──────────────────┐             ┌──────────────────┐             ┌──────────────────┐
│   BDD Scenario   │             │ Python Coder     │             │ Code Quality     │
│  Designer Agent  │             │ Specialist Agent │             │ Benchmark Agent  │
├──────────────────┤             ├──────────────────┤             ├──────────────────┤
│ Spec Generation  │             │ Code & Unit Tests│             │ Pytest & Grading │
│ Feature Files    │             │ Workspace Sync   │             │ Issue Reporting  │
└────────┬─────────┘             └────────┬─────────┘             └────────┬─────────┘
         │                                 │                                 │
         └─────────────────────────────────┼─────────────────────────────────┘
                                           │
                                           ▼
                       ┌────────────────────────────────────────┐
                       │        HUMAN REVIEW & APPROVAL         │
                       │          (Current Bottleneck)          │
                       └────────────────────────────────────────┘

The Architecture: Specialized Roles Over Monolithic Models

A common mistake in agent design is asking a single large language model (LLM) to be a product manager, architect, coder, and QA engineer all at once. Large contexts degrade model reasoning.

Instead, we decoupled our pipeline into highly specialized, single-responsibility sub-agents orchestrated by an underlying event loop:

1. The BDD Scenario Specialist (bdd-scenario-designer-agent)

Before a single line of production code is written, this agent digests the ticket requirements (e.g., LOS-64) and constructs the BDD acceptance feature file, step definitions, and test runner setup.

By forcing the system to establish acceptance criteria first, we establish immutable boundaries for what “done” actually means.

2. The Implementation Specialist (coder-agent-python)

Given the workspace context and BDD boundaries, the Python specialist targets specific module registries (e.g., src/supervisor/registry.py) and corresponding unit tests (tests/unit/supervisor/test_registry.py).

Crucially, this agent does not just emit code—it executes full workspace test suites (pytest) in the background. If a test fails, the agent captures the stack trace, adjusts its implementation, and reruns the suite without human intervention.

3. The Quality Benchmark Specialist (code-grading-agent)

Once implementation passes basic verification, the grading agent performs static analysis, complexity scoring, and benchmark grading. It formats the execution records and posts a comprehensive audit log directly back to our issue tracker (e.g., GitLab Issue #63).

Managing Long-Running Async Processes and State

One of the biggest breakthroughs in our pipeline was handling long-running, parallel agent execution. As shown in our workspace telemetry logs, deep engineering operations take real compute time:

If these operations ran sequentially inside a synchronous context, token costs would skyrocket, timeouts would proliferate, and progress would crawl.

By designing an asynchronous event-driven workspace, agents can spawn sub-processes, surrender execution focus back to the supervisor node, and resume when background test processes emit an exit code 0.

Why It Works: The “Test-First Guardrail” Paradigm

The secret to preventing agent hallucination drift is not a better prompt; it is a rigorous testing harness.

Without automated tests, an agent fixing bug A will blindly introduce bug B 80% of the time. In our architecture:

  1. No PR is generated without a passing test suite.
  2. No implementation agent is marked “Complete” until the code-grading-agent validates code style, test coverage, and performance overhead.

Because the agents are constantly executing real terminal commands (pytest, ruff, mypy) within an isolated workspace container, the feedback loop is instantaneous and deterministic. The AI isn’t guessing if the code works—it knows the code works because the compiler and test suite passed.

The New Bottleneck: Human Comprehension

When you have a swarm of agents resolving tickets, generating BDD specs, running 10-minute test suites, and publishing grading reports in parallel, your SDLC metrics flip completely upside down.

We went from asking:

“How long will it take engineering to build this feature?”

To asking:

“How fast can the lead architect read, understand, and approve these pull requests?”

Closing two complete, fully tested, quality-benchmarked tickets per hour means a continuous stream of incoming code changes. Because we refuse to treat our codebase as a black box, every PR must still pass human review.

The primary slowdown in our velocity is no longer implementation latency, context switching, or testing cycles—it is human reading speed. And as an engineering team, that is the best problem we have ever had.

Key Takeaways for Agentic Platforms

  1. Abandon Single-Prompt Fixes: Multi-step engineering requires multi-agent orchestration.
  2. Invest in Test Infrastructures: Agents are only as good as the deterministic feedback loops (pytest, linters, build systems) provided to them.
  3. Decouple Thinking from Execution: Let one agent design BDD specifications while another writes code and a third benchmarks quality.
  4. Embrace Async Latency: Deep code generation takes minutes, not seconds. Build your orchestrator to handle long-running background tasks gracefully.