Building without code

What exactly is an AI building block? Let's try to understand. In a simple way. Building without code does not mean nothing runs.

The parts that run are already written. You pick them off a list and drop them on a canvas. One of those parts is a block. A block is a single step that does exactly one job.

Send an email. Summarize a paragraph. Look up a row. Every block has the same three parts.

A slot for what goes in. Settings you fill in. And a slot for what comes out. The job inside is already coded by somebody else.

Your work is the settings. Which mailbox. Which sheet. Which model.

Fill those in, and the step is ready. Blocks come in a few kinds. A trigger, which starts the run. A plain action, like save this row.

And an AI step, which calls a model. The AI step is not special hardware sitting in your canvas. It holds some instructions, sends them to a model, and waits for text to come back. And because every block has that same shape, blocks are swappable.

Pull one out, drop another in, and the steps around it do not need to change. How much should one block do? One verb. If describing your step needs the word and, you are really looking at two blocks.

So, an AI building block is one prewritten step. A slot in, settings, a slot out. You do not write it. You choose it and fill it in.

Quick check now. One question is coming up. Let's see if it clicked.

How does a prompt become an output? Let's try to understand. In a simple way. You type a prompt into the AI step.

Your instruction, and the thing you want worked on, get glued together into one single block of text. Nothing clever runs on your own computer. That block travels over the internet to the model, and your step just sits there, waiting for a reply. Here is the catch.

The model receives one stream of text. It cannot see which part was your order and which part was the material. It only reads words. Then it writes back.

Not all at once. One small piece at a time, each piece chosen after everything written so far. That is why a long answer takes longer. Whatever it wrote lands in the output slot of that step, always as plain text.

Even a tidy looking list is still just characters in a row. Notice what did not happen. Nothing was fetched from a table of ready answers. Those words were written fresh, for you, right then.

Which is why the same prompt can come back worded differently on a second run. A setting called temperature decides how loose that wording is allowed to be. So the output rides entirely on the order you wrote. Name the format.

Name the length. Show one example. A blurry request earns a blurry answer. So, a prompt becomes an output like this.

Glued into one text, sent away, read once, answered piece by piece. Quick check now. One question is coming up. Let's see if it clicked.

What exactly is a connection between two AI steps? Let's try to understand. In a simple way. Drop the second step under the first, and you have only decided which runs first.

The second step's input box is still empty. Nothing was handed over. To hand something over, you click that empty box and pick step one, output. What lands in the box is not text.

It is a tag holding an address. Then, at run time, just before step two starts, the builder replaces that tag with whatever step one actually produced. That swap is the whole connection. A step rarely hands back one lump.

An email step offers a subject, a body, a sender. So you point at one named part. Step one, body. The same address can be used again and again.

Step four and step seven can both paste in step one's answer. And one box can hold two tags at once. Here is where it hurts. If step one produced nothing, the tag is swapped for empty text.

Step two still runs, on nothing, and reports success. And the tag really is only an address. Rename step one, or delete it, and every tag pointing at it now points at nothing. Step two also never inspects what arrived.

It cannot tell a good answer from a wrong one. A mistake made early is carried forward as fact. So, steps talk by address. You point at an earlier output, the builder swaps in the text, and every step after that trusts it.

Quick check now. One question is coming up. Let's see if it clicked.

How does workflow memory work? Let's try to understand. In a simple way. Every run of your workflow starts blank.

It wakes up, does its steps, and stops. Yesterday's run left nothing behind for today's run to find. Inside a run you can park a value in a variable block. But it lives only while that run is alive.

Run ends, value gone. The model stores nothing either. Every AI step meets a fresh stranger. It knows only the text you send it this time.

So memory cannot live in the workflow at all. It has to sit outside, in something that stays. A spreadsheet row, a database table. Which means two ordinary blocks.

One at the end that writes down what happened. One near the start that reads it back. Save, then load. But load whose?

Every saved line needs a key. A customer id, a thread id. You fetch only the rows carrying that key. And a loaded row does nothing by itself.

You still have to paste it into the prompt. Otherwise the model never sees what you saved. That is all a remembering chatbot is. The conversation gets saved, then pasted back in, every single turn.

Feels like memory. Really it is re-reading. Which is why it grows. Ten turns of history make every later call slower and costlier.

