Tiny tools. Mini games. Practical AI, made simple.

Automation is the oldest of the three: a rule that fires the same way every time. If a photo lands in a folder, rename it with today’s date. If an email contains the word invoice, file it away. Automation is fast, cheap, and completely unable to handle a surprise. It does exactly what you told it, including the mistakes.

An assistant waits for you to ask, then responds. You bring the goal and the judgment; it brings speed, memory, and patience. The Mood Meter on this page is a toy version of the idea: a sentence goes in, a reaction comes out. Real assistants read context, ask follow-up questions, and draft things for you to approve. You are still driving. They just make the driving easier.

An agent gets a goal and works out the steps itself. It tries something, looks at what happened, adjusts, and tries again. Mind Reader, also on this page, is a tiny honest example: guess the middle number, listen to “higher” or “lower,” cut the search space in half, repeat. Seven guesses, guaranteed. Bigger agents do the same loop with real tools: files, websites, calendars, code.

Why does the distinction matter? Because picking the wrong one hurts. Use a brittle rule for a job that needs judgment and it breaks quietly at the worst moment. Use a fancy agent for a job a three-line rule would nail and you have built an expensive, unpredictable way to do a simple thing. This lab builds at all three levels on purpose, and the blog will keep pulling the ideas apart, one small experiment at a time.

Nobody loses their afternoon to one big task. They lose it to forty small ones, each too trivial to complain about and too frequent to ignore. That is exactly the territory where simple automation pays. You do not need special software for most of these, just the habit of noticing a chore the third time you do it.

1. Receipts in, PDF out. Photograph receipts the day they happen, then merge the photos into one monthly PDF. Future you, at tax time, says thanks. The Photos to PDF tool on this page exists for precisely this.
2. Name files by rule, not by mood. Date first, then what it is: 2026-10-01-rent-receipt.pdf. Files named by rule sort themselves and search themselves.
3. Save the replies you type every week. The same five answers, written once, pasted forever. Every mail app and phone keyboard can store text shortcuts.
4. Run a tone check before you send. Paste a heated draft into the Mood Meter here, or any sentiment tool, and see how it reads to fresh eyes. Thirty seconds that has saved more than one working relationship.
5. Batch the boring conversions. Text to PDF, PDF to text, a quick word count. Doing them in one browser tab, on your own device, beats uploading private files to three different ad-covered sites.
6. End the week with a five-minute sweep. Empty the downloads folder, clear the desktop, confirm one backup ran. Automating the reminder is the automation.
7. Keep one list, not five. Ideas, requests, and half-finished thoughts go in a single note. The best system is the one you actually check.

None of these will trend on social media. Put together, they are worth roughly an hour a week, which over a year is a full work week handed back. That is the real promise of automation at human scale: not replacing people, just deleting the chores standing between them and the interesting work.

Strip away the marketing and every AI agent runs the same four-step loop. Hold a goal. Take a step. Observe what happened. Adjust and repeat. The models, tools, and interfaces change. The loop does not.

Mind Reader runs that loop where you can watch it. The goal: find the number you are thinking of, between 1 and 100. The step: guess the middle of the remaining range. The observation: you say higher or lower. The adjustment: throw away half the possibilities and guess again. Each round of honest feedback cuts the problem in half, which is why the game promises a win in seven guesses or fewer. No cleverness, just a loop that respects feedback.

Serious agents add three things to that skeleton. Tools, so a step can mean converting a file, searching the web, or sending a message instead of just producing text. Memory, so step twelve remembers what step three learned. And stopping rules, the judgment to know when the result is good enough to hand over. When agents fail in the real world, it is usually the loop that broke: they skipped the observe step and confidently repeated a bad guess, or never learned when to stop.

That is why this lab starts with games and meters. The loop is visible here, small enough to hold in your head. The automations and assistants being built on the same bench are the same loop with better tools, longer memory, and more careful stopping rules. Play a round of Mind Reader and you have the whole idea. Everything else is scale.

