If you teach an AI agent to work the way you do, have you built your replacement or your best tool? Why that copy should belong to you.

I have taught a machine almost everything I know how to do at work. I taught it by correcting it, one rule at a time, such as the rule that, whenever I offer a client two dates, both are held in my calendar until they reply. Today it works in a way I recognise as mine, and I don't know whether I have built my replacement or the best tool I have ever had.

Something like this happened once before. More than a century ago, Frederick Taylor needed stopwatches and engineers to get workers' knowledge of their trade out of their heads, and that knowledge, which he himself called the principal asset of every tradesman, became the company's. Now I hand mine over of my own accord, and so does anyone who corrects an AI agent.

I think it can end differently this time. The machine can learn every rule I teach it, but only I can see the next one it needs. And if that copy of me is mine, it works for me and keeps what I have taught it, including what I have since forgotten. I believe every person should own theirs and be able to take it with them when they change jobs.

My company, Hellomatik, builds agents for other companies, and I delegate almost all of my own work to our agents, so I am not a neutral observer. Nor can I know what work will look like in ten years; nobody can, and much of what follows is a bet, though one placed on what I measure every day.

Continue reading

For eight months I worked almost entirely through Claude Code, at times with nine sessions running at once. I never trained as a programmer, and most of the software I use every day I built myself with it. Every message I wrote was still on disk, so I measured what actually changed how the agent behaved: the model, the rules I wrote for it, or the guards that block it when it breaks one.

What the record shows

These findings come from one person's record, with one tool and one vendor; the paper gives the intervals and the limits.

A model release changed the agent's behaviour as much as my strongest combination of rule and guard. In the week Claude Opus 5.5 came out, 18% of its first drafts broke my writing rules. Claude Opus 5, under the same rules and on the same days, broke them in 57% of its first drafts, and the gap held inside the sessions that used both.

For the one rule I could follow through three stages, writing it down was not enough. The share of drafts in the wrong language went from 16% with no rule to 10% with a written one, a fall that may be down to chance, and to 3% once I restated the rule more firmly and added a guard to check it.

Guards filtered what reached me without improving what came after. The writing guard took about half of the violations out of the answers I read, but after a block the agent's next drafts in the same session were no cleaner.

My own work changed shape. Corrections fell from about a third of my messages to under a tenth, and messages asking the agent to keep going rose from one in twenty to one in five. The models, my habits and my tasks all changed over those months, so this describes my work rather than isolating a cause. My own output also had a ceiling: with seven or more sessions open I wrote about 21 messages an hour, and the share spent on supervision did not depend on how many sessions were running.

I also build applications in which you mainly work by talking to an agent with a defined job: an options terminal, an email client and a studio that writes blog posts. In each one, the screens and the agent read and write the same data. Those agents got more new work and less supervision from me than development sessions did, though the difference may be chance.

What it says about what I believed

In "The machine of the future" I wrote that as machines take over execution, a person's work moves to intention: deciding what is worth doing. The record is consistent with that. I spend less of my time fixing the agent's work and more of it keeping the work moving.

In "The end of software" I wrote that an agent should keep each correction as a rule. Here the record forces me to qualify what I wrote. For the rule I could follow, writing it down was not enough; it held once I restated it and a guard checked it every time, and the newer model broke my rules far less often than the older one.

Abstract

Companies govern coding agents with written instructions and, increasingly, with hooks that block an action when it breaks a rule. This study measures what changed the behaviour of Claude Code over eight months of daily use by one operator with no training in programming who directed many sessions at once, using 46,464 operator messages, 1.3 million agent messages and 3,411 recorded blocks. A fixed instrument applied the rules of one guard to every surviving answer, including those written before the guard existed. In the week Claude Opus 5.5 was released, it broke the operator's writing rules in 18% of first drafts and Claude Opus 5 in 57%, a gap that held within the same long-running sessions. For one language rule, a written instruction was followed by a fall that could not be distinguished from chance, and a reinforced rule with a guard by a fall to a sixth of the starting rate. Blocks roughly halved the violations that reached the operator, with no detectable effect on later drafts in the same session. Supervision accounted for a third to a half of the operator's messages throughout, while its content shifted from corrections to nudges to keep working. Agents built into the operator's own applications, each with a defined role and sharing its data with the application's interface, received more new work and less supervision than development sessions, a difference within chance.

Keywords: coding agents; AI agent governance; runtime guardrails; instruction following; human oversight; agentic software engineering.

The paper

