My builds · Danielius Stasiulis
Six real projects.
See the loops inside.
These are projects Danielius built by directing AI agents. Explore the results, then open “How I built it” to see the tools, memory and checks. The comic and map are now complete archives; the class simulation continues.
A working loop proves the routine can run. Real users and payments are a separate test. See what a failed experiment taught us ↓
New to the model? Learn how loops work → Ready to make one? Build yours →
01 · Request-triggered service
The 60-Second Startup
A student sends a skill or problem. The service returns a checked startup concept with its own page.
Pattern to borrow: save the request first, then deliver only a checked result.
- Trigger
- One submitted skill or problem.
- Make
- AI drafts a structured concept page.
- Check
- A fresh AI review plus code checks; one repair and recheck if needed.
- Deliver
- Publish a passing page and return its link.
- Remember
- Keep the request, result, review and ratings.
How I built it One request → one checked page
Tools: a hosted Sites Worker and D1 database, with server-side AI calls. Code owns the sequence; the model fills a defined output structure.
Memory and checks: a unique request record prevents duplicate work. A fresh checker reviews the draft; deterministic checks enforce the format. If one repair still fails, the result is withheld.
A separate improvement loop: after 15 ratings, a bounded test can compare old and new producer instructions on three held-out cases with a blind grader. The new instructions are adopted only if they pass the safety checks and score higher than the current version. This does not retrain the model or establish better customer outcomes.
Human role: choose scope, budget, checks and stop rules; inspect failures. The output is a concept page, not an operating business. A proposed price is not a sale.
Recreate the pattern
A practical starting sequence, adapted from this build.
- Define the exact page you will deliver and its required fields.
- Save each request with a unique ID before calling the model.
- Separate drafting from review; allow one repair, then hold failures.
- Publish a passing result once and collect a rating.
- Test proposed instruction changes on fixed cases before adopting them.
Explore the service and improvement loops, then use the build guide.
02 · Scheduled research and publication
Autonomous Startup Ideas
Autonomous Startup Ideas researches business opportunities from documented work, then publishes candidates that pass an independent check. Formerly While You Sleep; its links and records stay available.
Pattern to borrow: a schedule creates an attempt. Passing the check earns publication.
- Trigger
- An hourly slot becomes due.
- Make
- Read public paid-work notices and supporting evidence; draft an opportunity.
- Check
- A fresh checker reopens evidence; code checks duplicates and format.
- Deliver
- Publish an immutable post and feed entry, or refuse the candidate.
- Remember
- Keep source evidence, fingerprints, run receipts and active rules.
How I built it Evidence → publication → bounded improvement
Tools: GitHub Actions supplies the cloud schedule; Codex performs research and writing; the public site and RSS feed carry the output.
Memory and checks: the current demand-first version chooses a customer segment and public demand feed. Saved sources and fingerprints help avoid repeats. A fresh checker revisits the evidence. The routine allows one repair; it can end without publishing when a candidate still fails.
A separate improvement loop: a daily bounded test compares proposed rules with the current rules. Only a better passing comparison is adopted. Repetition alone would not improve the rules.
Human role: set the topic, publishing policy, permissions and budget. Read the public receipts to distinguish attempts, refusals and actual posts. A sourced opportunity still needs a real demand test.
Recreate the pattern
A practical starting sequence, adapted from this build.
- Choose a narrow audience and the evidence that makes an item useful.
- Save sources and previously published fingerprints.
- Run research and drafting when a slot is due.
- Have a fresh reviewer check the evidence; publish once or refuse.
- Record the outcome, then test rule changes separately from publishing.
03 · Completed creative experiment
The Long Run
A story continued one illustrated scene at a time. The final archive contains all 187 committed pages, made 11–14 October 2026.
Stopped by Danielius · 14 October 2026
What worked: a fresh worker continued the story from a compact handoff, without inheriting the whole conversation.
Limit: continuity was checked by the creating artist, not an independent reviewer. Generation depended on an awake, connected Mac.
- Trigger
- A five-minute tick, when no previous job is active.
- Make
- A fresh artist continues from the last image and saved recap.
- Check
- The artist inspects the picture and continuity; code validates the files.
- Deliver
- Commit one numbered page to the reader.
- Remember
- Save the cast, fixed facts, current scene and unresolved threads.
How I built it A small handoff carries a long story
Tools: a local Codex heartbeat starts a fresh creative agent; built-in ImageGen draws the page. A Python state engine manages the archive and static reader.
Memory: the artist gets only the latest image and a compact handoff. Stable world facts and character identities stay separate from the changing recap. Every published page preserves its exact image prompt and next handoff.
Checks and recovery: the creating artist checks visual continuity; there is no independent semantic reviewer. Code requires a real image, the correct page number and a current ownership token. Interrupted artwork is kept for recovery, and committed pages are never overwritten.
Human role: provide the premise, set acceptable continuity and pause or steer future work. New generation needed the Mac awake and Codex connected. A five-minute attempt was not a guarantee of a new page.
Recreate the pattern
A practical starting sequence, adapted from this build.
- Write a premise and the facts future scenes must preserve.
- Make and inspect one scene before automating repetition.
- Save a compact recap, cast and next-scene handoff.
- Schedule one fresh worker at a time and skip overlapping ticks.
- Commit the image and handoff together; test restart recovery.
This is the final saved archive. Play turns through existing pages; it does not generate new ones. Use the memory and control principles to apply this pattern to another product.
04 · Completed artifact experiment
The Unfinished Atlas
One shared map expanded a square at a time. The final archive contains all 264 committed tiles, made 11–14 October 2026. Replay its growth, then drag to explore.
Stopped by Danielius · 14 October 2026
What worked: a fixed coordinate and saved neighbours let fresh workers append to one shared map.
Limit: a tile saved locally was not yet published. File and coordinate checks could not prove that its visual joins were good.
- Trigger
- A five-minute tick selects the next spiral position.
- Make
- A fresh artist draws a tile using the nearby regions.
- Check
- Visual inspection plus coordinate, file and metadata validation.
- Deliver
- Append the tile locally, upload it and read back publication.
- Remember
- Keep each tile’s position, prompt, continuity and image hash.
How I built it Neighbour context + an immutable archive
Tools: Codex and ImageGen create the art; Python manages the local ledger. A Sites Worker and R2 archive store ordered hosted additions, while the static reader displays them.
Memory: each artist receives the saved continuity, latest image and immediate spatial neighbours. The next position follows a fixed spiral, so the model does not choose where to overwrite the map.
Checks and recovery: the artist inspects visual joins. Code validates coordinates, files and hashes. Publication rejects conflicting or out-of-sequence tiles, treats an identical retry as already published and reads the result back. File checks alone cannot establish visual continuity.
Human role: choose the style and growth rules, operate the local scheduler and handle exceptions. The hosted archive can stay available while the Mac sleeps; generation cannot.
Recreate the pattern
A practical starting sequence, adapted from this build.
- Define the growth rule and the properties every addition must preserve.
- Give each job a position and only the relevant neighbouring context.
- Generate and inspect one addition.
- Save the image, description and continuity as one record.
- Append in order, reject conflicts and verify the uploaded result.
This is the final saved archive. Replay animates existing tiles; it does not generate new ones.
Choose a tile to read its description.
264 saved tiles · made 11–14 October 2026 · generation stopped. The map uses lightweight previews; the full-size link opens the preserved artwork.
05 · Scheduled multi-agent simulation
The class simulation
38 fictional students research in small teams, share what they learn, and refine three leading startup ideas plus two runners-up. Each selected idea develops a proposed implementation plan and receives independent reviews from fictional accelerator mentors.
Pattern to borrow: give teams different research questions, keep a shared memory, and let evidence change the shortlist.
- Trigger
- A scheduled cloud tick selects a few speakers.
- Make
- Research a specific question, compare findings, and draft a plan with a falsifiable first test.
- Check
- Verify exact quotes; a separate reviewer compares proposals under a fixed rubric.
- Deliver
- Publish at most five active plans, their separate discussion, team reports and mentor reviews.
- Remember
- Keep shared working principles, evidence, objections, retired versions and usage records.
How I built it Research, critique and tested improvements
Tools: GitHub Actions runs a Node.js engine. Each selected persona makes a separate OpenAI call; the GitHub Pages reader loads saved data from the sim-data branch. The personas use one configured model, not 38 different models.
Research and memory: Riga, LIAA and official European statistics supply dated context. Teams also inspect approved supplier costs and tool documentation. Researchers, builders and challengers investigate different questions, then bring their reports into a shared class notebook. Context, supplier capabilities and actual customer validation stay distinct.
Focus and mentors: the implementation leaderboard holds at most three leaders and two runners-up. Teams propose the audience, economics, operational loop, risks, four-week milestones and first real test. Fictional mentor roles offer occasional sparring and independent weekly reviews of the selected ideas; objections and reasons for removing a version are preserved.
Checks: new proposals must quote an actual source. Revisions stay only after a separate reviewer finds at least a one-point improvement with evidence, usefulness, payer, autonomy and test checks. New production votes also need a current review of at least 7/10. These are model judgements about hypotheses, not customer validation.
Improvement loop: two research methods use the same author and sources; a separate reviewer sees anonymous alternatives. Three pairs must improve the average by at least one point without weakening checks. On 14 October, a weekly-return method scored 5.67 against the source-first method’s 7.00, so the existing method stayed.
Budget and recovery: student, team, mentor, reviewer and trial calls share the existing $10/day limit. Reservations, discussions and version records are saved before paid calls so an interrupted runner can resume safely.
Human role: set the profiles, rubric, permitted methods and budget; inspect the evidence and pause the engine. Historical production decisions remain class votes. The class currently researches and plans: actual customer tests and permission to implement are future steps.
Recreate the pattern
A practical starting sequence, adapted from this build.
- Start with three contrasting profiles and one shared board.
- Define a few actions: propose, refine, back and oppose.
- Fetch a few trusted public sources and require exact quotations.
- Hold revisions for independent comparison; keep only supported improvements.
- Assign distinct team research questions, preserve shared lessons and review a focused shortlist.
- Compare research methods on matched cases and save the keep-or-reject decision.
- Schedule the routine within one shared budget and preserve recovery records.
A real saved workshop submission
“Dog walker marketplace”
Riga Dog-Walking Match
A small service matching Riga dog owners with nearby, vetted walkers for recurring walks.
7 / 10 AI rubric score
A proposal to test, not a verified business.
06 · Request-triggered classroom workflow
The live idea board
Students submitted ideas during the workshop. The system scored them against five criteria and returned a more concrete proposal. The archive preserves 33 accepted ideas from 42 received.
Pattern to borrow: put a reliable transaction around one AI call, including the failure path.
- Trigger
- A student submits an idea.
- Make
- One AI call scores it and proposes users, price, loop and first test.
- Check
- Validate safety, exact fields and score ranges.
- Deliver
- Return a private result and show accepted proposals on the Top 10.
- Remember
- Keep the request, status, score, proposal and completed attempt.
How I built it Save → evaluate once → publish only checked results
Tools: a separate Sites Worker, D1 database and simple browser interface. One server-side OpenAI Responses call uses gpt-6-luna; there is no model key in the student page.
Memory and recovery: a saved request ID avoids duplicate work. A processing lease claims the job once. Old in-flight jobs cannot publish into a newly reset session.
Checks: input filtering, the model’s safety decision and deterministic output checks withhold rejected or malformed results. This is one model evaluation plus code validation, not an independent second AI review.
Human role and trigger: Danielius sets the rubric, pauses intake and can hide results. Submission requests start background work; open receipt and projector pages help drain queued work. There is no independent scheduled wake-up. Scores and suggested prices are advice, not measured demand.
Recreate the pattern
A practical starting sequence, adapted from this build.
- Choose one input and the exact fields a useful response needs.
- Save a uniquely identified request before making the model call.
- Require structured output and validate every field.
- Return a receipt; publish accepted results and withhold failures.
- Test repeated submissions, slow calls, unsafe inputs and session reset.
Workshop archive captured 13 October 2026. Personal names and private receipt data are omitted.
A failed experiment · closed 14 October 2026
The Night Shift
The aim was to make, check and improve a small song, game or tool on a schedule. Danielius closed this as a failed experiment.
What happenedIt published 20 pieces from 35 attempts. On 13 October the clock chain was cancelled, its next run was skipped, and the saved status still said “active”.
What to learnA timer is part of the product. Check the last successful output and the next actual run, not only a status label. Decide what failure means and when to stop.
The results remain evidence of the experiment. Scheduled generation is disabled. Read the closure record ↗ · Learn the control principles →
Choose a pattern, then shrink it
What is the smallest useful loop you could ship?
Pick one user, one repeated job and one result they can judge. Borrow the structure of a build above, then test your own value with real people.
Looking for a project idea? Browse the class’s real workshop submissions →