A task
“Write this week’s newsletter.”
One result. You start the next job.
Learn loops · Danielius’s model
Run the work.
Improve the system.
Build a business that delivers useful results without you doing every step—and uses evidence to get better.
Your job shifts from doing every task to designing the routine, setting its limits and deciding what success means.
Understand the model ↓THE DELIVERY LOOPDo the work.
Make → check → deliver
Outcomes ↓↑ Tested changes
THE IMPROVEMENT LOOPChange how it works.
Observe → test → keep or reject
Start with the distinction
Repeating is useful.
Learning is a separate loop.
A delivery loop
Every Monday, gather sources, write, check and send.
The next run starts from its trigger.
An improvement loop
Use replies and failures to test a better version of the routine.
Change the method only when the test supports it.
A schedule makes work repeat. Feedback, a comparison and a keep-or-reject decision close the learning loop.
1 · Close the delivery loop
From trigger
to useful result.
Start with one user and one small promise. Make every step between the trigger and their result explicit.
- 01
Trigger
A request, due time or event starts a run.
- 02
Make
Use the right inputs to produce the result.
- 03
Check
Test it against a clear pass/fail rule.
- 04
Deliver
Put the result where the user needs it.
Save what happened. The next trigger runs the routine again. Stored progress lets it resume work and avoid duplicate delivery.
If the check fails: repair within a limit, hold for review or stop. A failed run should be visible.
If delivery fails: record it, retry safely and verify receipt. “AI finished” is not the same as “the user got it.”
Try it · Find the broken loop
Where does the system still depend on someone?
Illustrative scenarios. Choose the missing piece; try again if needed.
2 · Close the improvement loop
The next version
has to earn its place.
This is the second loop in Danielius’s model: improve the instructions, rules or tools that run the first one. Start by reviewing changes yourself; later, let the system propose, test and adopt small changes within the limits you set.
What happened?
Read real outcomes, user feedback, failures, cost and manual rework.
Change one thing.
State why a specific change should improve a named outcome.
Test old and new.
Use the same saved cases, including difficult ones. Keep some unseen cases too.
Keep or reject.
Promote only within the agreed limits. Save the version and a way back.
A new prompt is a candidate. It becomes an improvement only after evidence supports it.
The outcome is the point
Check what changed for users.
Did they receive something more useful? Did errors or manual rescue fall? A higher AI score is evidence about that test, not proof of demand or customer benefit.
A real implementation
Autonomous Startup Ideas tests its rules.
Candidate rules are compared with the current rules on saved examples. A failed comparison keeps the existing rules. The model itself is not being retrained.
See the research-and-publish loop →See it running: the class simulation shares research findings and objections in a common notebook. Small teams refine a focused startup shortlist, with independent plan reviews and weekly mentor challenges. It also compares research methods on three matched pairs and keeps the old method when the candidate loses. These are proposal assessments; real customer results must come from actual tests.
What does “recursive self-improvement” mean here?
The system can improve how it improves: for example, propose a better check after repeatedly missing the same failure. That is a further layer, not a requirement for your first version.
Keep evaluation rules and versions visible. A system must not raise its apparent score by dropping hard tests, redefining success or giving itself wider permissions. This is an operational design goal, not a claim of inevitable compounding or autonomous model training.
Try it · Keep or reject?
Would you let the new rule go live?
Illustrative results, not measurements from the real examples. The goal is a useful, accurate digest.
Your choices stay on this page. Nothing is submitted.
3 · Design the business around it
Grow. Serve. Improve.
Three connected jobs: bring people to the service, deliver value, and learn how to do both better.
Design illustration, not live operating data. The moving dots do not represent measured users or improvements.
Why will the next person come?
A useful page can carry a share link. Invitations can lead to new users; you still have to measure whether they do.
Measure: new and returning users.
What useful result do they get?
The request becomes a checked result, delivered where they need it. A result can be paid, free or useful inside an organisation.
Measure: useful deliveries and human minutes.
What evidence changes the method?
Failures and feedback trigger a proposed change. A comparison decides whether the next run should use it.
Measure: outcome change, cost and errors.
Start with one useful Serve loop. Grow and Improve can begin with people; automate more as you understand the work.
These are three business jobs, not three required agents. A running content channel is not automatically a viable business: test who returns, who benefits and who pays.
4 · Give autonomy a boundary
The routine can run.
You still set the rules.
Autonomy means less routine intervention inside an agreed scope. Goals, permissions and consequential decisions still have an owner.
You know the route.
Code sets the sequence, including branches and retries. It can call AI to write or judge a result.
The next action depends on what it finds.
The model chooses among allowed steps or tools using the results so far. Its choices still need limits.
An AI call inside a repeated workflow does not by itself make it an agent. Read the architectural distinction ↗
A clock or event starts the work; an available computer or server executes it. A stopped laptop cannot keep a local loop running.
Save inputs, versions, results and delivery status. The next run must know what already happened.
Use code for exact rules and judgment for ambiguous work. Test bad inputs, bounded retries, failed delivery and restart.
Cap cost, actions and retries. Define what needs approval, alert on failure and provide a stop control.
Watch the outcome,
not just the activity.
Real users · Returning users · Useful results · Errors · Cost per result · Human minutes
What checks can—and cannot—prove
A file exists, a link works or a price matches the input: code can test those exact rules. Use a clear rubric and saved examples for AI judgments such as relevance or tone. Calibrate those judgments against people.
A separate AI reviewer can still make the same mistake. Combine checks with user feedback and spot checks. Inspect the delivered outcome as well as the system’s claim that it succeeded. Read more about evaluating agent outcomes ↗
5 · Build by directing AI
Describe. Build. Inspect.
Keep what works.
Give a coding agent a goal, example inputs, the result you want and the limits. Ask for one working path. Test it yourself, then make the next change.
Your first specification
Who gets value? What starts the run? What gets made and checked? Where is it delivered? What happens on failure? What feedback will you use to test a change?
Write your six-line brief →See what Danielius built
Follow the actual trigger, saved context, checks and handoffs behind the startup generator, ideas channel, comic, atlas, class simulation and live idea board.
Explore my builds →Sources and how to read this lesson
The business design lens and emphasis on connected operating and improvement loops come from Danielius’s SSE Riga workshop and project framework. The scenarios above are teaching illustrations.
The technical distinctions and evaluation practices are supported by Anthropic’s Building effective agents and Demystifying evals for AI agents. The builds show which parts are implemented and where limitations remain.