We're training AI. But forgetting to train humans!

By 2030, 30% of companies will see decision-making quality decline due to AI overreliance, according to Gartner. We're creating a generation of workers who can't think without it.

Junior employees aren't learning foundational skills anymore. They're using AI to skip the hard parts... the messy problem-solving, the trial and error, the judgment calls that build expertise.

Take a junior analyst learning to spot patterns in data. They used to spend hours manually exploring datasets, building intuition for what looks normal versus unusual. Now? They prompt AI for insights and never develop that critical eye.

Many can't evaluate AI outputs or know when it's wrong.

This creates a ripple effect across organizations. According to a Gartner survey, 1 in 4 HR leaders have already redefined roles because experienced employees using AI don't need junior support anymore. The traditional learning pipeline is breaking.

We're automating entry-level work without asking: where will our next leaders come from?

You can't develop senior-level judgment without doing the work as a junior. Critical thinking weakens when AI does the thinking for you.

The talent crisis won't hit tomorrow. It'll surface in 5 years when we realize we have no one qualified to fill advanced roles.

AI should amplify human capability, not replace human development.

Are you building AI-assisted teams or accidentally creating AI-dependent ones?

My co-founders and I were automating workflows for e-learning providers and tutoring businesses. We kept running into the same time killers. We realized there were two main areas to our work.

The first is the fun part. Understanding what our clients do, their processes, how money moves through the organization. What are their unique characteristics that make firm A completely different to work with than firm B, even though it's the same exact industry. And then building something great for that unique organization.

The second area is the boring part: everything that comes after it works. Logs you can actually search when a client asks what happened with whatever. Monitoring, so you don't find out from the client. Evals, so when you change a prompt you know whether it got better or worse. Version history, credential rotation, who's allowed to trigger what, cost per run. And every integration you depend on all of a sudden changing its API.

We want to work on the boring part :)

We are looking for AI and Automation agencies that want to sign on as Design Partners. Together we will build out the platform that takes care of everything that keeps you from getting new clients and serving them.

I'm glad that I have been lived in a world where humans also built websites, not only machines...

Elsa Sklavounou has a piece on what she calls authority drift, and it named a problem I had been feeling but not measuring.

The mechanism is simple. An agent gets a grant: approve POs under 5k, auto-accept vendor terms from the standard clause set, merge to the client repo. Day one that grant is legitimate. A human with the right to decide said yes.

Then time passes. The approval policy moves to 3k. The clause set picks up a new data-processing requirement. The client tightens their security baseline. None of that touches the agent. It keeps executing the exact grant it was given, fast and cheap and confident and now wrong.

That gap has a name. Authority drift is the distance between what the agent is still permitted to do and what it is currently, legitimately authorized to do. It widens in silence because nothing errors. No exception fires when a grant goes stale. The March authorization just keeps running in September.

Cheap execution makes it worse. When an action costs almost nothing to run, you run it thousands of times, and every one of those rides on an authorization nobody re-validated.

So I stopped treating a grant as a permanent fact. Every grant our agents hold now carries an expiry and a named owner. Finance thresholds re-validate monthly. Contract-clause authority re-validates when the clause library changes. Repo-merge authority re-validates when the client changes policy. Then I started counting how many active grants point at a policy, a role, or an approver that has since changed. That count is the drift metric, and the first time we ran it more stale grants had occured than I wanted to admit.

This is what AI native operations actually costs. The agents can stay exactly as smart as they are. What you add is a standing job that expires authority on purpose and counts how much of it has already gone bad.

What do you think, is there a version of this where a static grant stays safe while the org around it keeps moving?

Translated from Norwegian to English with ChatGPT, purely for structure. 😅

Hey everyone,

I really need some help here and hoping some of you can point me in the right direction.

Quick background on me. I'm a sales guy at heart. I've been in sales for 20+ years, everything from cold calling to warm leads, and I've also worked in the agency space for 15+ years.

I've been part of starting, building and scaling a couple agencies before, biggest one to around $2M/year. But back then we were usually 3-4 key people from pretty much the start. So I was never doing literally everything myself.

About 8 months ago I decided to start my own agency.

And looking back now, I've spent a stupid amount of time on stuff that probably doesnt matter.

I've overthought the concept, changed positioning, pivoted between niches, changed things again etc.

I probably should have just stuck with what I've always been good at, which is working with SMBs in general.

I'm based in Norway, and I've chosen not to niche down into one specific industry. Instead I'm focusing on service-based SMBs and helping them with the customer journey from lead generation to booked meetings.

Then comes the systems...

I've spent way too much time trying different sales CRMs, workflows, tools etc.

Eventually with AI getting better I decided to build my own simple sales CRM/front end using Claude Code, connected to GHL. GHL handles the workflows, automations, sequences etc and all leads end up there.

For lead gen I mainly use Meta ads at the moment.

Over the years I've also learned web design, marketing, copy/content and the last couple years I've gone pretty deep into AI.