So people keep the last few turns, or a short summary. So, workflows remember by writing to a store outside themselves, loading it back by key, and pasting it into the next prompt. Quick check now. One question is coming up.

Let's see if it clicked.

How does giving your AI a calculator work? Let's try to understand. In a simple way. Ask an AI step to multiply two long numbers, and it answers instantly.

Confidently. And often wrong. It never did the arithmetic. Because a model writes text one piece at a time.

It picks digits that look right after the ones before. Looking right is not adding up. So you attach a calculator to that step. In the builder it is a checkbox, or a tool you drag in.

Underneath it is ordinary arithmetic code. Now watch what the model actually does. It does not do the sum. It writes a tiny request.

The tool's name, and the two numbers. Your workflow catches that request and runs the real calculator. Exact answer, every time. The model never touched it.

Then the answer goes back into the model, and it writes the sentence around it. So one AI step is really two trips, not one. How does it know to reach for it? From the description you typed.

Something like, use this for any arithmetic. Vague words there, and it guesses again. But here is the trap. The model still picks the numbers.

Copy the wrong figure out of the invoice, and the calculator returns an exact wrong answer. And it can skip the tool entirely. A tool is an option offered, never an order. Which is why easy sums sometimes come back guessed.

So, a calculator block means the model asks, your workflow computes, and the number comes back true. Quick check now. One question is coming up. Let's see if it clicked.

How does letting your AI browse the internet work? Let's try to understand. In a simple way. A model learned from text collected up to some date, then it stopped.

Ask about this morning, and it answers from that old pile. Confidently. So you add a browse step. That does not put the model online.

It never opens a page. It still reads only the words in your prompt. Your workflow does the visiting. A search block sends words off to a search engine.

A fetch block downloads one address you hand it. And what comes back is not an answer. It is the page as plain text. Headlines, menus, cookie notices.

Then that text is pasted into your prompt, under a line like, here is what we found. The model reads it like any other text. So the search words decide everything. Send vague words, land on the wrong page, and the model will summarize that wrong page beautifully.

A page is long, and a prompt has a limit. So the block keeps a slice. The top results, or the first chunk. Your answer comes from that slice.

Sometimes nothing comes back. A paywall, a login, a page drawn by scripts. The slot arrives empty, the run still reports success, and the model answers anyway. And remember whose words those are.

A stranger's page, pasted in as the source of truth. Nobody checked it. So keep the link, and read it. So, browsing means your workflow fetches text and pastes it in.

The model just reads. Quick check now. One question is coming up. Let's see if it clicked.

How does AI reading your private documents work? Let's try to understand. In a simple way. You drop a PDF into your workflow.

But a PDF is not text. It is a container, bytes describing how to paint a page. So a block opens that box. A document loader.

It pulls the characters out and hands back one long stretch of plain text. The model never opens your file. It cannot. Your workflow opens it, and the extracted words get pasted into the prompt.

Inside a PDF there are no paragraphs. Only characters, each with a position. The loader guesses the reading order, so two columns can interleave. Now a scanned page.

That is a photograph of paper. No characters inside it at all. The loader returns empty text, and nobody warns you. For scans you need OCR.

A separate step that looks at the picture and guesses each letter. Guesses. A smudged five comes back as the letter S. A table is a grid to your eye.

Extracted, it becomes words on one line, headers drifting from their numbers. Charts and stamps vanish. And a hundred page contract will not fit in one prompt. So the text is cut into pieces, and only some travel with your question.

So print the extracted text once, before building on top of it. If it looks like noise, every step after it dresses up noise. So, reading your documents means one thing. A loader turns a file into plain text.

Everything after that depends on it. Quick check now. One question is coming up. Let's see if it clicked.

How does turning words into searchable memories work? Let's try to understand. In a simple way. You save a note.

The launch slipped to March. Later you search for delay, and get nothing. The meaning is there. The letters never matched.

So you stop storing the words alone. Each piece of text goes through an embedding block, and comes back as a long list of numbers. That list is a position. Every piece of text lands somewhere on one big map, and pieces that mean similar things land near each other.

You keep those numbers in a vector store. One row per piece: the numbers, and the original sentence sitting right beside them. Searching runs the same way. Your question goes through the same embedding block, becomes its own position, and the store hands back the closest rows.

