Since I got wired up with always-online sessions, the way I work has changed. I don’t think I’m going back.
Three things happened.
The first. A session remembers where we were. No cold start, no re-explaining last week. I sit down and we’re already mid-thought.
The second is ironically a gap. I'm dictating this post in the car, and the Claude session I'm talking to isn't one of the always-online sessions. Conversation mode doesn't run that way. The conversation is happening outside the online sessions. But I can still get across. I can do this because I built Greenroom, my own project tool. The Claude session in the car talks to Greenroom, and Greenroom carries the message on to the other sessions. A conversation while driving still relays to the always on sessions and can communicate with them.
The third turned my AI tool into something completely different. The sessions started talking to each other. This means they can specialize and I can ask the always-online session what the other sessions are doing. My next move is to give each session its own rules. A small crew of agents, each with their own job.
That’s the setup. This is what it argues for;
Build the API first
Any application you build today should be fully doable through an API. Every single thing a person can do, a machine should too.
Take an invoicing tool for example. Every action on an invoice — create it, send it, chase it — reachable through an API. Now invoicing can be automated with an AI. Invoicing handles itself. Do that to all your systems and they can talk to each other. Now you can automate almost any process.
The bottleneck in most digital services isn’t that they’re slow or ugly. It’s that they’re locked shut. Nothing can reach in, but they should be reachable. I can’t think of a case where that’s not true.
Security is a different layer
The usual objection: you can’t expose all that, it isn’t safe. Accessibility and security aren’t the same argument, and we keep collapsing them into one.
If an API shouldn’t be public, don’t cripple the product, secure the API. Keep it off the open internet. Allow only the addresses that should reach it. Make it reachable, then guard where it’s reachable from. Don’t let a security question become a reason to build something a machine can’t use.
The automation ladder
So how do we automate? There’s a ladder here.
Most of us are on the bottom rung without even noticing there is more.
Rung one: a human wires it up. You point the AI tool to the invoice API by hand. That’s where most companies are today.
Rung two: an agent wires it up, when you ask. If all tools have APIs connecting two tools is a job a machine can do. I haven’t seen much of it in the wild — we’re not that mature yet.
Rung three: the agent stops waiting to be asked. “I've drafted a better process for you. Do you want to use it?” A suggestion, on its own initiative.
Rung four: it just does it. “I’ve set the process up. Hope you’re happy.”
Rung five: “And now I’ll optimize it.”
Each rung hands more judgement to the machine.
Everyone wants to reach the top first. Few ask the better question — what is needed to get there. Do I have an API to all of my services?
How do we know we get better?
On rung five, the agent turns around and says it improved your process, but how do we know?
In the last post I said iterations mostly run on gut feeling, but real improvement needs to be evidence based.
There are two things we need to measure.
One is efficiency, measured with data. For example, take the invoice. The goal is simple: I send it, I get paid. Measure the time from one to the other. That’s a well-defined process, and you can watch it get faster. The catch is the mountain of data and that patterns are hard to find. Good analytics people exist but it’s still too much for a human to take in. It’s the kind of thing an AI is genuinely good at: read the whole pile, find the pattern, draw the conclusion.
The other is experience, and you can only measure it with honest feedback. We craft digital applications designed to create human experiences. The person receiving that invoice should find it smooth, easy, and even pleasant. That’s good design, and the only way to know you’ve got that is to ask the user.
So in Greenroom I built a feedback widget. Add it to your site, press F, click anything on the page, write what you think, send. It lands in Greenroom as feedback. Today I read it and decide if it's a good idea, or a real problem, then it becomes a task and is built. An agent could do the reading. That’s a self-improving system in its simplest form — human feedback on one end, agents updating the product on the other.
A personal screen for everyone
Here’s where it gets strange. If the API defines everything the product can do, the interface no longer has to be one-size-fits-all. One API underneath, a UI per person on top. Automatically built, shaped by user feedback.
In the last post I warned about feature bloat. This sounds like exactly that. It isn’t. Bloat is bad because it gets hard for a person to see and understand all the features. If your version is personalized to you, your version is easy for you to understand. Personalization is the cure for bloat, not the cause.
There’s a governance line that keeps it sane. Change something in the UI and you’ve changed it for one person. Change something in the API and you’ve changed it for everyone. What the product is, lives in the API. What it looks like to you lives on your screen.
What keeps the product from growing out of control? I say, clear goals and purpose. The system’s goal decides which features should be added. If the goal is sending invoices — or levelled up to getting paid — then reminders belong, but a hundred unrelated things do not. The goal is the new defence against bloat.
What to do
Make sure you set clear goals and set the purpose of your applications. Change on evidence. If you build new applications, build the API first. A machine has to be able to do anything a person can in the systems.
Everything after that, agents, personalization, and systems that improve themselves, needs that.