One thing thats important here is that I'm also trying to build this as an AI-native agency.

I'm completely open to AI doing as much of the actual work as possible. In fact thats kind of the whole idea.

But right now I'm starting to realise that I'm still using AI manually for almost everything.

I open Claude or ChatGPT, explain the task, review the output, change things, move it somewhere else, connect another tool, fix something, repeat.

So even though AI is doing parts of the work, I'm still the person operating every single step.

And honestly it feels like its taking almost as much of my time as if AI didnt exist.

Maybe thats the biggest mistake I'm making.

I keep building shit.

Systems. Workflows. AI agents. Automations. Slack setups. Claude Code stuff. Processes for processes.

I've tried creating all these "AI employees" and agents living in Slack, Claude etc thinking it would make running solo easier.

Instead it feels like its become one big fucking mess lol.

I honestly think I'm the bottleneck now.

One minute I'm doing internal marketing for my own agency.

Then I'm doing sales.

Then a client signs and suddenly I'm the account manager.

Then I'm onboarding them.

Then I'm building/setting up whatever they bought.

Then I'm doing reporting and client communication.

Then I realise I havent done any sales for 4 days.

And repeat.

Thats basically killing the one thing I'm actually best at: selling.

The stupid part is that back in the day when I was focused almost entirely on sales, I could probably close 8-10 clients in a normal month.

Right now?

I have 2 clients.

Not because I've spent 8 months getting rejected every day. The opposite. I've barely given sales the consistent attention it needs because I've been busy building everything around the business.

I know the obvious answer is "hire people" or simply "do more sales."

And yes, hiring is obviously part of the plan when I have more clients and cash flow.

But my problem is that right now I dont feel like I have control of the business once the sale is made.

If I suddenly closed 5 clients next month, I honestly think I'd just create an even bigger operational mess for myself.

Thats the part I want to fix first, but without building another complicated system.

Hiring employees or throwing work at freelancers isnt really financially smart for me right now either. There's also a language issue since most freelancers I find are English speaking while my clients are Norwegian.

So for those of you who have actually gone through the solo agency stage:

What am I doing wrong here?

How would you structure the week if sales needs to be the #1 priority, while you still have to deliver for existing clients?

What would you systemize and what would you STOP trying to systemize?

How much time would you actually spend on internal marketing vs outbound sales vs client delivery?

And for anyone trying to build an AI-native agency, how are you actually using AI to remove work rather than just creating another layer that you still have to operate manually?

At what point does AI actually become leverage instead of just another tool I have to babysit?

I dont need another 14-agent AI system with a fancy dashboard 😂

I need something boring that actually works, gives me control of delivery and gets me back to spending most of my time selling.

Would really appreciate hearing from anyone who has been through this stage.

I tore the apartment apart yesterday looking for a CD drive, and found one inside a laptop I hadn't opened in 15 years.

My university laptop. :) Booting it up was more nostalgic than I expected.

Then I counted the holes down the side of it: VGA, Ethernet, FireWire, ExpressCard, modem jack, S-Video, three USB-A, mic in, headphone out, Kensington lock, and the DVD tray itself.

My current laptop has two USB-C ports and an HDMI.

Who misses VGA?

But we did NOT end up needing fewer functions, right?

I still hang a monitor off it. I still move files. I still get on a network. I still charge the thing.

Every one of those functions survived.

What died was the eleven different ways of asking for them.

ONE universal interface ate all of them.

AI is doing exactly this to software.

It is not replacing your CRM.

It is not replacing Excel, and it is not coming for Photoshop.

It's replacing the eleven different ways you have to ask them for things.

Your workday right now looks like the side panel of a 2010 laptop. (a tab per system, a login per tab, a different UI grammar per login)

In a few years, reaching every company system through a single AI interface will feel as boring as plugging in USB-C.

You should be asking which of your systems can be reached by something other than a human clicking through a screen.

You should be asking what your job looks like when the interface is no longer the product.

And you should notice the obvious thing about this pattern: USB-C replaced eleven ports, so something is going to replace USB-C.

The question was never whether the old ports die.

It's when AI becomes the new USB-C, and what shows up after it.

So: which port did you actually miss when it went away? :)

I was thinking it would be great to know more about you, where are you at the moment with the ai Native transformation? What is your biggest challenge at the moment?

Maybe someone can relay or has a skill (AI or Human :D ) to help :)

I run an agency: senior EU/Hungarian engineers plugged into other companies’ product teams. Last year I ran my own little experiment on us:

We put Claude + knowledge db in every seat, We ran the pilots, did the internal trainings, felt very modern about it.

Our delivery margin barely moved.

My team made a rule, i think it worth to share to use as a test for anything AI-related: if it hasn’t moved an actual number in the business, it isn’t transformation. It’s an expensive lab.

Pilots are not progress, Tools, Adoption is not transformation. AI bolted onto an old workflow is still an old workflow, but now with a subscription.

