Putting it together

You have now met both halves.

A block is the noun: structured data with a name, fields and a stable address. A craft is the verb: logic that runs on the sheet.

Either one alone is useful. Together they do something neither can do by itself, and that is what this page is about.

Crafts meet at blocks, not at each other

Here is the part worth slowing down for.

A craft never calls another craft. It writes a block, and some other craft reads that block. Neither has to know the other exists.

That sounds like a small difference. It is the difference between a plugin system that grows and one that collapses. If craft B had to call craft A, then B would need A installed, would break when A changed its function signature, and could never be written by someone who had not heard of A. Instead B only needs to know that somewhere there is a block called line_items with fields sku, qty, price. That is a much smaller thing to depend on, and it is written in the file rather than in a README.

The block is the contract. Its name, its fields and its types are the whole interface.

This only works because the address is stable. If crafts pointed at Sheet1!C5, then a row inserted by the user, a column moved by a third craft, or a sort would quietly move the data out from under everyone. The whole arrangement would last until the first edit. Addressing by (block, field, key) is what makes it survive a real working document.

What that buys you

A craft written on its own is worth one feature. A craft written on a block is worth one feature times every block it can read and every craft that can read what it wrote.

Say you have four small crafts, none of which knows about the others:

1. a table extractor that turns a pasted region into a block,
2. a validator that flags rows failing a rule,
3. a pricing model that adds a computed column,
4. a report builder that renders any block as a summary.

Nobody planned a pipeline. But extract → validate → price → report is a pipeline, and so is extract → price → report, and so is validate → report. Each new craft you add does not lengthen a list; it multiplies the number of chains that already work.

This is the same reason Unix pipes outlived the programs in them. The difference is that a block is typed and persistent: it is not a stream that vanishes, it is a table that is still in the file tomorrow, with its schema attached.

The ceiling, and how AI removes it

There has always been a catch, and it is not technical.

Composition only happens when somebody knows it is possible. A person has to know that craft 3 exists, that it works on the kind of data craft 1 produces, and that running them in that order is the answer to the question they actually have. Most people never find out. So the combinations exist in principle and go unused in practice, and the plugin ecosystem ends up being a list of features after all.

An agent does not have that problem. It can look:

• list_blocks and describe_block tell it what data is in the workbook, what the columns mean, and which rules are attached.
• skills__discover tells it which crafts are installed and what each is for.
• skills__use loads that craft's functions and calls them.

So the agent can see the pieces and put them together, which is exactly the step that used to depend on a person happening to know. It can also make the pieces: create a block, declare its schema, and then run a craft on it.

That is the real multiplication. The number of crafts grows slowly, by hand. The number of useful combinations of crafts grows much faster than that — and until now almost none of them were ever reached. What AI changes is not the size of the toolbox. It is the fraction of the toolbox anyone actually uses.

Why it holds together

Three things make this safe rather than merely clever, and you have already met all of them:

• The address is stable, so a chain does not break when a person edits the sheet halfway through.
• The rules are declared, so a craft that writes nonsense into a block is flagged by the engine rather than discovered three steps later by the craft that read it.
• The policies are explicit, so a block that one craft owns cannot be quietly rewritten by another, and a person can fence off a column that nothing automated should touch.

Without those, "many crafts operating on shared data" is just a shared mutable mess. With them, it is a workbook you can still open in Excel.

Where to go next

• Write one → Write your own craft
• See how far a craft can go → Factory Simulator, an interactive simulation running inside an ordinary workbook
• Why any of this is the right shape → What is real AI-native?