The full study is a 32-page working paper: What changes a coding agent's behaviour: models, written rules and runtime guards over eight months of daily use of Claude Code (PDF, October 2026, self-published, not peer reviewed). It covers 46,464 of my messages, 1.3 million messages from the agent and 3,411 recorded blocks, and it states its own limits: one operator, one tool and one vendor, and a classifier whose labels were checked by a second model and validated by me. The analysis scripts and the tables behind every figure are published with it on Zenodo. My messages are not, because they contain client work.

It is deposited on Zenodo with a DOI, 10.5281/zenodo.23510601, so the file will still resolve when this site does not. To cite it: Correa, I. (2026). What changes a coding agent's behaviour: models, written rules and runtime guards over eight months of daily use of Claude Code. Working paper, Zenodo. https://doi.org/10.5281/zenodo.23510601

Isaac Correa, Madrid. ORCID 0009-0003-0657-4419.

A manifesto, October 2026. Also as a PDF. It carries the DOI 10.5281/zenodo.23468806.

These days, isn't software the least valuable thing a software company owns?

I think software as we know it is coming to an end. Anyone can now build it, copy it or replace it, and whatever anyone can build stops protecting the company that sells it. What's left is whatever you can't download, which means well-structured data and genuinely complex solutions, and above all relationships with people.

I'm writing from daily experience (I built 80% of the software I use myself, and I don't know how to code), so I'll start with why code no longer protects anyone, then the gold rush that almost everyone building AI apps is reliving, and what software has to look like once an agent can do the work for you. After that come the one thing that can't be copied, the people companies are going to need, and the industries worth fighting in.

Code no longer protects anyone

The software I've built includes a program that manages the terminals where I run my AI agents, an AI-powered native Mac app that labels my email, answers it and sets up meetings, and a program that pulls data straight from Nasdaq and analyzes entire options chains, Greeks included, to find the best contracts and tell me whether they're actually worth trading. I used to pay a subscription for every one of those, and now I build them myself.

If someone like me, with no programming background, can build those tools, polish them to my liking and get them running, don't you think any company could? And what happens when every company embraces AI and nobody outsources software anymore? Plenty of companies will drop HubSpot the day 300 extra leads push its account into a higher contact tier and a bigger monthly bill.

The markets have already noticed. As I write this, in mid-October 2026, HubSpot is down 42% year to date and Monday.com is down 39%, while Shopify was down 41% at one point this spring. The selloff even has a name now, the SaaSpocalypse, which is shorthand for the fear that AI agents able to do the work on their own will make per-seat licensing obsolete.

That makes sense to me, given that there's an open-source option for almost everything and cheap AI models that answer questions and write code. Software has been losing value layer by layer: first the frontend (now very easy to build), then the backend, and finally infrastructure and operations. Now add REA (Reverse Engineer Anything), an open-source tool that lets an AI agent reverse-engineer any app installed on your computer, even one from a company worth hundreds of millions of dollars, and then build you your own version. Small businesses are already asking the obvious question: why pay hundreds of euros a month for third-party software when a tool like that exists? Code doesn't work as a moat anymore, and generic SaaS has gone down with it.

Everyone is digging for gold, and only the shovel sellers win

And yet almost everyone keeps building software expecting to sell it. I was stuck in that trap for months, seeing AI as a way to supercharge my ideas and build solutions for companies faster. All I was really doing was building traditional solutions with AI instead of accepting that we don't have to keep building the same thing.

Right now the default move is to pay $200 a month for an AI coding tool and use it to build general-purpose software that anyone can adapt. The result looks exactly like fast fashion, a market drowning in supply, full of sloppy, disposable products. I think there's a bubble in business AI apps that all look alike, with nothing innovative about them, trying to sell a solution today that would have been fantastic six years ago. Lots of people are building, very few are making it and almost nobody is selling, because when everything is this easy the only thing left is a price war. The moment a rival ships a feature, markets it better or is simply cheaper, you have to match it, and it gets so competitive that you can't grow. You stop thinking about growing and start thinking about holding on, and that's a war I won't fight.

It reminds me of the California gold rush, when people came from all over the world to strike it rich, and in the end the only ones who got rich were the ones selling shovels. Today the shovels are the AI models that write code, the data centers and the chips. Everyone knows that part. For anyone building software, though, it means that every $200 monthly subscription someone pays to build generic software and sell it is a shovel sold, and the seller gets paid every time, whether the digger strikes gold or not. And the gold, meaning generic software, is now worthless, because everyone is digging with the same shovel and pulling out the same thing. What I mean is that you shouldn't be just another sheep in the herd, building software for nobody. Or for everybody. I think it's idiotic to start a company building an agent that does everything, because an agent built to do everything ends up doing nothing well.