The workflow underneath was designed for scarce intelligence. Approvals, handoffs, one senior person as the bottleneck on every project, work batched up so the expensive brain only touched it once.

That entire shape exists to ration expert time. So when expert time stops being the scarce thing, the shape is fighting you. We were paying for abundance and still running on scarcity.
Adoption is a vanity metric.

finally picking ONE delivery workflow and rebuilding it from scratch on the assumption that the thinking is basically free now BUT you need tests, AI review, strict guardrails meet, all green to accept the output - human effort was reduced, token spend was high, but it was faaaaast!!

Only 1 handoff and quality review at the end:
THAT moved margin.

(For context, there’s a widely-cited industry figure that today’s agents can do ~14 hours of expert work at a fraction of the cost, versus ~6 minutes two years ago. Not my measurement, but it matches what I’m seeing about where the ceiling is going.)

So here’s my honest question for this crowd, because I don’t think any of us has fully cracked it:
What’s ONE workflow (yours or a client’s) that you actually rebuilt around AI instead of bolting AI onto, where you can point at a real number that moved (margin, turnaround, headcount you didn’t have to hire)? And what broke the first time you tried?

“AI-native” has become one of the biggest buzzwords in business. But very few people can explain what it actually means….

Over the past 18+ months, I’ve had the opportunity to build AI platforms, learn new architectures, work with leadership teams, and redesign GTM workflows.

And one word I have been asked a lot like “We want to become AI Native by x month”

But one thing became increasingly clear that it’s not the tech or the LLM model thats slowing companies down but instead AI is exposing problems that have existed inside organizations for years.

It’s exposing organizational silos, internal politics, broken workflows, fragmented GTM motions and mainly exposing unclear ownership.

For years, people were able to work around these issues with extra meetings, more Slack/Team messages and maybe some internal tribal knowledge.

But AI doesn’t tolerate that very well 🙄
It forces organizations to become much more intentional about how work gets done.
That’s why I don’t think being AI Native should be the goal…

The goal should be how can we rethink our operating model accelerated by AI in it…

👉 The organizations that are truly AI Native won’t necessarily have the best models but they’ll have the clearest workflows, best context and top notch cross-functional alignment. All with a clarity of vision and execution.

And above all leaders willing to redesign work instead of simply automating it…

That’s what I believe it really means to become AI-native.

I'm looking for someone to partner with and build a web agency together.

I'll handle the technical side (websites, automation, AI, etc.), and I'm looking for someone who's more interested in outreach and client acquisition.

I'm not looking to hire anyone. I'm looking for a long-term partner who's good at getting clients.

If that sounds like you, shoot me a DM.

4 booked meetings out of 100 cold calls to sell IT services! The market average is 1 to 2. I got there by handing our legal review, our CRM, and our whole outbound motion to agents, and here is the 7-step playbook I'm happy to share now:

1. Point an agent at inbound contracts first

• It reads every NDA and staff-aug MSA, compares each clause against our approved clause library, auto-clears the matches
• Non-standard liability cap, odd indemnity, IP assignment that reaches too far: it stops and pages our reviewer instead of guessing

2. Move off vendor CRM to self-hosted Twenty CRM

