NEXT4I 分享 N-Flow Agentic Inception 工作流，文章標題稱 10 天完成 1.3M 次變更

The NEXT4I Micro-batching Architecture for Enterprise Software Implementation

"I want to share the story and the stats from running an AI Agent workflow that I built and kept improving until it went into real use on an internal project. I gave it a cool name, "N-Flow Agentic Inception." It is NEXT4I's own internal AI workflow, built on the Micro-batching concept and running at Enterprise scale, with a workload of about 1,200 tasks. Right now I have the AI churning out work at about 5-7 tasks per hour.
It has turned me from 'a dev who sits and writes code' into 'a dev who runs an AI factory, checking that the production line is still healthy and reading the reports from a factory that runs 24 hours a day.'"

For several months I went through a lot of trial and error building a workflow with AI Agents to develop software as a Long running Implementation, using the Micro-batching Concept. The goal was to have AI Agents work continuously for 24 hours++, keep the cost worthwhile, stay on requirement without drifting off course, work across services within the scope of the work, test themselves, and produce evidence. I'll keep sharing all of this bit by bit until the work is done. Based on the stats, the AI estimates the whole run should take about 20 days.

Stats from real runs, last month (wave 1):

Speed & Scale: After a sweeping round of fixes (I'll write about the big failure in a later article), it started running: 30 Tickets in 4 days (not running all day). Tickets hit problems often. A batch could only get through 3-5 tasks before it couldn't go any further, and I had to keep going back to fix tickets.
Low-Accuracy: Tickets failed the Quality Gate very often. Some failed for real, and some failures came from the Quality Gate itself checking things that didn't make sense, such as expecting code coverage when there were no Unit Tests yet, or Ticket Dependencies that Blocked each other so nothing could move.
Trackable: The system committed code to Git on its own, in an orderly way. In the first batch, the models closing tasks were gpt-5.6-sol (main), gpt-5.6-luna and gpt-6-astra.
The stats weren't interesting yet, and I had to fix things so often that multi-hour continuous runs were nowhere near. So I decided to tear the workflow down and rebuild it again.

Stats from real runs, 7 days ago (wave 2):

Speed & Scale: Speed kept scaling up from the very slow first wave. It now does 3.5-7 tickets per hour and has cleared about 11.7% of the Epic (146 of 1,243 tickets).
Run-to-run variation: This wave ran about 4-5 times. Some services were slower, or the loop stopped often, dropping speed to 2-4 tickets per hour. Continuous runs lasted about 3 hours, reaching 6 hours on some runs.
100% Accuracy: Among the tickets that completed, every one passed the Quality Gate on the first try.
Trackable: The system still commits code to Git and clearly records which Model finished each Task (e.g. [sonnet], [opus]).

Stats from real runs after another Workflow Refactor (wave 3):

Speed & Scale: This wave does 5-7 tickets per hour, and 43.4% of all the work is now cleared.
Running 100% on Local Claude Code, it closed 109 Tasks in the first round, using 28% of the Weekly Quota on Claude Max 5x, with a 99% Cache hit rate and 54% Context.
Then, while I was at the weekly quota limit, I used the remaining 197 USD of Free Claude Cloud credit while waiting for the weekly quota reset, and closed another 82 tickets, averaging 2.4 USD per Task. (Most of them were done by sonnet, 78 tasks, and opus picked up 4 tasks.)

Project Estimate

A project at this scale might normally need a Dev team of about 12 people (Backend 8-9, Frontend 2-3, DevOps 1-2) running for about 12 months. 1,243 tasks in total, about 3,500 Man-days (estimated by Claude Sonnet 5.5). At the current speed, the system projects it will finish in about 20 days (dev time only).

What is N-Flow Agentic Inception?

The project is enterprise-scale software that NEXT4I is building for itself. The work crosses several services and has been broken down into 1,243 tasks. (I use task, ticket and work order interchangeably here.)

The core idea is micro-batching. Instead of handing the AI one huge job, you cut the work into small pieces with a clear scope and run them in small batches. Each piece has to pass a check before the next one starts.

Here is how it actually runs:

Step 0, human: I write the requirements and refine them together with AI, using Claude, GPT-SOL and Gemini as advisors. This stage took about five to six months in total.
Step 1, planner AI: turns the requirements into tasks. Each task has a goal, things it must not do, guardrails, the tests that will verify it, and a complexity level. A set of unit tests then checks that the work orders themselves are complete.
Step 2, worker AI: picks up a work order. The system chooses a model based on the task's complexity. Some tasks are implementation work that produce code; others are test work that produce evidence.
Step 3, Quality Gate: checks each result. Only work that passes gets committed to Git, tagged with the model that finished it, such as [sonnet] or [opus].
Step 4, when it fails: retry, or escalate to a stronger model. There are human-in-the-loop checkpoints at important states so I can step in and review.

Requirements (human + AI advisors)
        │
        ▼
Planner AI ──► 1,243 work orders ──► unit tests check the work orders
        │
        ▼
Worker AI (model chosen by complexity)
        │
        ▼
Quality Gate ──► pass ──► commit + model tag ──► next task
        │
        └──► fail ──► retry / escalate to stronger model / human review

What happens when the AI gets something wrong?

As for failures, here is a stretch of log I really like:

Ticket 2: a script hit sed filter broke. Instead of stopping, the system re-checked the state, saw the work was actually done, and let it through.
Tickets 3 and 4: came back as DONE_WITH_CONCERNS. The system treated that as "not passed" and escalated from Sonnet to Opus automatically.
Opus on Ticket 3: did not start rewriting code. It concluded "no code change needed, just mark it DONE," citing earlier MCP tickets that had hit the same situation as precedent.

In factory terms, line workers (Sonnet) do most of the work, and a QC lead (Opus) only gets called in when something looks off. That matches Wave 3, where Opus handled just 4 of 82 tickets.

What I learned from the earlier rounds

The classic problem with having AI write code at scale is that we "give instructions that are too broad." The AI guesses wrong (Hallucinates), burns through Tokens, and we end up fixing things ourselves. On top of that, the cost was very high: I was using the LLM API with tools looping way too much, tokens ballooned, and the cost spiraled. It took a long time to tune, and I took a lot of pain from it myself.

So I rebuilt it around the Micro-batching concept and called it "N-Flow Agentic Inception" (AI assigns work to AI, and AI checks AI's work). The process is:

Planner AI: Takes the Requirements I designed and breaks them down into tasks with a clear Scope.
Worker AI: Takes the "work order" and runs it. The system automatically picks the Model that fits the complexity of the task, writes code and Tests until it passes the Quality Gate, then Commits the work. These AIs handle both implement tickets, where the output is code, and test tickets, where the output is evidence.

As a result, I monitor the AI's tasks less and less. After all the tuning and fixing, it has become fairly stable. I used to check the AI's progress Report every 1-3 hours, and sometimes a run would get through 50-80 tasks and then hit a problem. Now I can run long stretches of 100 tasks++, which take about 24 hours in total, and during the day I only look in once in a while. One day uses about 25-30% of the weekly quota, so I've now had to upgrade to Max 20x to be able to run the full week, since my Free Cloud credit is used up. And the stat from the latest 24 hours of runs: not a single Task has had to Escalate back to me to fix.

Summary

Breaking my back on Task Decomposition to close the Garbage In, Garbage Out gap means the system no longer bottlenecks on us. Our job is to finish the requirements, make the work clear, and then let the AI do the long runs.

My first goal for this architecture was to save cost and speed up the project. By now I think it's getting good enough that I dare to leave it running, get up from the computer, and spend my time on other things without worrying, while my NEXT4I Factory keeps churning out code like an automated production line.

As for how things turn out from here until the work is done, keep following along on this channel.

Welcome to the era of Agentic Workflow. 🚀

Explore the NEXT4I journey and read the original article at: https://go.next4i.com/next4i-devto-en

https://www.next4i.com/journey/en/next4i-agentic-workflow-01-en