A watch movement seen up close: steel gears and, at the centre, one green jewel.

The method

Seven rules for putting AI agents to work on real code and real processes. They do not depend on a language or a tool: they say where the limits go, and who decides.

Checks before anything moves

Nothing reaches the main branch without passing the same checks, in the same order.

A change, written by a person or by an agent, reaches the main branch only after a fixed series of checks: tests, types, dependencies, complexity, build. The order never changes, cheapest first, and the first one that fails stops everything. The checks run on the merged result, not on the branch alone, so they show what would really happen.

In the Libretto case

In Libretto that is fourteen steps, and a release starts only when CI is green. See it in the case: Checks before anything moves

Numbers that can only improve

Defects are counted; the limit goes down with them and never back up.

When a project carries defects (type errors, unused code, functions that are too complex) there is no point in demanding zero in a day. They are counted, and the count becomes a limit: a change that exceeds it stops, a change that lowers it lowers the limit too. The number can only go down.

In the Libretto case

In Libretto type errors went from 1,185 to 234 in two weeks. See it in the case: Numbers that can only improve

Agents in parallel lanes

Each agent works in its own copy, with its own data; the work meets only at the checks.

Several agents can work at once if they stay out of each other’s way: each has its own copy of the code and its own database, and the work meets only at the checks, one at a time. If two changes collide, that shows up there and not in production. How many jobs run at once is a deliberate choice, not a side effect.

In the Libretto case

In Libretto we set a maximum of three jobs in parallel. See it in the case: Agents in parallel lanes

A check on every write

Every change is verified before it is saved; if it does not hold, it does not go in.

Every change to structured data (a page, a configuration, a model) goes through a check before it is saved. If it breaks the rules it is refused with a precise reason, and nothing is left half done. The same rules apply to changes made by hand and to those made by agents.

In the Libretto case

In Libretto every write to a page goes through one tree check. See it in the case: A check on every write

Dry run first, then apply

Changes are tried without side effects; only what passes is applied.

A set of changes can be tried without side effects: the dry run runs every check and then rolls back. Only what passed is applied, as one revision that can be undone. An agent sees the outcome before it touches anything.

In the Libretto case

In Libretto an agent tries a batch of operations with dry_run_ops before applying it with apply_ops. See it in the case: Dry run first, then apply

A person decides

Agents propose and do the work; the choices that matter stay with a person.

Agents write, test and propose. Publishing, deleting, changing a rule: these decisions stay with a person, and the tools make that explicit instead of leaving it to good intentions.

In the Libretto case

In Libretto an agent publishes a site only after a person’s explicit go. See it in the case: A person decides

Problems are reported

When an agent is blocked it says so; the fix goes back into the tool.

When a tool does not allow something, the agent does not look for a shortcut: it opens a ticket saying what is missing. The fix becomes a capability of the tool, for whoever uses it next.

In the Libretto case

In Libretto agents send their tickets to whoever maintains the platform with report_issue. See it in the case: Problems are reported

Where we applied it

The method was born building Libretto, a CMS written largely by AI agents. The case page has the numbers.

The Libretto case

If something here is useful and you’d like a hand making it your own, we’re at info@innestidigital.it. If not, that’s fine too.