Giving AI a desk
Your AI bill went up. Did anyone use the work?
The AI finished the audit. The client couldn't open it. Why I measure AI by whether the work got used, and the eight design decisions behind the pages that make that visible.
Uber spent its whole 2026 AI token budget in four months. Fortune reported that in May, in the same piece that said Meta had dropped its token leaderboard. Uber's COO, Andrew Macdonald, said that without a clear line to shipped features, the cost is "harder to justify."
Tokens are the units AI models bill by. A token count tells you how much AI a company bought. It can't tell you whether any of the output reached a customer, and that second number is the one I care about.
Counting pages or reports doesn't answer that either. A bigger pile is still a pile. What I measure is one piece of work at a time: did the person it was for use it? Did they approve it, push back with a change, or fill in what was missing so the job could move? Each of those leaves a record, and the record looks the same no matter which AI model made the work.
I built it that way because of one audit a client couldn't open on 6 October. This piece covers that story, what I designed after it, what Case Engine's team did with it, where Gina is taking it next, and the eight design decisions underneath. If your company uses AI to produce work for other people, the design decisions are the part to read.
The audit nobody outside could open
Case Engine is an agency that went all in on AI early. On 6 October their AI wrote a full audit for a client, and the team sent the client a link to it.
The client couldn't get in. The AI tool's page only opened for people signed in to Case Engine's own workspace, and the client had no login there. A finished audit sat behind a login that the one person it was written for didn't have. How good the audit was, and how fast the AI wrote it, made no difference to someone who couldn't read it.
The quick patch was a PDF attachment. I didn't want to stop there, because I'd been running something better on my own work since the summer.
I'd already hit this in my own businesses
I run several businesses and I have AI agents working across all of them. Early on the agents did decent work, and then it sat in a chat window until I copied it somewhere I could use it. I was the copy-and-paste step, for every agent, every day.
So I changed where the agents put things. Nearly all of their work now lands in one private store that I call my brain. Each piece is a real page with saved versions. Nothing is public until I click Publish, and when I do, it becomes a page I can send to anyone. I've reviewed my agents' work this way since the summer, and as of 12 November the store holds more than 7,000 pieces.
When Case Engine's client got locked out, I recognised it. The audit was written. It had no route to the client in a form the client could open and answer. I had closed that same gap for myself a few months earlier.
Why I rebuilt it for an agency
In my own setup I'm the only reader, so the trip from agent to reader is short. Pages helped me, but I could have lived without them.
An agency has a bigger version of the problem. Case Engine has far more people than I do, plus outside collaborators, clients and AI bots, all producing work at the same time. Every one of them has to hand something to someone else, and each of those is a spot where an audit or a report can get stuck the way that one did on 6 October. Add a person or a bot and you add more of those spots. The fix is worth more there than it ever was for me.
I didn't copy my own setup across. I rebuilt the idea for a team, and Case Engine's version does more than mine. It has forms an outside person can fill in, tracking of who opened a page, a team-only level between private and public, and templates.
For context on who's who: I run KaiCalls, and Case Engine and Gina are partners I work with. In all of them my job is designing the system that gets AI work to the person it's for.
What Case Engine's team did with it
At Case Engine the system is called CE Pages. Anyone on the team can turn finished work into a web page from a menu in the app, and their AI can do the same through its own set of publishing tools. Either way it's one step. The person on the other end taps the link and the page opens. They don't create an account or download anything.
I designed it and built it in. Then Case Engine's team took over. They're a sharp team and they moved faster than anyone planned for. Within weeks, pages were how work moved around the agency.
The team uses pages for client deliverables like audits, monthly reports, and stats pages for ebooks and microsites. They use them to ask clients for things: an approval page where the client signs off or asks for changes, a domain pick from three options, an access link that asks only for what's still missing, kickoff questions. They use them internally too. Review checklists get marked item by item and post a comment on the task, and one firm had 100 proposed site changes reviewed that way. Account managers write pre-call reports, plans and how-tos as pages. There's also a guide that was written once and gets a personal link for each client.
As far as I saw, there was no pilot phase and no committee. The team started using pages on live client jobs and inside their own team right away. Publishing a page was easier than attaching a file, so people just did it.
What I actually measure
The AI adoption number most people quote is 95%. In August 2025 Fortune covered an MIT report that said 95% of generative AI pilots at companies were failing. It's worth knowing how that was measured: interviews, surveys and a review of 300 public deployments. That is a measure of pilots.
I don't look at totals. I look at a single piece of work and ask what happened to it. Say a client report goes out on a link. The client opens it and asks for one change. The fix goes up as a new version behind the same link, and the client approves it two days later. That's adoption I can see, because the work got used. Somebody made a decision with it.
The same record tells me when something is stuck. A report that only the team has opened hasn't reached the client, whatever it cost to make. A form nobody has filled in is a follow-up call waiting to happen. Totals hide both of those.
It also doesn't care which AI made the work. I've swapped the models feeding my own setup and the record of what was delivered carried straight on. That's the part that keeps me from getting locked in.
There are limits. Staff publish pages as well as the AI, so not every page is AI work. Security scanners that open links in email can add opens no person made, so I look at who opened a page rather than how many times.
I'd still rather have this than a token bill. From where I sat, nobody at Case Engine had to change how they worked before those records started showing up. People kept doing their jobs, and the page became the place where finished work goes.
The lock-in is everything around the model
Go back to why the client couldn't open the audit. The AI tool kept its output on its own page, and that page only opened inside one workspace. To me, that was lock-in. The work existed, but it lived in a place only that vendor's login could reach.
Stack Overflow published a survey with Stacklok on 21 October that lines up with this. They asked 520 technical leaders. Only 8% use a single model provider, and 25% use five or more. 84% said avoiding lock-in matters, yet it ranked last of eight selection criteria. 57% said a migration would take four months or more. The way I read it, teams already swap models freely, and what they can't move is everything they built around the model.
CE Pages sits on the "around" side, and Case Engine owns it. A team member publishes from the menu, and any AI that can use the publishing tools can publish too. The page doesn't care which model wrote it.
My own setup is the longer test. I run Claude, Codex, Gemini and local models, and nearly all of their work lands in the same private store. I've changed the agents feeding it and kept the work and the links.
The design decisions underneath
A page with a link sounds simple. Under it are eight decisions, and I had a reason for each one.
1. The link never changes. When the team updates a page, the system writes a new version behind the same link, and each version is its own saved file. I did it this way because links get forwarded and buried in email threads. If every edit made a new link, every old email would point at stale work. The most-edited page at Case Engine is on revision 49, and nobody had to resend anything.
Two details matter here. If two people update the same page at the same moment, the second is told to re-read the page and try again, so nobody silently overwrites a colleague. And when a page is unpublished, the link stops working but the record, the versions and the saved answers are kept, so the team can still show what was sent. Case Engine has 17 unpublished pages and all of them are still on file.
2. Three audiences. Public means anyone with the link. Public pages are never cached, so no stored copy is served in place of the real page, and every open reaches the server and gets counted. Team means signed-in staff only. Anyone else gets the same "page not found" they'd get for a page that doesn't exist, so an outsider can't tell something is there. Only me means the author alone, and the title is hidden from lists and reports too.
I went with three levels because work moves through stages. A draft starts as mine, the team reviews it, then the client gets it. With only public and private, a draft either goes out too early or stays in one person's files. The middle level is the one Case Engine uses most, because most work gets reviewed by the team before a client sees it.
3. Facts fill in when the page opens. A page doesn't have the client's phone number typed into it. It has a marker that says this client's phone number goes here, and each time the page opens the server fills in the current value from the client's record. A number pasted into a page is wrong as soon as the client changes it. With a marker, the team fixes it once on the client's profile and every page is right on the next open.
The marker also lets one page serve many clients. A guide written once gets a separate link per client, which is the page link plus a 20-character code that tells the page whose facts to show and whose record a form writes to. Ask for the link again and you get the same one back, and it can be cancelled. There's a check at publish time too. A marker with no value behind it stops the publish, so a client never opens a page with a hole where their business name should be.
4. A form can only write what the stored page allows. This is the one I'd defend hardest. When someone saves a form, their browser sends a message to the server, and anything sent from a browser can be tampered with. So CE Pages ignores what the browser says the form may write. It reads that from the page stored on the server, which is the one thing the team controls. If the stored page says this form may update a phone number and a domain, those two fields are all it can touch.
Forms also come in a short list of kinds, such as questions, client details, review, approval and domain choice. Each kind has one writer, a single piece of code that checks every answer before it's saved. A form of an unknown kind can't be published at all. The stored page holds only a placeholder, and on each open the server works out which client is looking and draws the real form with their current answers filled in.
5. Receipts keep before and after. Every save writes a receipt that records each answer and, for every field that changed, what it said before and what it says after. When a client changes something on their own record, the first question from the team is what changed. A line that says "form submitted" can't answer that weeks later, and a before and after can. The receipt also stores the city and a hashed ID for the browser. It stores no IP address. That's enough to tell saves apart without keeping more about a person than the job needs.
6. A blank never erases. If a client leaves a box empty and saves, the record keeps what it had. People skip boxes because they're busy or because they assume you already have the answer. If a blank wiped the record, one hurried client could delete a phone number the team spent a week chasing.
7. Opens are split three ways. Each open is logged as a visitor, a named teammate or a bot. Say a page shows nine opens. If all nine were the team checking their own work, nobody outside has read it and the account manager should pick up the phone. If one was an outside visitor, that's a different conversation. A single view count can't tell you which one you're in. The split is still imperfect, because scanners can add opens that no person made.
8. Pages run sealed off. These pages are written by AI and by many different people, and they get sent outside the company. So each page runs sealed off from the rest of the app. It can show things and collect answers through its form, and that's all. The page files sit in private storage that only the app's server reads. This is what lets me allow one-step publishing. Without it I'd want a human review before every publish, and that review would become the new bottleneck.
Publishing does run checks. A missing client fact or an unrecognised form blocks the publish. Checks on how the page looks at phone width, in dark mode and with charts are reported back and never block it. Uploads are capped at 50 MB per file and SVG files aren't accepted. Page links end in 12 random characters so nobody can guess one.
What happens when someone outside hits Save
Forms are where a person outside the company changes your records, so this is where I'm most careful. Every save is checked before anything is written:
- It came from its own page and it isn't a bot.
- It's under 64 KB, which is far more than a real form needs.
- A hidden box that people never see is still empty. Spam programs tend to fill every box they find.
- The page wasn't republished after the person opened it, so their answers still match the form in front of them.
- The page was open for at least 1.5 seconds and less than 24 hours.
- It's inside the limits of 10 saves per 10 minutes for one browser and 60 per hour for one client on one page.
Files go to a one-time upload address first and then land in the client's folder.
There's no autosave. A half-filled form that gets closed is gone, which means every answer on the record is one the person chose to send. Some people will call that unfriendly. I'd take it over a record full of half-answers.
The same idea at KaiCalls
Kai is the AI that answers phone calls for a business at KaiCalls, which I run. When a call ends, the owner gets an after-call report, which is a summary of the call and what to do next. It's the same idea applied to a phone call. Kai takes the call, and the report is how the owner finds out what happened on it.
Gina: the same idea for a business owner (in progress)
Case Engine proved the idea inside an agency. Gina, an AI assistant for small businesses, is where I'm taking it next, and I'm building it with the Gina team now. It's running on staging and isn't live yet.
An agency has a team to review a page before a client sees it. A small business owner usually doesn't. It's one person, often on a phone between jobs. So in Gina a page isn't a fixed page with a form on it. It's a canvas. The owner asks for a page in one sentence, Gina builds it from the business's own records, and the owner and Gina's agents keep working on that same page.
Take a plumber whose job needs an extra part, which is the example we design around. His customer gets a text with a code, opens the page on her phone with no account, and approves the part. Her approval lands back in his jobs with who approved it and when. That's the same test I use everywhere: the work got used, and there's a record of it.
Gina keeps the core Case Engine proved: one link, versions behind it, and a record of what the customer did. It goes one step further on privacy. A public link shows only the fields the owner marked public, which is the three-audiences decision taken down to each field.
What I'd tell any team building this
These come from what I built and what I watched the team do with it.
- Start from a real failure. CE Pages began with one client who couldn't open one audit, and that told me what to build first: a page that opens with no account.
- Make publishing one step, for people and for AI. If it takes five, people go back to attachments.
- Keep the link fixed and keep the versions. Keep the record even when a page comes down.
- Decide on your server what a form may write. Read it from the page you stored and ignore what the browser claims.
- Record changes as before and after, so someone can see what changed weeks later.
- Treat an empty box as no answer.
- Split your opens. Nine opens from your own team look exactly like a client who read the audit.
- Block the publish only for things that would embarrass you in front of a client, like a missing fact or a broken form. Report the rest and let it through. Block too much and people stop publishing.
The question to ask
I call this giving the AI a desk. It's a place where finished work gets put down and someone can open it and answer it, with a record that they did. For my agents that's my brain. For Case Engine it's CE Pages. For Gina's owners it will be the canvas.
Token spend and pilot counts won't tell you whether you have one. If the honest answer in your company is "someone copies and pastes it," that's the first thing I'd fix. Here is the question I'd put to every AI tool you run:
When the AI finishes, how does the work reach the person who needs it?
This is the delivery half of the story. The other half is checking that an agent's "done" is true, which is what Agent Receipts v1 and the Definition of Done for AI Agents cover.
I first published this on LinkedIn.