Same block both times, or nothing works. Save with one embedding model and search with another, and the numbers sit on different maps. You also pick how many rows come back. Ask for three, you get three, even when only one of them deserved to be there.

Because closest is not the same as right. The store ranks by distance. It never checks whether the sentence actually answers you. And the numbers are a snapshot.

Edit the sentence and its row is stale, still pointing at the old meaning, until you embed it again. So, a searchable memory is text turned into positions. Save the numbers, search by meaning, and get back the sentences that sit nearby. Quick check now.

One question is coming up. Let's see if it clicked.

How does answering questions from your own files work? Let's try to understand. In a simple way. You ask your workflow, what is our refund window.

The model has never seen your policy file. So it answers from the general internet. So the trick is the order. Before the model is called, a search step pulls the few pieces of your file that match the question.

Then your workflow builds one prompt. The instructions, the pieces it just found, and your question. Glued together into a single block of text. The model still opens nothing.

It reads that block. Your answer comes from the pieces sitting inside it, not from the file on your drive. That is why one instruction matters. Answer only from the text above.

And if it is not there, say you do not know. But the model never checks those pieces. Hand it the wrong paragraph and it answers from that, confidently. A search mistake becomes an answer mistake.

So ask for the source. Make it quote the sentence it used, and name the piece it came from. Now you can check in seconds. And when the search finds nothing, that slot arrives empty.

Without the instruction, the model fills the gap from general knowledge. Only those few pieces travel, never the whole file. So an answer is only as good as the paragraphs your search sent. So, answering from your own files is three moves.

Search, paste, then ask. The model reads your paragraphs, and answers only from them. Quick check now. One question is coming up.

Let's see if it clicked.

How does structuring messy AI text into data work? Let's try to understand. In a simple way. Ask a model to read an invoice email.

You get back a friendly paragraph. But your next block needs one thing. The amount, on its own. So stop asking for a summary.

Name the fields you want. Sender. Amount. Due date.

Those exact words become the keys of your data. Then paste an example of the shape. Curly braces, key, value. The model copies patterns, so a sample beats a paragraph of instructions.

Careful though. What comes back is still text. One long string of characters that only looks like data to your eyes. So the builder gives you a parse step.

Text goes in, named fields come out. Now your next block can point at amount. And here is where it breaks. The model writes, sure, here is your data.

That one friendly sentence, and the parse step fails. Which is why builders have a JSON mode. Switch it on and the model is only allowed to write characters that fit the shape. Also ask for every field every time.

When the due date is unknown, you want it empty, not gone. A vanished key breaks everything downstream. And a last trap. The shape can be perfect while the value is invented.

Valid data is not correct data. So check the value yourself. So, structuring text is three moves. Name the fields, lock the shape, then parse.

And check the values before anyone trusts them. Quick check now. One question is coming up. Let's see if it clicked.

How does an if then decision work? Let's try to understand. In a simple way. One message is a furious complaint.

The next just asks about your opening hours. Same workflow, but they should not take the same steps. So the builder gives you an if then block. One entrance, two exits.

A true exit, and a false exit. Inside, you fill three boxes. A value, a comparison, and what to compare it against. Priority, equals, urgent.

And your builder runs that rule, not the model. At the fork, only one side runs. The blocks hanging off the other exit are skipped completely. They never even start.

But where did priority come from? From an earlier step, where you asked the model to reply with one word. Urgent, or normal. Here is the trap.

Equals compares character for character. Urgent with a capital U, or a trailing full stop, is not equal to urgent. So clean the value first. Trim the spaces, drop the capitals, and hand the model a short closed list to pick from.

And never leave the false exit empty. Every run has to land somewhere. An unwired exit is a run that quietly stops. One last thing.

The fork is exact, but the label is a guess. Borderline messages flip between runs. So send the unsure ones to a person. So, an if then block is a fixed comparison with two exits.

Your builder decides. The model only supplies the word it reads. Quick check now. One question is coming up.

Let's see if it clicked.

How does a repeat step work? Let's try to understand. In a simple way. You built one workflow that summarizes a review.

Now two hundred reviews land in a spreadsheet. You are not running it by hand. So the builder gives you a repeat block. Some call it for each.