Most “photo to PDF” tools on the web work the same way: you upload your images, their server stitches them together, and you download the result. It works, but your photos took a trip you never approved, and some of those sites keep copies. There is a simpler route. Your browser can do the whole job itself.

The Photos to PDF tool on this page reads each image right in the tab, draws it onto a page, and hands you one tidy PDF. Nothing leaves your device. The steps take about twenty seconds:

1. Open the tool and choose Photos to PDF.
2. Add your images by tapping the box or dragging files in. JPG, PNG, WebP, and GIF all work.
3. Check the order. The list on screen is the page order in the finished PDF, so add photos in reading order.
4. Tap Make my PDF. One image lands on each page, centered and sized to fit.

Two tips from doing this a lot. First, shoot documents flat and straight overhead, with the page filling the frame; the PDF inherits whatever angle the photo had. Second, glance at file names before you start. When a form has a front and a back, adding them in the wrong order is the only real way this goes sideways.

That is it. One PDF, made locally, ready to email or file away. If your photos need to become editable text afterwards, run the finished PDF through the PDF to Text tool next and see what it pulls out.

A PDF can hold words in two very different ways. In a born-digital PDF, the kind exported from Word, Google Docs, or a web page, every character is stored as actual text data, along with instructions for where to draw it. The words are really in there. Reading them back out is just a matter of asking nicely, which is what the PDF to Text tool here does, page by page, right in your browser.

A scanned PDF is a different animal. A scanner or phone camera produces a picture of a page, and the PDF wraps that picture in a file. To you it looks like text. To a computer it is a grid of colored dots, no different from a photo of a cat. There is no text layer to extract, so an honest extractor hands you back nothing, and that is the correct answer.

Getting words out of a scan takes OCR, optical character recognition: software that studies the dots, guesses which letters they form, and rebuilds the text. OCR is genuinely useful and genuinely fallible. It stumbles on handwriting, odd fonts, and crooked scans. Building a good OCR tool is a bigger project than a page like this one, so for now the lab sticks to clean text-layer extraction and tells you plainly when a PDF has nothing to give.

Quick test for any PDF you meet: open it and try to select a sentence with your cursor. If the words highlight, it has a text layer and extraction will work beautifully. If you can only drag a box around the whole page like a picture, you are holding a scan.

The Mood Meter is almost embarrassingly simple. It carries two lists, a few dozen sunny words and a few dozen gloomy ones. You give it a sentence, it counts how many words appear on each list, and the ratio becomes a percentage. “Today was wonderful” scores high. “Today was terrible” scores low. That is the entire machine.

And yet it feels, briefly, like it understands you. That feeling is worth examining, because real AI language systems start from this same instinct, that words carry emotional weight, and then add everything the word list cannot do. They learn from context that “sick” is praise in “that trick was sick” and a complaint in “I feel sick.” They notice that “not bad” is good, that sarcasm flips meaning, that “great, another meeting” is not great at all.

The meter knows none of that, and says so. It shrugs at sentences with no listed words, it gets fooled by mixed sentences, and it will confidently rate “I am not happy” as sunny because “happy” is on the list. Those failures are the honest advertisement for why the assistant and agent work this lab is chasing matters: the gap between matching words and reading meaning is exactly where useful software gets built.

Try to break it. Paste a sentence that fools the meter, then think about what you understood that it did not. That gap, in one sentence, is the whole research program.

Most chat assistants on websites are a rented language model with a help page taped to it. Pip is a different experiment: how helpful can an assistant feel with no model at all? No AI API, no tokens, no server round trip. Everything Pip knows lives in this page, and everything it figures out, it figures out in your browser tab.

Three parts do the work. First, a knowledge base: a list of topics about this site, each with the words and phrases that point at it. Tools, games, posts, experiments, contact details, plus short explainers on ideas like agents and automation. Second, a matcher: your sentence gets split into words, common filler gets tidied away, synonyms get expanded (photo, image, and picture all count the same), and every topic scores points for the words it matches. The best scoring topic wins. Third, actions: some answers do something. Ask Pip to open the PDF tools and it switches the tab and scrolls you there. Ask for a post and it finds the card and opens it.