Why five apps and not one?

Take my own case.

I don't like Outlook, Teams or Calendar, but I need them every day, and inside them I only do a handful of things: send emails, save drafts, schedule sends and book meetings. Why would I do that in an app with 300 features? The logical move would be some version of the Pareto principle, keeping the 20% of features that handle 80% of the work. That's how most people are approaching it, and on top of that they bolt an agent onto a panel on the right. Great.

We keep working like this only because that's how it's always been done. I'm not talking about Microsoft or HubSpot in particular; I'm talking about SaaS in general. If after years on a platform you can't improve it, or you can't think of a single way to make it fit you better, you haven't thought about it enough. SaaS is built for the masses so that it works for everyone, but why should we use a system where we have to click around and spend hours managing it? Can't we just forget traditional SaaS and embrace the new era?

In that new era, the agent works inside the app itself. It can perform every action the app offers, it moves between screens, it understands context and it writes like you, because while you were building it you gave it all your emails so it could learn your style. If you can build that, why would you treat AI as an add-on rather than the core of the product? Why can't you just ask it what to do, how to do it or what to reply, instead of digging through your inbox?

The agent and the interface draw on the same data. This agent oversees the work and carries it out, and it can do anything the app can do, because it works directly on the app's data and actions rather than on buttons someone designed for everybody. You teach it and give it rules to follow. For example, I told mine that whenever it proposes two dates in an email, it should create a calendar invite for each one with "(TC)" at the start of the title, for "to confirm". That way, while I'm waiting for the client to tell me which slot works, I don't book another meeting on top of it and then have to tell them the slot is gone, which makes me look bad. You can ask it to alert you about anything at all, not just whatever a list of preset options allows, and every time you correct it, it learns. Because it knows the whole app, when you ask for something that doesn't exist yet, it puts it together from the actions it already knows, so the agent ends up building itself around you. Why fight an interface and features you don't care about when it can do that for you? I made this point in my essay "La máquina del futuro" (The Machine of the Future): the machine of the future is the tool that can take action in the real world simply from a plain-language description of what you need.

That's why I'm proposing a new way of working, where the interface stops being where you act and becomes a live view of what's happening. The agent acts, and I sit next to it, watching and correcting it as it goes. Email and the stock market aren't going anywhere in the next decade, and neither is the habit of running AI alongside them.

All these new AI companies want to take us back to the same old thing. On a typical day I already juggle four different apps, and every one of these new AI companies wants to be the fifth. And why do I need five in the first place? Why not two, or just one of my own that handles everything while I keep an eye on how it behaves and spend my time on more interesting, more creative things? We have to stop building 2010-era software and start building connected, intelligent software that lives outside conventional apps.

The only thing that can't be copied

If code doesn't protect anyone anymore, what does? A small company will build its own software with its own AI specialist. A big one, before it builds anything, needs data infrastructure across the entire company. That's why I've focused on what I think is hardest to replace: very complex solutions for very large companies. It sounds obvious, even easy to replicate, until you realize that a single solution means integrating with 15 different APIs, setting up your own databases and building flawless data pipelines so the AI doesn't hallucinate. AI writes the code for all of that too, these days. What no model can hand you is an understanding of a large company's data, or the trust it takes for that company to open its data up to you. The fact that someone who can't code built all of my own software is proof enough that code isn't the hard part anymore.

That's where the human relationship comes in, and I don't see it going anywhere. In that same essay I wrote that a company's value lies in the people who work there, and always will, however far technology advances. I think software will become increasingly custom-built, developed together with the client company, with outside partners working inside the business to solve its problems. Unless an idea is truly disruptive, I don't think generic software has much of a future, because the market for generic tools is already saturated with people and companies selling software. A company hands its data to someone it already has a relationship with. That's why I say relationships are everything: anyone can copy a vendor's code, but the relationship stays with whoever knows the client's data and problems.

So I believe the right order is to build the company's own data infrastructure first, across the whole company and with proper data governance, and only then build specific apps for the company or for one department on top of it. Whatever progress we make as a society will come from the average company having better-structured, more complete data, much more than from having more tools. Instead of trying to build better CRMs or ERPs, like everyone else, we need to build solutions that make sure a company never needs a CRM again, with specific apps for specific employees.