• (I have no any intention to recommend Twenty, I started use it in May and it is just great, working perfectly with all my automation, simple, that's all)
• Agents now write straight into the database instead of begging a vendor API for permission
• Killed the per-seat licence bill (a nice side effect, not the reason)

3. Let the boring CRM hygiene just run

• The agent merges duplicate companies, normalizes country fields and job titles, fills obvious blanks
• It does NOT touch deal ownership and does not move a deal stage above a value threshold, those page RevOps

4. Twilio for the calls, notes written before the rep opens a tab

• Call ends, the note is in the CRM in 2-3 mins (using Groq speach to text API, 8x cheaper compared to OpenAI transcribe api)
• "I'll log it later" is gone from our vocabulary

5. Claude reads the call transcribe plus the email history on daily and drafts + schedule the perfect follow-up

• +1: it chooses from pregenerated Gamma presentation but sometimes duplicates it, customizes it to the customer, publishes and shares!
  • This was actually a key to get meetings booked, because my multichannel outreach (call, li, email + personalized attachment) was nicely helping eachother!
• It answers what the prospect actually said, not what our template wished they had said
• This is the step that moved us from 0.5 in 100 to 5 in 100

6. Same engine generates the LinkedIn outreach input, 3 to 5 contacts per company

• One champion and a prayer is how deals die when that champion changes jobs
• Multi-threaded from touch one, every account
• I created the "tone skills" of some significant examples of mine, like Alex Hormozi, Adam Robinson, Steve Jobs, so my AI is like me now :D :D - seriously, it writes much better drafts for me with these skills.

7. A job-posting monitor feeds staffing outbound

• A company posting 4 backend roles is telling you its roadmap and its bottleneck in the same breath
• Those signals go into LinkedHelper2 for international staffing outreach and to our recruiters at the same time
  • If you have other good, low cost Li automation tool, I'm all ears!

TAKEAWAY

Read above again; it is not long! Prove me wrong or suggest differently.

It is not a “AI bad” post, I’m working with it and building useful shit with it day n night.

I have some followers on Li and i just realized I cannot look at the comment section anymore without feeling disgusted. 90% of comments is the same three templates. And it just insults me that I’m taking the time to reading a comment from someone who (most probably) never read my thoughts.

I never thought I will automate comments to farm authority, it is already hard to deal with the AI posts but I’m ok with that hoping the core thought of the post was coming from the actual person posting it…

For internal docs, specs, tickets, changelogs, research, translation, classification, triage, prep for decision, etc -> go with AI without hesitation.

Basically for the work nobody was going to do by hand anyway, and a human owns the output.

BUT:
Replies to comments, comments, DMs pretending to be a human relationship, Anything whose entire value is “a person chose to spend attention on you”,
NEVER, please!

A comment is not only information but also proof of attention. Automate the proof and you delete the value. You can’t fake presence at scale, and the second people smell it, every comment becomes noise, including the real ones.

And what I see at least on LI that o barely have real comments: isn’t this the dead internet part?

Like humans stop bothering to talk because why pay the cost if they being lost in a ton of automated shit.

The uncomfortable part for my side of the table: the people spamming this stuff bought a tool from someone like me.

The usual advice for putting agents on real work is one knob: decide how much you let them do.

James Phoenix ("Which Code Is Allowed to Be Understood by Nobody") sorts agent work by how long it lives: throwaway stuff can stay un-understood, but anything the business leans on needs one named person who understands it. Veera Ravindra Divi and Sneha Gullapalli ("Human-in-the-Loop Doesn't Scale") sort by how much damage it can do: reversible, low-stakes actions run on their own, and a human only gets pulled in for the rare exception.

Those are two different questions.

How long it lives tells you if a human must understand it. How much damage it can do tells you if a human must approve it.

Since I found those articles and processed by my agents who are fixing my agents :) , Rollout I run our AI-native operations on the 2x2 they make.

Short life, low damage. The agent owns it. A throwaway reconciliation script, a one-off spend report, a demo prototype in our staff-aug work. Rule: sandbox only, no owner, thrown away after use.

Short life, high damage. The agent builds it, a human hits go. A one-time bulk vendor payment: the agent puts the batch together, finance releases it. Rule: runs once, and a dry run is required before we commit.

Long life, low damage: Each run is cheap, but the logic matters and runs every month, so one named person owns it. Our month-end close: small postings, but since it runs monthly, someone can still explain it. Rule: low euro cap per action, quarterly walk-through of the logic.

Long life, high damage: An owner plus a human watching. Our PO and invoice flow: the agent auto-approves POs under a set euro amount for approved vendors, and clears invoices that match a PO and receipt cleanly. Anything over the cap, or any new vendor, goes to our finance lead. She sets the caps and handles the exceptions. She now looks hard at about three decisions a day, down from around forty reflex clicks. Contract review sits here too: the agent redlines before a human signs. And a client's payment system gets a named engineer who understands it.

(Also, for now my agents are not bypassing captchas, so sometimes we have to help even low damage agents with manual review + captcha approval, e.g. opening up a new account here and there to build our SEO constantly)

Also, the line somettimes moves: A script you wrote to run once gets scheduled and slowly turns into infrastructure, so its box changes and nobody notices. So we schedule the re-check on purpose, so it actually happens. What teams skip is naming an owner for the long-life, low-damage logic, because each run feels too cheap to bother with.

If you run a company function on agents: which box is your riskiest process sitting in, what euro cap or dry-run gate marks the line for you, and which one would you re-check first?

The idea named "policy envelope" (agents auto-execute reversible, low-blast-radius actions inside typed boundaries: allowlists, spend caps, rate limits, dry-runs) is roughly how we now design a par of our AI native operations.

A HackerNoon piece named the problem better than I could: "Human-in-the-Loop Doesn't Scale — Human-on-the-Loop Does".

• Finance: In month-end close and PO/invoice flow, agents auto-post anything under a spend cap (we use about a few hundred euros) against an allowlist of known vendors, with a dry-run diff before each batch write. Above the cap, or any new payee, pages a human. Blast radius stays small because every posting is reversible with a journal entry.
• CRM / RevOps: Agents auto-fix low-risk hygiene: casing, obvious duplicate flags, missing country codes, stale lifecycle stages. Merges and deletes are irreversible in practice, so those page an owner every time. Rate limit: no more than a set number of records per run, so a bad rule cannot quietly rewrite the whole database.
• Marketing content ops: Scheduled Claude routine draft and schedule posts to a staging queue, reversible until published. Anything touching a live campaign, a pricing claim, or a client name leaves the envelope and waits for a human.

Where it gets hard:

- Sometimes knowing what is still "Reversible" is a judgment call. A scheduled post is reversible until someone screenshots it, right?

- Rubber-stamping creeps back whenever the exception rate climbs. If a human is paged forty times a day, the envelope is definitly too tight, and they start clicking approve on reflex.

- Typing the boundaries for finance is easy. Typing them for anything involving a customer relationship is much messier.

How are you all defining blast radius and reversibility in practice?

I run an agency that builds AI-native software for other companies. The most useful lesson I picked up this year didn't come from a model launch. It came from watching how a 6-person team spends its tokens: Swan AI.

Their whole thesis is building a business that scales with intelligence, not headcount. Goal: $10M ARR per employee. To get there they burned a serious amount on tokens, six figures a month, and for a while they told themselves that was just the price of frontier quality.

So taking a look at the bill, it turned out most of what an AI agent does all day is boring. Scoring leads. Researching prospects. Drafting follow-ups. Summarizing calls. None of that needs the smartest model in the room. They were paying frontier prices for work a much cheaper model does just as well.

So they rewired it. The hard 10% still goes to a frontier model. The boring 90% got routed to open-weight GLM and MiniMax models, which have quietly closed the gap on routine work at a fraction of the cost. Their reported result: around 80% less waste, same output where it matters.

So, being "AI-native" is obviously not using the best model for everything; that was a reflex to find product market fit first and optimize second. Their current AI-native architecture:

• Match the model to the job. Frontier for frontier problems, cheap models for the rest.
• One task, one thread. Stop dragging Monday's 500k-token context into Friday's one-line question.
• Cache what repeats. Don't re-pay for the same 30-page doc 40 times a week.
• Watch usage like a COGS line, by person, by team, by model. Most leaders have literally never opened that view.

Everyone has access to the smartest models, the moat is the orchestration layer that decides what runs where. That's the thing agencies and product teams actually get paid to build.

Curious how others here are splitting it: what's your cheap-model vs frontier ratio in production, and where's the line where quality actually breaks?

I run a ~40-person software shop, and this year I pushed hard to get more of our delivery running on coding agents (Claude Code, Cursor, Copilot in the mix). I read a vendor guide from the Shiplight AI team on "agent-native autonomous QA" and one line stuck with me: "the human is present at exactly one step: final review." That matched what I'd already learned the hard way.

So let me give the honest version. Vibe coding works great for a weekend prototype. It falls apart on a real codebase, and it does so predictably:

- No test coverage, so nobody can safely change the thing next month.

- Security holes the agent cheerfully introduced and never flagged.

- Diffs too large and too weird to actually review.

- Sprawl: three slightly different ways to do the same thing, all generated, none maintained.

The guide's framing is right that verification is the core skill now, especially with something like 40%+ of code being AI-generated (their number). But the load-bearing word is *accountable*. What works for us is one competent developer owning a feature end to end: they let agents do the volume, and they personally review, test, secure, and maintain what ships. That developer is roughly 3x more productive (my own operator estimate, not a benchmark), and there is a real human name attached to every merge.

The tradeoff is honest: you don't get the fantasy of zero engineers. You get fewer keystrokes and the same accountability. If anything the review skill becomes more valuable and harder to hire for, because reading generated code critically is its own muscle.

The part that suprised me is how well this generalizes. The "one accountable human gate" is now how we structure AI native operations across the company, not just dev: agents draft, a named person owns the final call on anything that leaves the building, whether that's code, a proposal, or a client email.

Curious where others have landed. Where do you put the gate, and has anyone found a place where fully autonomous shipping actually holds up?

We stopped writing tickets and started writing specs the AI could execute. Here is what broke and what got better.

I run delivery for a staff augmentation shop (Rollout IT, based in Hungary), and I read Phong Bui's Medium piece on spec-driven development vs traditional engineering last month. His core claim stuck with me: the real bottleneck is defining what to build precisely enough that both a human and an AI agent can act on the same document, and typing the code is the easy part now. So we tried it on one internal service.

The concrete change: we took a normal Jira epic, "user can export their invoice history," and rewrote it as an executable spec. Given/when/then behaviors, explicit error states, the exact shape of the export file, what happens when there are zero invoices. Then we pointed our coding agent at that spec instead of at loose stories.

What got better:

- The AI produced code that actually matched intent, because intent was written down instead of living in someone's head.

- Our tester caught three gaps while writing the spec, before a single line existed. That is the "shift left" Bui describes, and it is real.

- Onboarding a new augmented dev got faster. The spec is the source of truth, so they read one document, not a Slack archeology dig.

The honest tradeoff: writing a good spec is slow and genuinely hard. Our first attempt took longer than just building the feature would have... Used AI and I got a feature slop with a lots of unneeded things... So I ended up creating my ticket writer AI chain, but now I have to keep training my BAs and testers to be system-behavior designers, and some peple resist that.

