On Monday morning a scheduled sync for one of Saprel's customers failed. A monitoring alert fired within two minutes, before anyone had seen anything in the product. The cause took longer to find than the alert took to arrive. One agent session had made a burst of parallel reads through the edge connection pool, and the pool asked the managed database for more connections than it had. The pool was on its default settings. The database was on its smallest tier. Nobody had written down how many connections the whole system was allowed to use, so nothing stopped it.
The fix shipped the same day. A written connection budget: worst-case connections, summed over every client of the database, stay at or under 75% of what the database allows. Hard limits on the database roles that agent access uses. Caps on every edge pool. A production database tier. The next scheduled syncs came back clean.
One more thing came out of it. The alert said that something had failed, not why. A sensor now watches the connection count, the thing that ran out, so the next alert names the cause.
Two loops, one shape
Last month this blog described the GTM loop: strategy sets what to say, the site says it, campaigns send people to it, reporting shows what happened, and the strategy is revised from what converted. That is how a customer's go-to-market learns.
The build loop is how the product learns. Saprel is built largely by agents, with a small number of people, and the question that matters is not whether that produces mistakes. It does. The question is what happens next. The answer is a loop of the same shape, with four stages and two places where a person holds the pen.
Four stages, two gates
Specify. Research, a written spec, and an adversarial review of the spec. Decisions the spec cannot make on its own are listed, and the owner rules on each one and signs the spec. Nothing is built before that. Architecture decisions are recorded as they are made, and a build plan is the hand-off to the next stage.
Build. The build plan is worked through, mostly by agent sessions, in a repository every session can open. Every change is a commit with a reason.
Verify. Tests, QA, and an adversarial review of the code. Then the second gate: a production deploy runs only when the owner starts it. A session cannot.
Operate. Logging, monitoring, alerts. This is the stage that feeds the other three, and the one that is easiest to leave half built.
The adversarial review is the same move applied twice. A second model from a different vendor, in a read-only sandbox, goes through the artifact before the owner does and argues with it. On a spec that happens before the owner's section-by-section pass. On one spec's first draft the review said do not sign, and it was right on the main points, so the spec changed before the owner signed it. On code it happens on the eve of a release, against the exact diff that will ship.
Where Monday ended up
A pipeline would have put the fix in one place and moved on. What makes it a loop is that Monday's failure left something written at three stages, and each of them is picked up on the next pass.
At specify, the connection budget became a section of the operations runbook the agent sessions work from, a line in the project instructions every session starts from, a risk row in the agent-access spec, and a step in the procedure for adding a customer: redo the sum before adding a tenant. The rule is written and it is enforced, because the role limits and pool caps are settings that hold whether or not anyone remembers the sentence.
At verify, the role limits shipped as a migration with a test, and the syncs that followed were watched rather than assumed.
At operate, the sensor on the connection count, a row in the monitoring register, so that the stage which raised the alarm can say what it was alarmed about.
A second Monday
One incident does not prove a method, so here is another, from a few weeks earlier, less flattering.
For three weeks, every push to the main repository had failed its automated tests. One cause: the test runner needed a newer runtime than the CI service was using. Nobody saw it, because the failure emails went to one inbox that the agent sessions could not read. It was found on the day a machine identity was given read access to CI status, and it was fixed in three places: the CI runtime, a CI check at the start of every session, and a written lesson in the record. Every alert needs a reader that will act on it.
The CI case also shows the loop's weak point. A signal nobody can act on is not part of the loop, however often it fires, and the fix was access, not another alert. That lesson is why Monday's alert reached an inbox that was watched. Operate fed specify, and specify was followed.
What the record is for
The reason to write all of this down, rather than remember it, is who does the next piece of work. The next feature is built by an agent session that was not there on Monday. It starts from the project instructions, the runbook, the spec, and the tests, and the budget is in all four. The lesson is in the system, not in a person's head, and the person's time goes to the two gates instead of to remembering.
That is the same argument Saprel makes to its customers about their go-to-market strategy: keep it as one living document that the team and the agents both work from, and let it improve with use. The build loop is that argument applied to the product itself.
What it does not do
The build loop did not prevent the first failure, and it did not find the cause on its own. It made the failure visible within two minutes, gave a person the record to find the cause in, and turned the cause into a rule, a test, and a sensor. The second failure of this kind is less likely, and if it comes, the alert will say why.
Not that nothing fails. That failure is noticed, explained, and budgeted against. As of October 2026, that is what the build loop can look like.
The GTM loop, the companion piece, is at /blog/the-gtm-loop. Saprel builds both: Guide holds the strategy, Web the site, Lifecycle the conversations and the pipeline.