Who wants to hire a HubSpot expert, pay thousands of euros for a new employee and, on top of that, keep paying thousands more every month for a platform that sits on your data and locks you into its services? When the system is yours, your data can live on your own machines in your own office, and you don't have to worry about where it ends up. Isn't getting out of that one of the greatest advances in history?

Every company's Avengers

Companies will gradually stop adapting to generic software that someone else built for everyone, and they'll start building their own, because the barrier to entry is minimal. In small companies, one prompt engineer will do all of that work, and in large ones there will be one in every department, responsible for every pain point their colleagues have. They'll be the company's Avengers, the people who modernize it and do the work that actually moves it forward, and they'll put an end to SEO, to junior roles and to the high cost of paying people for repetitive tasks. That doesn't mean you stop hiring; you'll hire people for how they think and for their potential to grow inside the company, not for being better at a mechanical task, since a system trained for that can already handle it.

I know plenty of companies still resist change, or haven't been exposed to AI much, and see it as a chatbot that answers questions. They don't see everything it can do when it oversees and carries out the work of an entire department. But those same companies are swamped with day-to-day work, and they'll be increasingly open to hiring real experts who can handle their data, because their Avengers can't build anything on top of data nobody has organized. I'm just a little ahead of the curve because I use AI heavily every single day.

No pirates and no price wars

If relationships are everything, it matters a great deal who you have them with. Some industries have far more complex problems than others, and plenty are much better bets than marketing.

I know this is going to annoy people, but I see marketing agencies as pirates. They take other people's services and resell them to the end client, adding management or content on top. They don't actually make anything (the only thing they really market is themselves). They're ruthless on price, because their whole business is margins and client management. They'll fight over every last euro, and they'll always go after your margins, because that's exactly their job: negotiating on both sides of the table. I've seen this firsthand at other companies, and while not every agency is like this, most of the ones I've dealt with are loyal to no one. They set false expectations that someone else has to deliver on, they're extremely demanding and they're rarely grateful. They're masters of reselling and negotiating, but that doesn't mean you have to do business with them.

They take that pressure from their own clients and pass it down the food chain, and whoever builds software for marketing walks straight into the middle of it. With this much competition, the whole sector has turned into a battle of pirates. And trust me, you wouldn't want to be on anyone's ship.

Competition leads to mediocrity rather than success, which is why I prefer industries like healthcare, defense or transportation, where the problems are more serious, where you don't compete on price, and where you can grow as far as you need to without always having a market leader to beat. In those industries, keeping your data on your own machines, where it never leaves your hands, matters even more. As Peter Thiel put it, "Competition is for losers."

Software adapts to you, not the other way around

No more adapting to software, buying licenses and learning how to use it. If there's one thing I want people to take away from all this, it's that software isn't worth anything anymore and relationships are everything.

Sources

Share prices: Yahoo Finance (HubSpot, Monday.com, Shopify); the year-to-date change is the close of October 16, 2026, against the close of December 31, 2025, and Shopify's figure is its low of May 2026. SaaSpocalypse: Peter Cohan, Forbes, February 6, 2026. HubSpot contact tiers: HubSpot Knowledge Base, "Set contacts as marketing". REA: github.com/morluto/rea. Peter Thiel, "Competition Is for Losers", The Wall Street Journal, 2014. The essay quoted is The machine of the future.

The first year of Hellomatik: what we built, what we published, what we learned, and what we bet

Madrid, September 2026. Hellomatik was incorporated on 28 July 2025, so this is the first September on which there is a year to account for. I am Isaac Correa, one of its co-founders, and I intend to write one of these every September: what we built, what we published, what we learned, and what we bet. Everything in it is either already published with a date on it or can be checked at the place the link goes to. Where it cannot be checked, I say so.

Where the year started

The company started from a habit rather than a plan. Between December 2022 and November 2024 I delivered three hundred Looker Studio dashboards for clients, one commission at a time, starting with a first sale of seven dollars on the last day of 2022. Almost nobody in those three hundred jobs asked me for a chart. They asked a question about their own business and hoped a chart would answer it. The ones who left happiest were the ones who could finally say a sentence out loud about their own company and know it was true. That is the habit: the interpretation goes next to the number, and a number nobody can read is decoration.

Something else was true in every one of those companies. The most valuable information in the building was not in any system. It was in the head of the person who reconciled things by hand every day: transport invoices against shipments, the sales figure of the month that comes out different on every screen, which orders did not leave yesterday and why. Hellomatik exists to write that down.