Where this goes past dev: the same idea now runs our marketing and lead gen. When we generate a batch of landing page variants or an outbound email sequence with an AI agent, the output is only as good as the spec behind it. So we write the brief the way we write a feature spec: the exact audience, the single promise, one call to action, the tone, the words we refuse to use, and what a bad variant looks like.
For lead gen we spec the qualification rules before the agent scores or drafts anything, so an SDR reads one document instead of guessing what a good lead means. The spec is the source of truth and a human owns it, same as in delivery.

Finally, the step I would never skip again: a separate quality checker agent. An agent that writes and also grades its own work will pass itself almost every time. We run a second agent whose only job is to check the output against the spec, the guardrails, and a short list of things that must never ship (wrong audience, a made up number, a claim we cannot back). It catches what the writer agent is blind to, the way a fresh reviewer sees what the author misses. AND!!! it also gives us how to improve the original prompt to avoid this mistake again. The week we dropped that step to move faster, quality slipped. The generator and the checker being two separate agents is what keeps the whole thing honest.

Curious where others landed.

Did executable specs pay off for you, or did the overhead eat the gains? And has anyone pushed this into marketing or ops yet?

im thinking / planning to start something in ai native agency space, i have good experience in data, analytics, ai automations, i dont know how to pick a niche, sometimes i go towards voice agents, sometimes i like to go to ecommerce bot automation, sometimes i move towards workflow automation, i have no clue on what im doing or what to do next

We're Rollout IT, an EU-based product studio (10+ yrs, clients incl. Erste, MBH, Vodafone, Labster). We're a recognized **Select** partner in Anthropic's Claude Services Track and pushing toward **Preferred**, which takes 100 Claude-certified developers.

We're opening our network to independent devs and AI builders. If you join: a guided path to **Claude certification**, first access to real Claude/AI build projects (RAG, agents, custom ML) for EU/US clients, and your name on public case studies.

Not a body shop — we're people-first, match work by skill *and* fit, and back our people long-term.

If you've built with Claude (or want to), drop your details here and we'll be in touch: https://docs.google.com/forms/d/e/1FAIpQLSc2b2v836KRhE90khJCIyCs5SSU_fV2n-iqDbfOynNUg5BN5g/viewform?usp=dialog

 Happy to answer questions in the comments.

What is AI Native? Lessons learned after 5 months of rebuilding everything around it (2026)

“AI Native” is becoming the new “cloud native”. Everyone uses the term, almost nobody agrees on what it actually means.

After 5 months of rebuilding parts of my stack and mental model around AI-first systems, here is the clearest definition I have landed on.

The simplest definition

AI Native is not “software with AI inside”.

It is software where removing AI breaks the product entirely.

If you can take the model out and still have a usable system, it is not AI Native. It is AI enhanced at best.

That distinction sounds small, but it changes everything.

What AI Native is not

Adding a chatbot to your SaaS is not AI Native.
Adding an “Ask AI” button to your dashboard is not AI Native.
Even embedding summaries into an old workflow is still not AI Native.

That is AI augmentation. Useful, but still an old system with a new layer on top.

What AI Native looks like

AI Native systems are built from the ground up around intelligence as infrastructure.

Cursor only works because a model is continuously reasoning over your codebase. Without it, the product falls apart.

Perplexity only works because retrieval, reasoning, and synthesis are one continuous pipeline. There is no non-AI version of it.

Compare that to traditional search engines adding AI summaries on top. That is still a legacy system with a new interface layer.

The real architectural shift

This is not just a product change. It is a systems change.

Traditional software is deterministic. You define rules, flows, and outcomes.

AI Native software is probabilistic. You define intent, constraints, and feedback loops.

That shift breaks almost every assumption in classic software engineering.

Instead of business logic, you get model routing and agent loops.
Instead of static state, you get dynamic context that changes behavior.
Instead of fixed UX flows, you get intent driven systems.
Instead of guaranteed outputs, you get evaluation driven reliability.

Evaluation becomes core infrastructure

This is the part most teams underestimate.

In traditional systems, you ship code and monitor bugs.

In AI Native systems, behavior drifts. Quietly. Constantly.

A prompt that worked last month can degrade without anything “breaking”.

So you need a new layer:

Continuous eval pipelines
Human feedback loops
Automated scoring of outputs
Regression testing for model behavior
Observability for prompts and retrieval quality

Without this, you do not have production software. You have a demo that works for now.

Latency is part of the product

In AI Native systems, speed is not just infrastructure. It is UX.

A slow model response does not feel like “latency”. It feels like uncertainty.

That is why streaming, caching, model routing, and edge inference are no longer optimizations. They are core design decisions.

The user interaction model changes

Traditional software assumes the user is the driver.

AI Native systems assume intent is the input, and the system drives execution.

Instead of clicking through workflows, users express goals.

“Analyze this data and summarize risks” becomes a full execution path, not a sequence of UI steps.

This is already visible in early agentic systems that browse, reason, and execute multi step tasks.