Pip also keeps a small local memory. Tell it your name and it uses it next time. It remembers which tools get opened on this device, so its recommendations lean toward what you actually use. That memory never leaves your browser, and clearing your browser data clears Pip's mind with it.

Now the honest limits, because they are the interesting part. Pip cannot reason. It cannot rephrase your question in a smarter way, and it cannot answer anything its knowledge base does not cover. Ask about the weather and it will politely admit defeat and offer what it can do instead. Every miss is a missing entry, not a mystery: the fix is to write a better entry, which is exactly how this experiment grows.

Why build it the hard way? Because a small site does not always need a model. It needs fast, private, predictable help that costs nothing to run and never sends a visitor's question to a third party. Pip is the test of how far plain rules get you. So far the answer is: far enough to run the front desk of this lab. Try asking it how it works. It will tell you the same thing this post just did, only shorter.

Mini Lab is a small block builder that lives in the Experiments neighborhood of this page. The idea underneath it powers most automation software: a chain of simple steps, where each step hands its result to the next. Three kinds of blocks, one straight line, no code.

Step one: add an input. Click the Text input block. A card appears in your chain with a box for your text. Type or paste anything, a paragraph from an email works well. This block is the start of the chain, the trigger in automation language: the thing that sets everything else in motion.

Step two: add some logic. Click Word count. This block takes the text from step one and turns it into a number. Logic blocks are the middle of every automation: they check, change, compare, or trim whatever flows through. Mini Lab also has a contains check (does the text mention a word?), a line filter (keep only lines that match), a case changer, plain math, and a number comparison that can stop the chain early when a condition fails.

Step three: add an action. Click Show result. Actions are how a chain finishes a job: display the value, copy it, download it as a text or JSON file, or pop up a notification. Then press Run and watch the highlight travel down the chain, one block at a time, with a small log narrating each step. The number at the end is your word count.

From there the variations are the fun part. Swap Word count for the line filter and you have a tool that pulls every line mentioning a keyword out of a long document. Chain the case changer into a download and you have a one click SHOUTING file maker. Save any chain with the Save project button and it waits for you in this browser next visit. Export it and you get a JSON file you can share or stash as a backup.

The honest limits of version 0.1: chains run in a straight line with no branches, blocks are a small starter set, and projects live in this browser only. That is deliberate. The experiment is finding out which tiny tools people actually build, and the block shelf will grow toward whatever that turns out to be.

Pick any automation you rely on and take it apart. A phone that backs up photos at night. An email rule that files receipts. A reminder that fires when you leave the house. Different tools, same skeleton:

1. Trigger: the thing that starts it. A time of day, a new file, a button press, a message arriving, a form submitted. Triggers are events, and the first design question is always: what event? Nothing runs before it.
2. Logic: the part that looks and decides. Does this photo already have a backup? Does this email contain the word invoice? Is the number bigger than ten? Logic ranges from a single yes or no check to a chain of small transformations, but it is always the middle step: inspect, compare, change.
3. Action: the thing that happens. Save the file, move the message, show the result, send the note, download the document. One clear outcome a person can point at and say: that is what it did.

Why bother splitting it into three? Because when an automation misbehaves, the split tells you where to look. Firing at the wrong time is a trigger problem. Firing on the wrong items is a logic problem. Doing the wrong thing is an action problem. People who design automations well are mostly people who got good at asking those three questions in order.

It also works in reverse, as a design tool. Take any chore you do by hand for the third time this week and name its three parts out loud. The event that starts it (an email lands). The looking you do (find the attachment, check the amount). The finish (save it, rename it, file it). If you can say all three plainly, the chore is automatable, and you have just written the spec.

Mini Lab, on this page, is this idea with the training wheels visible: input blocks are triggers, logic blocks check and change, action blocks finish the job. Build one tiny chain there and the three part pattern stops being vocabulary and starts being something your hands know.