The first version was a system that answered restaurant phone calls: a voice on top of a database. It repeated what was in the record accurately, and when the record did not contain the answer it produced a plausible one in the same even tone. The two well-known fixes, looking things up instead of recalling them and saying “I do not know”, helped and decided nothing: they do not decide which of three disagreeing systems is believed about a given field, and they cannot look up the conditions a business applies every day and has never written anywhere. Before the software, then, there is a document. That document is what the year went into.

What we do, in four sentences

We set out how your company works: its data, its rules with their exact constants, and who may do what. We read your systems without writing to them. The agents only do what you approve: every action is declared in the map and authorised by you. And every figure we publish comes from a case measured at a customer’s site, and every case is published with what it does not show.

Those are the four sentences we repeat everywhere, on purpose, and I do not expect them to change. The language model is the last piece, not the first: models are a commodity, and one can be swapped for another in an afternoon. Data, everybody has. What almost nobody has is a living, governed model of how their company works. The model can change. The governance cannot.

What is running

The technical report states the scope of what the method runs on rather than implying it, and I repeat that scope here because it is the only part of this letter that is not an argument. At the time the report was written, three systems were running and one was open to the public, each on a different rung of the ladder from answering to watching to acting, and each with its limit published.

Those are counts of what the systems run over, not of what they improved. The measured results are published case by case on Hellomatik’s site, each with what it does not show, and without naming the installation. A few of them, in the form the cases use. In an automated warehouse we measured, an order takes three minutes to pick and four and a half hours, at the median, to reach the person who picks it; nobody had measured that wait before, because it lived between two systems, and it is a measurement, not a result: it has no “after”. In the same installation, 41 per cent of the emails in the customer-service inbox were people asking where their order was; now a list of what did not ship yesterday arrives every morning with the cause, and whether that percentage falls is measured from the day the client signs the channel open. Closing a year of transport invoices, 180 a month in 30 formats, takes eight minutes, where it used to take days of a person who knows what they are doing. And 2,132 orders were held with no reason recorded anywhere, which is not a failure of the people; it is what happens when the map is in their heads and not on paper.

If we cannot name the customer, we say “an automated warehouse” or “a distributor that sells to other businesses” and keep the number. The number is the proof; the logo is not.

What we published

We chose to publish the method as a technical report with a DOI rather than as a brochure, because a technical report can be cited, checked and taken apart, and a DOI puts a fixed, dated version of the text in a repository that is not ours. The people we want reading it, operations directors, systems people, the person in a company who is quietly responsible for the ERP, read papers.

Three works carry a DOI. How we build a company’s ontology is the method itself: six layers, twelve rules the engines enforce, and one procedure that builds the model backwards from the first agents, deposited as 10.5281/zenodo.22647735. The machine of the future was written in November 2025 and published in September 2026 without changing a line, so that the date on it means something; it is where I set down what I think the next tool is and what it will always need from us, at 10.5281/zenodo.22671771. And The cliff of innovation names the point where the hard part of building something new stops being building it and becomes integrating it, and states the limit we found at the edge, at 10.5281/zenodo.22704763.

In September I put all of it in one order, in a long essay called The map of a company: nineteen sections with notes, drawn only from those three documents, the pages of this site and the sources they cite, with nothing added that is not in them. If you read one thing from this year, read that; if you read one section of it, read the one on which actions can be undone: the group of actions nothing puts back is usually the shortest list a company can write, and it is the one that decides how much a system may do.

The rest of what I have written is short and lives on this site: the first week, when two competent people give two confident answers to the same question; four questions a company can put to its own people before any software; the vocabulary, each word with what it is not; and the pieces on the people I look for, why a product is aimed at one person or at nobody, and why the tool exists before it is built. Everything published away from this site is listed in one place.

What we learned

The report records three findings that changed the procedure, and they are the most useful paragraphs in it. Language turned out to be a property of the visitor, not of each message, and is now session state with a written precedence, tested before anything is switched on. A phase that depends on people acquiring a new habit, such as copying an inbox in, is not data; it is an assumption, and it now gets written down as a risk before the work starts. And at a manufacturer selling through subsidiaries, the field that looked like the customer identified who gets invoiced, not who buys: column names lie, and their contents almost never do, which is the entire reason the second step of the procedure is to read a real sample of records before naming anything.

