My take: the most valuable thing an AI team owns isn't its prompts, it's its test set. Prompts are easy to copy, and the best model changes every few months. A pile of real, ugly cases with known correct answers lets you swap models, rewrite prompts or cut costs without guessing. Without one, every upgrade is just vibes. I think the teams that move fastest over the next few years are the ones that started collecting hard cases early.
Sales call follow-up that actually happens: after each call, the transcript goes to a model that drafts the follow-up email and pulls out next steps, who owns them, objections raised and any dates mentioned. It suggests CRM updates but doesn't write them. The rep opens one screen, fixes what's wrong, hits approve, and the email and CRM changes both go through. Deals stop dying because nobody sent the recap until Thursday.
Every agent loop needs a hard ceiling. Without one, a confused agent can call the same tool over and over, burn through your API quota and run all night while nobody notices. Give each run a budget: max steps, max tokens, max wall-clock time. When it hits any limit, it stops, saves what it has and kicks the job to a human with a note on where it got stuck. A stuck agent should cost you a few minutes, not a weekend of usage.
Sneaky effect of instant drafts: whoever generates first sets the frame. A model spits out a plan in ten seconds, and now the meeting is about editing that plan instead of asking whether it's the right plan at all. Tweaking is easier than starting over, so the first draft wins way more often than it deserves. If something actually matters, have people write their own rough take before anyone opens the tool.
I'd bet a growing share of API traffic comes from agents, not developers, and that changes what a good API looks like. Agents don't read your pretty docs site or ask in your Discord. They need clear schemas, predictable pagination, errors that explain themselves, and docs a model can actually parse. Companies with messy, inconsistent APIs will lose deals they never hear about, because someone's agent tried to integrate, choked, and went with the competitor that just worked.
Invoice check before anyone pays: every vendor invoice that hits the inbox goes to a model that pulls out the vendor, line items, quantities, rates and total. Then plain code compares those fields against the PO or contract rates and flags anything off, like a rate that crept up, a duplicate invoice number, or a line nobody ordered. Clean ones get queued for approval and flagged ones go to a human with the mismatch spelled out. Nobody eyeballs PDFs line by line anymore.
Long agent jobs need save points. If a run has 40 steps and crashes at step 37, you don't want to start over and redo everything, including stuff that already touched the real world. After each step, write the progress somewhere durable: what's done, what each step returned, what's next. On restart, the job reads that and picks up at step 37. It's the same idea as saving in a video game. Crashes become a short delay instead of a full rerun.
Second-order effect nobody's budgeting for: the grunt work was the training. Juniors learned by writing the boring query, the first draft, the basic test, and getting it torn apart in review. That's exactly the work that now gets handed to a model. Output's fine today. But in five years, who has the judgment to know when the model is wrong? If you don't deliberately give people reps on the fundamentals, you're quietly skipping a whole generation of senior people.
My take: the real AI edge for small teams isn't speed, it's fewer handoffs. Most work dies in the gaps between people. Waiting on design, waiting on a data pull, waiting for someone to write the spec. When one person with good tools can carry a thing end to end, a ton of that waiting just disappears. I think a lot of companies are about to find out headcount was partly a coordination tax, and that tax compounds the more people you add.
Security questionnaire drafts a small team can run: keep one library of every answer you've already gotten approved, plus your actual policy docs. When a new questionnaire lands, a model matches each question to past answers and drafts a response, citing which approved answer or doc it came from. Anything with no solid match gets flagged instead of guessed. A human reviews the flags and signs off. Nobody rewrites the same encryption answer from scratch for the tenth time.
If an agent can take real actions, make every action safe to repeat. Agents retry constantly. A timeout hits, it can't tell whether the email went out, so it sends it again. Same with charges, tickets and record updates. The fix is an idempotency key: each action gets a unique ID, and the system remembers which IDs it already handled. The second attempt just returns the first result. Retries should be boring, not a second customer email.
The bottleneck quietly moved from writing to reviewing. Drafts, code and analysis now show up way faster than anyone can actually check them. So the PR queue grows, the doc sits unread, and someone approves stuff they skimmed because the pile is huge. The scarce resource is no longer output. It's attention from someone who knows what correct looks like. Teams that don't plan for that just ship more unreviewed stuff, faster.
My take: most production AI calls don't need the biggest model, and teams will figure that out once the bill gets annoying. Classifying a ticket, pulling fields out of an email, rewriting a summary. Small, cheap models handle that stuff fine. I think the normal setup becomes a router, with the boring high-volume work on small models and the frontier model only called for the genuinely hard stuff. Paying top-tier prices to sort spam is a habit, not a strategy.
Contact form triage for a small team: every website form submission goes to a model that sorts it into sales, support, partnership, job applicant or spam, pulls out the company and what they actually want, and drafts a reply. Sales leads go to whoever owns sales, support goes to the support queue, spam gets archived. A human reads and sends the replies. Real leads stop sitting in a shared inbox for four days next to vendor pitches.
A fallback you never exercise is fiction. Lots of AI setups say 'if the main model fails, switch to the backup.' Then the main one goes down, traffic flips, and the backup chokes on a prompt it was never tested with, or a key that expired months ago. Run a small slice of real traffic through the fallback path all the time, and run your test set against it whenever you change prompts. If you only find out it's broken during an outage, it was never really a fallback.
Clear writing quietly became a technical skill. The person who can say exactly what they want, what done looks like and what to avoid now gets wildly better output from the same tools as everyone else. Vague asks used to get fixed by a coworker who'd just figure it out. Now they get fixed by nobody, and you get confident garbage back. The leverage goes to whoever can write a decent spec.
Technology removes friction.
Humans keep putting some of it back.
We climb mountains even though elevators exist.
We run marathons even though cars exist. We camp despite having houses. We play golf despite how often it makes us miserable.
Why?
Because efficiency is not the same thing as meaning.
If AI makes life dramatically easier, a Human Experience Engineer might design experiences valuable precisely because they are difficult, uncertain, social, physical, surprising, or real.
Adventure. Competition. Ritual. Challenge. Connection.
The product is not convenience.
The product is feeling alive.
My take: the chat box is a transitional UI. It's the default because it was the easiest way to ship a model, not because it's the best way to use one. Most people don't want to write a paragraph explaining what they need. They want the button that already knows the context. I think the AI products that win over the next few years mostly hide the chat and put the model behind specific actions inside the workflow, with chat as the fallback.
CIIMS: building an investment management system for my property business, mostly with AI agents
I run a small property management and investment company and got tired of spreadsheets, so I'm building CIIMS (Custom Internal Investment Management System) to track investors, ownership and distributions.
What's interesting is the process: it's architected in docs first, and AI coding agents implement it in small, gated slices. Nothing financial ships until its contract and acceptance tests exist. Postgres 17 with forward-only migrations, synthetic fixtures, CI against a throwaway database, and Cloudflare planned for the app layer.
Alongside it I've got Workers + D1 + Access running an agent ledger that tracks my AI bots' check-ins and mirrors them into ClickUp. Happy to share how either is set up. Would love feedback on the Cloudflare architecture for the financial side.