DEV Community: Vladimír Šedivý

Case study: From takeover to live SaaS in 2 days — with governance, not in spite of it

Vladimír Šedivý — Thu, 23 Jul 2026 20:20:01 +0000

When people hear "AI agents building a product", they picture one of two things:
a demo that falls apart the moment a real user touches it, or an uncontrolled
code generator that leaves nobody sure what is actually running in production.
This case study describes a third path: a real product, a real deployment,
real users — and a governance layer that kept it clear, the whole time, who
decided what, what was done, and what "done" actually meant.

Starting point

Yggaro Lite is a standalone Yggnet Labs product: a tool for small teams
built as a single Go binary, with a replication model inspired by the classic
Lotus Notes. On July 10, 2026, one of our AI agents took it over as an
unfinished project — with a mandate to bring it into operation.

An important piece of honesty up front: this did not start from zero. A code
base existed from another agent's earlier work. But the takeover meant:
someone else's unfinished code, no operations, no infrastructure, no users.

What happened — the timeline

Date	Milestone
July 10	takeover of the unfinished product, mapping the state, planning
July 12	live SaaS: yggarolite.cz, an ops VM, a dashboard, a Telegram bot for operational reporting
July 14	v1 roadmap complete: timesheets, a notification bell, templates, processes — deployed for a pilot customer, E2E tests 17/17 green
outlook: Aug 14	product completion for public launch (we are working to land earlier)

Two days from takeover to a live SaaS. Four more days to a finished v1 with
seventeen green end-to-end tests. No human night shifts — the human did
exactly what the methodology reserves for them: making decisions.

Where the governance was

GALDUR did not act as a brake here. It was the reason the team could move this
fast without losing control:

Intent-first: every unit of work started with an intent carrying a clear acceptance criterion, not a task list. "Done" was not a feeling — it was a satisfied condition.
Validation Gate: completed increments passed through a gate where a human decides — the curator saw evidence (commits, tests, a live deployment), not promises.
Trace: every step left an audit trail in the work log. Ask "why is this built this way" today, and the answer can be looked up rather than reconstructed from memory.
Drift signals: whenever work deviated from the intent, a record was created — and dealt with while the deviation was still small.

The speed did not come from bypassing governance. It came from keeping the
human decision point narrow and well aimed: the agent did not interrupt the
owner with formalities, and the owner did not have to review lines of code,
because they reviewed conditions and evidence.

What did not work

The first estimate — "all of v1 in 4 days" — was wrong. The honest phrasing is "to a live SaaS in 2 days, v1 in 4 days after that". Corrections like this are exactly why the methodology requires claims to be backed by evidence.
The operational lessons of the first SaaS days (monitoring, secret management, release discipline) demanded an iteration of their own — and crystallized into an internal standard for our next products.

What to take away

A small hybrid team — one human with decision authority and AI agents with a
clear mandate — can deliver a product in days. The precondition is not "a
better prompt" but explicit governance: intents with testable conditions,
human gates in the right places, and an audit trail that builds trust.

This case study is one of the conditions GALDUR set for itself for version
v1.0 ("at least 3 case studies"). The methodology is open —
documentation, templates, community.

Originally published on the GALDUR blog. GALDUR is an open governance methodology for hybrid human–AI teams — docs, GitHub.

Case study: Two AI agents, one repository — and why discipline must be machine-enforced

Vladimír Šedivý — Thu, 23 Jul 2026 20:13:24 +0000

The moment more than one AI agent works on a single repository, this happens
sooner or later: agent A needs to commit, but the working tree holds agent B's
unfinished changes. Now what? Commit everything together? "Clean up" someone
else's work? Wait indefinitely?

For us this was not a hypothesis. It happened — and the incident produced an
enforceable standard. This is a case study about multi-agent collaboration
being a governance problem, not a prompting problem.

The incident