Two things were confirmed rather than learned. The one requirement to start is not technical: somebody inside the company has to be able to say, for each decision under discussion, what the right answer is and why, because that is what the model writes down; if that person does not exist or has no time, the project stops there, and it is better to learn it on day one than in month three. And the limit of a system that acts inside a company is not the model and not the computing power, both of which improve every month without our help. The possibilities end where the creativity of the last person who uses it ends. The product’s job is to make asking easy. The company’s job is to have people who ask.

What we will not do

A letter like this is more useful for what it rules out than for what it promises, so here is what the rules cost, said plainly. Your team does not pull a new report on its own: every business question is a function written by hand, with its formula, because a free report generator produces reports that cannot be compared with each other. There is no forecasting with trained models: the signals are explicit rules that the person responsible can argue with and change. The initial load runs at night and takes hours; an agent takes time to switch on, because it is not activated without a frozen baseline, a stop rule and a rehearsal; and the daily series reach yesterday, not now. No agent writes except through a typed action declared in advance, and no limit lives in a prompt, because a limit in a prompt is a request to the model and a limit in the data is something a person can read, audit and change without redeploying anything.

We also do not name clients, and we do not publish a price. The licence is for the whole company, with unlimited users, and the figure is agreed in the first meeting.

The bets

A description that predicts nothing is a story, so the predictions carry dates. I keep the ones I have put a date on in one place: four so far, all due in 2028, three from the working paper on the cliff and one earlier, on X, each with where it was said and how anyone can check it. Next September this letter will report on them as they stand, and when the date comes, the row on that page will say held or missed, with the original wording untouched.

The people

I do not choose people by their grades or their titles. I look for two things, and neither of them appears on a CV: someone who does not care what other people think of them, including me, and will say what they see instead of what they guess I want to hear; and initiative shown where nobody asked for it, something small built on their own, or an idea tried and not reached, with the exact place where it stopped. People with both signs are rare, and they are worth four of anyone else, not because they work four times as hard but because they need to be told once, they notice what nobody assigned, and they keep the rest of the room honest without meaning to. Being resourceful makes you a better machine. Being hungry makes you a better human.

The engineer who sits in the meeting is the engineer who writes the code, and stays. That is the whole difference between us and a consultant who delivers a report and leaves, and it is the argument a large company cannot make.

Where this goes

The ambition is to be the reference company for this category in Europe, starting in Spain and entering each country through the subsidiaries of the clients who are already there. I say that as an ambition of our own, without comparing us to anybody by name.

And the end the map serves has not changed since I wrote it down in November 2025. Running a company will stop being a manual, fragmented activity spread across many separate tools; when a task is repetitive, can be expressed as rules and is necessary for an organisation to keep going, sooner or later it gets automated. What stays human is the deciding: the value of a company is the people who work in it, and all of this works only with a human component in its decisions. A company, to me, is like a child: if you look after it, it grows, and it needs you every day. Anyone who owns a small business knows the wish to step away for a few days and come back to find the clients answered and the work done. What we are building is what lets that child grow on its own. Put without the metaphor: the difference between having a business and being tied to it.

That is the year. A voice that answered the phone became a document a company can act on; the document became a method with a DOI; the method is running, with its limits written down, in four systems; and the argument is now in one place, dated, so that it can be disagreed with in detail. Next September I will write what held.

Isaac Correa
Co-founder, Hellomatik
Madrid, September 2026. ORCID 0009-0003-0657-4419.

I am Isaac Correa, co-founder of Hellomatik. A prediction without a date is an opinion, and an opinion cannot be wrong. This page keeps the predictions I have put a date on, each with where I said it and how anyone can check it when the date comes. Nothing here is edited after the fact: if a bet turns out wrong, the row will say so, with the date it was settled.

Four bets so far, all of them due in 2028. They are the ones already published in my own words elsewhere; this page only collects them.

How this page works

A bet enters this page only after it has been published somewhere with a date on it, in my own words: a paper with a DOI, a post, a page on this site. The row links to that place, so the wording here can be checked against the original. When the date comes, the status changes to held or missed, with a sentence on what happened, and the original wording stays. The long version of the reasoning behind bets 2 to 4 is in The map of a company.

Isaac Correa, Madrid. ORCID 0009-0003-0657-4419.

What a business has to write down before software may act inside it, and what changes once it has

I am Isaac Correa, co-founder of Hellomatik, in Madrid. Since 2025 I have been publishing the pieces of one argument in separate places: a technical report with a DOI, two working papers, and a set of short pages on this site. This essay puts the pieces in one order.