You hand it a list, and it runs the steps inside once per item. But it needs a real list. Two hundred separate rows, not one long block of text. Hand it a blob, and you get a single pass.

Inside the loop you point at the current item. That tag means this pass only. On pass three it holds row three. The passes run one after another, in order.

Pass one ends, then pass two starts. Nothing inside sees the other rows. Every pass makes an output, and the loop gathers them. What leaves the bottom is a list of results, one per row.

Here is what people miss. Each pass is a fresh call. The model does not remember pass one while it runs pass two. So a running total lives outside the loop.

And a loop multiplies everything. Two hundred rows means two hundred calls, two hundred waits, two hundred charges. Test on three rows first. One bad row can stop the whole run.

The loop halts, and the rows behind it never run. So catch the error inside and carry on. So, a repeat block takes a list, runs the same steps once per item, and hands back a list of results. Quick check now.

One question is coming up. Let's see if it clicked.

What exactly is a form trigger? Let's try to understand. In a simple way. A workflow does nothing on its own.

It sits there, waiting. Something has to press start, and that something is called a trigger. The friendliest trigger for a person is a form. You drop a form block at the very top.

It has no input slot. Only an output. You build the form by naming its fields. Name, email, and your question.

Each field becomes a box on the page. The builder hands you a link. That page is your form. Anyone who opens it can start your workflow.

When somebody presses submit, one run begins. One submission, one run. No submit, no run. The workflow just waits.

And the answers arrive as the trigger's output. One value per field, addressed by the field name you typed. Your next block reads them like any step's output. Mark a field required, or make it a dropdown, and the builder checks it right on the page.

A blank one bounces before your run even starts. But your link is a public door. Whatever passes the check is a stranger's words landing inside your prompt. Keep the fields narrow, and treat what arrives as data.

The person does not wait inside your run. Once they submit, the page can thank them at once, or hold until the workflow finishes. That ties them to your slowest step. So, a form trigger is a door.

One submit starts one run, and the fields walk in as named values. Quick check now. One question is coming up. Let's see if it clicked.

What exactly is a schedule trigger? Let's try to understand. In a simple way. You do not want to press start every morning.

But a workflow never moves on its own. Something has to press it. So you drop a schedule block at the very top. It has no input slot.

What fires it is a clock, not a person. You set the rhythm. Every day at nine. Every fifteen minutes.

Every Monday morning. The builder wakes it at each of those moments. Now look at what this trigger hands down. Almost nothing.

Just the moment it fired. Nobody typed anything, so there is no question to answer. So your first step has to go and get the work. Read the spreadsheet.

Search the inbox. The clock says when. Your block says what. And a clock never notices a change.

It wakes up and looks. An email landing one minute after nine waits until the next fire. Every fire also starts clean, so it sees yesterday's rows again. Mark each row done, or you will send the same email twice.

Check the timezone too. The clock runs where the builder lives, not where you sit. Nine there can be the middle of your night. And nobody is watching a run at three in the morning.

It can fail quietly for a week. So have it message you when it breaks. So, a schedule trigger is a clock at the top. It picks the moment, and your first step fetches the work.

Quick check now. One question is coming up. Let's see if it clicked.

What exactly is a workflow API? Let's try to understand. In a simple way. Until now a person started your workflow.

A click, a form, a clock. Now you want another program to start it. So you swap the trigger for a webhook block. The builder hands you a web address.

Anything that can send a request there starts your workflow. The caller sends a request to that address. Inside it, a small package of named fields. Those fields land in your first step.

Here is what people forget. The workflow has to send an answer back. A respond block at the end decides what the caller actually receives. Now you own a contract.

The field names going in, and the field names coming out. Their code is written against those exact names. So renaming one field quietly breaks every caller. Their code asks for summary.

Your workflow now says result. They read an empty value, and nothing errors. That address is a public door. Anyone holding the link can run your workflow.

So the very first step checks a secret key. And every call runs on your account. Their traffic, your model bill. A cap on calls per minute lives in your workflow, not in their code.

And the caller is waiting on the line. Most requests give up after about thirty seconds. If yours is slower, answer at once and deliver later. So, an API turns your workflow into a function other software can call.

An address in, a fixed answer out. Quick check now. One question is coming up. Let's see if it clicked.