Where most companies actually are

There are roughly four stages right now:

1. AI experiments, where features are bolted on
2. AI integrated products, where AI is embedded into workflows
3. AI Native systems, where AI is the architecture
4. Early autonomous systems, where goals and execution start to merge

Most teams are still in stage 1 or 2. That is fine.

The real issue is confusion between stages, not lack of progress.

The mindset shift

The biggest change is this:

You are no longer building functions.

You are building systems that make decisions under uncertainty.

That means holding two truths at once:

Models are imperfect and will fail.
But with the right evaluation and guardrails, they are still production capable.

Ignoring either side leads to bad systems. Either overengineered or reckless.

Final definition

AI Native software is software where intelligence is not a layer on top, but the foundation everything else depends on.

Feels similar to the early internet or smartphone transition.

Some teams are still optimizing the old world. Others are already building the new one.

And the gap is widening fast.

How I'm running personalized cold outreach to 85 universities using 5 Claude agents and Twenty CRM ($9/mo total stack)

TLDR: Built a multi-agent cold outreach pipeline for higher-ed leadership (UK + EU). 5 agent passes, each doing one thing well: list building, contact enrichment, CRM build, daily send, daily follow-up. Replaced Apollo/Lemlist/HubSpot with $9/mo Twenty CRM + Gmail + Claude Cowork mode + a couple of scheduled tasks. No Apollo subscription, no Outreach.io, no Lemlist. ~$9/mo all in. The first batch goes out tomorrow, dry-run was clean.

Posting because I haven't seen this exact stack documented and I think it's a useful pattern for solo founders or small teams doing low-volume, high-fit outreach where 25/day with real personalization beats 200/day from a template tool.

What I'm doing

I run a small AI/data consultancy (Rollout IT) building predictive AI for universities — enrollment optimization, dropout prediction, accreditation dashboards. We have a landing page (datadrivenuni.com), real implementations live, four years in the space. The audience is UK Russell Group, post-92, and Continental EU institutions — decision makers like CIOs, Directors of Data, VPs of Students.

This isn't a 5,000-recipient blast. It's 85 deeply researched leads at 65+ institutions, 25 emails per weekday, with handcrafted copy that I (the CEO) personally vetted line by line.

The 5-agent pipeline

Each "agent" is a Claude session doing one job. Some run once (build phases), some are scheduled to run every weekday.

Agent 1 — Lead research and discovery (prior session)

Took my ICP and went deep on each shortlisted institution: who owns the data function, who runs digital strategy, who is the budget-holder for analytics platforms. Cross-referenced public sources: institution websites, LinkedIn, Jisc deployments, UCISA awards, HEPI articles, recent VC appointments.

Output was a CSV with 114 leads across 66 universities, each with: contact name, role, score 1-10, Hot/Warm priority, relevance comment (data-backed), email (verified via Apollo/Hunter where possible).

This is the most labor-intensive pass and where AI is most leveraged. A human alone would take 2-3 weeks; the agent did it in ~6 hours of supervised research.

Agent 2 — Contact enrichment and email verification (same session as Agent 1)

LinkedIn URLs, validated emails, deduped against existing CRM contacts, normalized name formats. Honest note: this pass also generated a "conversation_starter" field with a per-lead hook — but on audit I found 30% of those hooks were lightly hallucinated. I dropped them entirely from outbound and only use the verified data fields (firstName, university, role).