It says what I think a company has to write down before software may act inside it, why almost no company has written it, what the writing costs, and what changes once it exists. Everything in it comes from those published documents or from the sources they cite; where a figure comes from a client system, it is stated with what it does not show.¹

Continue reading

My name is Isaac Correa, and I do not choose the people I work with by their grades or their titles. I look for two things, and neither of them appears on a CV. Here is what they are, and why I trust them more than the paper.

Why grades stopped being the signal

For a long time the marks and the title were a fair shortcut. They told you that someone could take in a fixed body of knowledge and reproduce it under pressure, and that used to be most of the job. Artificial intelligence now reproduces fixed knowledge better than any of us, and it does not get tired. The shortcut has not become useless, but it has lost most of what it used to measure.

What the work needs today is not intelligence in that sense. It is ingenuity: the ability to do a task that did not exist last year, with tools that did not exist last month. Nobody has a certificate for that yet, so I stopped asking for one.

The first sign: they do not care what you think of them

The first thing I look for is someone who does not care what other people think of them. That includes me, the person sitting across the table. Not rudeness; independence. Someone who says what they see instead of what they guess I want to hear, and who will keep saying it after they have joined.

That person will tell me when I am wrong. A company where nobody tells the founder he is wrong still finds out, only later and from a client. I would rather hear it on a Tuesday from someone in the room.

The second sign: something done outside the classroom

The second thing is initiative shown where nobody asked for it. Somebody who built something small on their own. Somebody who had an idea, tried to make it exist, could not, and can tell you exactly where it stopped. That last one counts as much as the first. The person who tried and did not get there has learned more about making things than the person who never left the syllabus.

What they made does not have to be good. It has to be theirs, and they have to be able to talk about it for ten minutes without notes.

Worth four

People with both signs are rare, and when I find one I have stopped pretending otherwise: they are worth four of anyone else. Not because they work four times as hard. Because they need to be told once, they notice what nobody assigned, and they keep the rest of the room honest without meaning to.

Two kinds of good

There is a line I use to explain the difference, and I mean it literally. Being resourceful makes you a better machine. Being hungry makes you a better human.

Resourceful is valuable: problems get solved, things get shipped. But a machine can be resourceful now, and it gets more resourceful every month. Hunger is the part that does not come from a manual. It is wanting the thing to exist badly enough to do the work nobody assigned. Every person I would want beside me on a hard week has the second, and the first followed on its own.

Isaac Correa, Madrid. ORCID 0009-0003-0657-4419.

There is a point in building something new where the hard part changes. I am Isaac Correa, co-founder of Hellomatik, and I have a name for it: the cliff of innovation. This is what it is, why we walked toward it, and what we found at the edge.

The easy road

When Hellomatik began, the easy road was clear. Take one of the tools that already existed, add our own touch, and sell it. Thousands of companies did exactly that in 2023 and 2024, and there is nothing wrong with the choice: it is fast, and the risk is known in advance.

We went the other way. Each time we tried to take a step forward and see how far a tool like ours could actually go, we got a little closer to a place I started calling the cliff.

Where the cliff is

The cliff of innovation is the point where what you want to make is either not invented yet, or has to be assembled from so many different parts that the difficulty stops being building it. The difficulty becomes integrating it: putting the parts together well enough that what you have looks like one ecosystem, and not like a Frankenstein.

That is the whole definition, and it took me a while to see how much it explains. Most of the parts exist. A model that understands speech, a model that understands language, a database, a phone line, a calendar, a mailbox. What does not exist, for any given company, is the thing that makes those parts behave like one system that knows that company: what is true, which rules it already follows, which actions can be undone, who is allowed to approve what.

Why integration is the real work

Bolting parts together is easy and it shows. You can tell a Frankenstein from across the room: every seam is visible, every part has its own idea of what a customer is, and the person using it has to translate between them in their head. An ecosystem is the opposite. The seams are inside, the parts agree about the world, and the person using it only has to say what they want.

Getting from the first to the second is where most of our year went, and it is why we published the method as a technical report with a DOI rather than as a list of features. Features are the parts. The method is the integration, written down so that somebody else can check it.

The last person

Standing at the cliff, you also find out what a tool like this is really limited by. It is not the model, and it is not the computing power; both get better every month without any help from us. I said it once without planning to, and it has stayed true since: the possibilities end where the creativity of the last person who uses it ends.

