You know what Marcus is. This is the mechanism — what it does end to end, and which gates never leave your side.

Kinetech · Marcus

Your backlog in.
Verified releases out.

Work is pulled from a queue rather than assigned to a person. A unit is one story at one stage — a worker takes the next one it is qualified for, does it, records its evidence, and asks for another.

Marcus, the Kinetech delivery agent

A typical month

What a month of delivery actually looks like

A typical month of Marcus deliveryThree worker lanes running in parallel across four weeks. Each lane cycles through building, independent verification and Kinetech review, pulling the next unit of work from a shared queue. Everything the month produces passes the gates before release.WEEK 1WEEK 2WEEK 3WEEK 4Lane 1buildverifyreviewbuildverifyLane 2buildverifybuildverifyreviewLane 3verifybuildverifyreviewbuildTHE GATESyour backlog18 build-days205 delivered storiesevery one driven, screenshotted and reviewed
Build Verify — a different worker drives the running app Kinetech reviewOne build-day ≈ 11 stories. Lanes are workers, not people — and they pull the next unit rather than being assigned it.

Lanes run in parallel

A lane is a worker, not a person. Adding lanes adds throughput — up to the point where your shared surfaces start colliding, and we will tell you where that is.

Verification is a different worker

The one that built it does not get to mark its own homework. A separate lane opens the running application and drives it.

Finishing a stage is the handoff

Nothing is routed by hand and nothing waits in someone’s inbox. Capacity is added by adding workers, not by adding coordination.

Nothing leaves without passing

The gates sit between the month’s output and your users. A gate that cannot be proven counts as failed.

The gates

The part that makes “done” mean something

A build is not finished because it compiles. Every application goes through the same fixed set of gates across six dimensions — Plan, Look, Act, Perform, Document, Operate — and each produces an artifact you can open rather than a status word.

Marcus, the Kinetech delivery agent

On a real delivery the model compiler reported zero errors on a build carrying six real defects. Driving the running application and screenshotting it is what found them.

That is the whole reason the gates exist, and why one of them is a separate worker driving your actual running application rather than reading the compiler’s opinion of it.

Every gate, and what it proves See the evidence

Three ways to add Marcus

Who drives, and who holds the standard

The mechanism is the same in all three. What changes is where the steering wheel sits.

Alongside your team

You drive

Your developers set direction and own the roadmap. Marcus takes the units of work you point it at and returns them proved.

Best when you have Mendix people and not enough of their hours.
We hold the quality gate

We drive the standard

Kinetech runs the milestone reviews and the release decisions, against the gates, before anything reaches your users.

Best when the roadmap is yours but the bandwidth to police quality is not.
Outcome, not capacity

We deliver it

A whole scope, fixed bid, with the risk on us and a date we commit to after reading your source.

Best when you want the result rather than the machinery.

The approval gates are yours in every one of them. Your applications, your models and your repositories are contractually yours. We host the developer, never your software.

The offer in full, including the comparison matrix

What we will not pretend. Throughput is bounded. Shared surfaces — navigation, security, the common model — are single-writer, so beyond roughly six to eight concurrent workers you are queueing, not scaling. We size to that reality instead of selling workers that would sit idle.

Step 2 of 6 — How does it work?

That is the mechanism. The fair response is 'prove it' — so next is exactly how a build has to prove itself.