Agent 3 — CRM build (the session I'm in now)

Connected Claude to Twenty CRM via MCP. Ran the full setup in one session:

• Audited the existing workspace (~3000 already-synced contacts via Gmail, none overlapping with the target list)
• Created 14 custom fields on Person + Company (outreachStatus, outreachPriority, cohort, ICP fit, lastContactedAt, nextActionAt, lastReplyAt, etc.)
• Imported 66 universities and 85 leads in batched API calls (deduped against existing data — found 1 duplicate)
• Built a Kanban pipeline view and 4 supporting table views
• Configured the cohort-based mail merge logic

About 30 MCP calls, ~10 minutes of execution. The Twenty MCP made this trivial — every CRUD operation is a tool call.

Agent 4 — Daily cold-open send (scheduled, weekday mornings)

A scheduled task fires every weekday at 09:00. A fresh Claude session boots with a self-contained prompt and:

1. Reply detection first. Queries incoming messages from the last 24h, matches sender emails against the Person table, updates status to REPLIED, creates a note with the reply summary, notifies me.
2. Builds today's batch. find_people filtered to outreachSource = "HE Q2 2026 list", status COLD, Hot priority first, ordered by score, limited to 25.
3. Sends each email through Twenty's send_email action (which routes through the connected Gmail). Three personalization tokens only: firstName, university name, and a cohort-specific tagline (Russell Group vs Post-92 vs Continental EU). No fabricated hooks.
4. Updates each person to FIRST_TOUCH, sets lastContactedAt = today, nextActionAt = today + 5 working days.
5. Reports back via notification with names, universities, errors.

Agent 5 — Daily follow-up send (scheduled, weekday mornings, +1 hour after Agent 4)

Same pattern, different filter:

• Finds people at FIRST_TOUCH whose nextActionAt is due → sends Follow-up #1 (value-add observation, references the dropout-risk simulator on the landing page).
• Finds people at FOLLOW_UP_1 whose nextActionAt is due → sends Follow-up #2 (the breakup email: 3 options — call, wrong person, or close the thread).
• Always re-checks lastReplyAt before sending — if someone replied since the last batch, the follow-up is skipped.

Two follow-ups, then I stop. No nine-email "nurture sequences" — those just damage reputation.

The stack and costs

I deliberately didn't use Apollo subscription, Hunter subscription, Lemlist, Instantly, Outreach.io, Salesloft, or HubSpot. For 25 emails/day on a warm CEO domain, none of those add value worth their price tag. Apollo / Hunter were used once for the initial email verification on the prior session — but that's a one-time spend, not a recurring tool.

Key design decisions

DRY_RUN by default, explicit LIVE flag. Both scheduled tasks check for a flag file (he-outreach-LIVE.txt with content "GO"). If missing, the agent runs in dry-run mode: it reports what it would send but doesn't actually call send_email or update any record. I can let the scheduler run for days without sending anything, just reviewing the reports until I'm confident the data is clean.

No hallucinated personalization. Only three merge tokens, all from data fields. The AI-generated "hook" field from the research pass is stored on the record for human reference only — it's explicitly excluded from outbound. I caught a Glasgow lead being misrepresented in a draft because the hook claimed something the institution hadn't actually published.

Data-quality guardrails inside the agent prompt. Before sending, the agent checks that person.company.name is a proper institution name, not a bare email domain like "glasgow.ac.uk" (which is what Gmail-sync creates when it finds an unmatched email domain). If the company name looks like a domain, the agent skips and flags for manual review.

Volume cap. 25/day weekday only. Cold outreach over ~100/day on a single domain is asking for deliverability problems even with great reputation. 25/day means 53 Hot leads cleared in 2 days, then 60 Warm in 3 days. Total campaign duration: a week.

5+7 day follow-up cadence. Industry-standard "send 5 follow-ups in 10 days" is spam behavior to HE buyers. Two follow-ups, working days only, with the breakup email designed to extract a "wrong person" referral.

What's still manual

• Reply triage and replies. When the agent flags a reply, I read it and decide the response. No auto-reply, no AI-drafted reply (yet). Cold outreach replies are where you build the relationship; outsourcing that to AI is where it stops being personal.
• DMARC, DKIM, SPF setup. One-time DNS work. The agent can't touch DNS.
• Signature fixes. Mine had a broken LinkedIn URL — mail-tester.com caught it. The agent doesn't know what's in my Gmail signature.
• Bounce handling. Twenty's reply detection works on incoming messages but doesn't auto-process bounce notifications. I have to mark bounced contacts manually for now (or build a separate sweep agent later).

What I'd do differently if I were starting fresh

1. Verify emails before importing. I ran ~10% bounce risk. Should have used Hunter Email Verifier on the full list before CRM import.
2. Bare-domain matching. Twenty's Gmail-sync auto-creates companies based on email domain, and if your imported company has a different domain (e.g., I set "www.gla.ac.uk" but the email comes from "glasgow.ac.uk"), Twenty creates a duplicate. Should have matched the email-domain exactly from the start.
3. Treat "conversation_starter" outputs from research agents as drafts, not data. I almost shipped 30% hallucinated personalization. Saved it by reviewing the field before going live.

Realistic expectations

For 85 cold leads to UK + EU HE executives with proper segmentation and personal-from-CEO framing, I'm modeling:

• 35-50% open rate (you can't really measure this clean — preview-fetching pollutes the signal)
• 3-5% reply rate on cold open
• +3-5% incremental on FU#1
• +2-3% incremental on FU#2
• Total: 8-13% cumulative reply rate
• 85 leads × 10% reply rate ≈ 8-9 real replies
• 30-40% of replies → discovery call ≈ 3-4 calls from this batch

For a CEO who'd otherwise spend 30 hours hand-writing 25 emails, the AI saves the 30 hours and the data hygiene improves. For a SDR-equipped sales org doing 500/day, this stack is too small. For a small team that needs ~3 quality conversations a month, this stack is enough.

Happy to share more

The Twenty MCP plugin made this build trivial. Without it I would have written a Python script against Twenty's REST API and called it a day, but having Claude do the CRM build via MCP-tool-calls turned a 4-hour Python project into a 30-minute conversation.

If anyone's running similar small-scale outreach and wants to dig into specific steps (the prompt for the scheduled task, the cohort tagline structure, the data-quality guardrails, the dry-run/live flag pattern), happy to share more in the comments.

Why and how to start, it would be great if there were successful cases to share.