A tool that can act inside a company can only do what somebody inside that company thought to ask of it. Which leaves two jobs. The product’s job is to make asking easy. The company’s job is to have people who ask.

The long version

This page is the short version. The argument in full, with the four things that are missing in every company, the five seams of a badly integrated system, a worked example of the permission table, the scope the method is running on, three predictions dated for 2028 and the paper’s own limits, is a nine-page working paper: The cliff of innovation: why integration, not construction, is the hard part of building a system that acts inside a company (PDF, September 2026, self-published, not peer reviewed). It is deposited on Zenodo with a DOI, 10.5281/zenodo.22704763, so the file will still resolve when this site does not.

Isaac Correa, Madrid. ORCID 0009-0003-0657-4419.

I am Isaac Correa, and I learned this selling, not building. It is the difference between two sentences, said to the same person about the same product, and only one of them worked.

The sentence that sold nothing

Early on, when I sat down with someone who might become a client, I explained what we had built. A company that uses artificial intelligence to automate a business with its own data. Every word of that is true, and to me it is the most interesting sentence in the world.

To the person across the table it is nothing. I remember saying it to someone who sells property, and I remember the answer, because I have heard it in several voices since: I love the idea, tell me about it some day. That is what people say when you have described yourself instead of them. It is a kind answer, and it is a no.

The sentence that did

So with him I stopped, and I did not mention artificial intelligence again. I asked whether his customer management system gave him trouble. It did. I told him we had solved exactly that for several companies already, and that if he wanted, we could look at his.

That was the conversation. Same company, same product, same afternoon. The only thing that changed was the sentence: his problem, named, with proof that it had been solved before. You do not go to a client with the technology in front. You go with their problem in front, and the technology stays behind it until they ask.

One person, or nobody

The lesson underneath is short. A product is aimed at one specific person, or it is aimed at nobody. Not a segment, not a market, not “small and medium businesses”. A person with a job, a tool that gets in their way, and a Tuesday afternoon when it got in the way again.

When you can describe that person, everything else follows: what the product does first, what it refuses to do, what the first screen says, what the first sentence of the sales call is. When you cannot, you end up describing yourself, and you get told how much they love the idea.

How it shows up in the product

This is why, when we take on a company, the first thing we write down is not what the system will do. It is what the business already does: the rules it follows, the actions it takes, who approves what. The agents are then given a goal and an intention, not a chat window. They are aimed at a job that a specific person in that company already has, and their success is measured by whether that person’s afternoon got easier.

Three hundred dashboards taught me the first half of this, and I wrote that down in what selling taught me. The property seller taught me the second half in one conversation.

Isaac Correa, Madrid. ORCID 0009-0003-0657-4419.

I am Isaac Correa, co-founder of Hellomatik in Madrid, and the best feeling I have had in my work is not the one people assume. Here is what it is, and the rule I took from it about when a thing is really finished.

A summer of screens

Before a single line of Hellomatik existed, there was a summer of one person thinking. I spent the first month talking through what the thing had to be: how it would be built, how it would be explained, which pages it needed, what was still missing. I spent the second month turning that conversation into a design, one screen at a time. If I had to describe the craft in a sentence: take an idea that lives in your head, put it into words, and turn the words into pictures. I have written about the order I work in, and that summer is where the order came from.

What I found months later

Months later, with the platform running and people using it every day, I went back to those screens and compared them with the real product. I expected to find that reality had rewritten most of it. It had not. The design had moved almost nothing.

That was not luck, and it was not stubbornness either. It was what happens when the idea is clear enough before the building starts. The building then becomes execution: careful, slow, but not a search.

The rule

The rule I took from it is one I now apply to everything: when you have the idea that clear, you can create the whole tool before you build it. Design is not a sketch of the product that the code will improve on. Design is the product, waiting for its code. If a screen cannot say which decision it helps somebody make, it does not survive the design, and it never has to be taken out of the code.

People sometimes read that as a reason to build faster. It is the opposite. It is a reason to think longer, because the thinking is the part that does not get redone.

The best feeling

People assume that the best moment in this work is the sale, or the applause afterwards. It is neither, and I want to be precise about it because it is the thing that keeps me at this.

The best feeling I have had in my life is seeing something that only existed inside my head working outside it, used by people who never saw the inside of my head. A screen I drew in a quiet month, and a stranger clicking on it on a busy afternoon because it does what they needed. There is nothing else in this work that comes close, and it is available to anyone who is willing to finish the thinking first.

Isaac Correa, Madrid. ORCID 0009-0003-0657-4419.