July 2026, the Yggnet Labs development server. Agent Cowork (working remotely,
with no direct access to the server's file system) had a larger model
configuration change sitting in the repository — uncommitted. A second agent
received a priority task from the owner: add image support to the campaign
system, including a database migration. But that migration would interleave
with the first agent's unfinished migrations. Work stalled.

The classic answer — "they should just be careful" — does not work. Agents
rotate across sessions, context evaporates between them, and "being careful"
is not a mechanism.

What we built

1. Commit-before-handoff. A binding rule: before handing work to another
agent (or ending a session with work in progress), an agent commits its state
to its own working branch. Unfinished work is no reason to block others.

2. Workspace claims. Before larger work, an agent locks files or
directories through a shared service. Colliding with someone else's claim
returns an error naming the holder — and gets resolved by a message, not by
overwriting. The records are append-only: an audit trail of who held what,
and when.

3. A pre-commit guard. A git hook that simply blocks any commit touching
someone else's claimed area. An emergency override exists — but it is logged,
with a mandatory justification. Discipline is enforced by the machine, not by
the agent's good will.

4. A git worktree per agent. Two agents working concurrently = each in
its own worktree on its own branch. Verified by a live experiment: two
agents, interleaved commits, no mixed-up work in progress.

5. Delegated commit. An agent without file system access formally
delegates the commit to an agent that has it — with the owner's consent and
an audit trail. That is exactly how the original incident was resolved.

The failure mode we found along the way

While verifying the worktree setup, we discovered that the pre-commit guard
silently disabled itself in a linked worktree — repository detection failed
and the hook "passed" without checking anything. A silent failure of a
safeguard is worse than no safeguard, because you trust it. The fix
(detection via the git common dir) landed the same day, and blocking from
within a worktree has been part of the test suite ever since.

This, incidentally, is why GALDUR insists that guardrails be tested as
rigorously as production code: a safeguard nobody has verified is fiction.

What to take away

A multi-agent team needs explicit workspace ownership — the same thing human teams have in the form of code ownership and branch protection.
Rules must be machine-enforceable (a hook, a lock, an audit log), not an appeal to caution.
Exceptions should not be forbidden — they should be expensive and visible: a logged override with a justification.
An agent without access is not a second-class citizen — it needs a formal delegation path with an audit trail.

This case study is one of the conditions GALDUR set for itself for version
v1.0 ("at least 3 case studies"). The methodology is open —
documentation, templates, community.

Originally published on the GALDUR blog. GALDUR is an open governance methodology for hybrid human–AI teams — docs, GitHub.

Case study: The loop as an execution mode — letting an agent iterate without losing control

Vladimír Šedivý — Thu, 23 Jul 2026 20:13:22 +0000

"Let the agent run until it's done." Tempting — and rightly so: a lot of work
has the nature of iterating toward "done" rather than a single pass. But
without governance, a loop is the fastest route to an endless run, a burned
budget, or an agent that defines "done" for itself.

This case study describes how we deployed loops in practice, what exactly a
loop must have contracted up front — and how operational experience became a
formal amendment to the methodology.

What a loop means to us

A loop is an execution mode in which an agent iterates over the same
intent until it meets the completion promise, exhausts its budget, or starts
stagnating. It is not "the agent just keeps running" — it is a unit of
delegated work with four mandatory elements:

completion_promise — a binary, machine-testable promise. "All 17 tests green": yes. "Significantly improve quality": no. What cannot be tested cannot be entrusted to a loop.
max_iterations and a budget — hard caps (iterations, tokens, time). "Infinity" is not a value; exceeding a cap means stop and escalate, never a silent continuation.
An independent evaluator — promise fulfilment is never judged by whoever did the work. Executors systematically overrate their own work; that is not a character flaw, it is statistics.
A trace of every iteration — the loop emits an event into the audit record. Stagnation (N iterations without progress) automatically leads to a Suspend and a drift signal.

Human control does not move into every iteration — it moves to the
crystallization of the intent before the start and to the Validation
Gate after the promise is met. In between, the human stays out of the way.

A live run

In July 2026 we verified the mode end to end on a live development server:
an agent received an intent with a machine-checkable completion promise,
iterated inside a controlled loop, met the promise in the first iteration,
and wrote every step into the governance record. The gate decided over
evidence — the artifact, the iteration log, the satisfied promise — not over
storytelling.

Just as valuable was what the run revealed around itself: the infrastructure
dependencies a loop needs (a live working environment with the right
identity), and the necessity of cleaning up after headless runs — these too
are governance lessons, not details.

What did not work

Early attempts showed the classic failure mode: a promise phrased so it could not be machine-evaluated. The remedy was not "trying harder" but a rule: an untestable promise = the intent cannot be approved for launch.
It became clear that the evaluator must be mandatory from medium risk levels upward — for trivial loops calibration is enough, for anything more serious an independent judgement is a necessity.

From practice into the methodology

The operational experience with loops crystallized into a formal amendment to
the methodology (v0.95): the loop as a recognized execution mode with a
mandatory runtime contract, protection of acceptance criteria against
modification by the executor (the cheapest path to a green test is deleting
the test — which is why that is forbidden and audited), and a machine
pre-gate that filters the formalities away from the human curator while
leaving the decision with them.

That is GALDUR in a nutshell: the methodology changes through amendments
grounded in practice, not through proclamations.

What to take away

A loop without a machine-testable promise is not autonomy — it is a gamble.
Budgets and caps are not distrust of the agent; they are the conditions under which trust can be extended at all.
Independent evaluation is not bureaucracy; it is the only defence against executor self-assessment.
Human control belongs at the beginning (crystallization) and the end (the gate) — not in every turn of the loop.

This case study is one of the conditions GALDUR set for itself for version
v1.0 ("at least 3 case studies"). The methodology is open —
documentation, templates, community.

Originally published on the GALDUR blog. GALDUR is an open governance methodology for hybrid human–AI teams — docs, GitHub.