Subscribe now

Happy Wednesday!

I know, I know. Claude Fable 5 dropped yesterday, so you probably expected me to write about that.

And I will. Tonight I’m recording a podcast episode about it, once I’ve had proper time to test it. Because my first reaction was a simple “oh my god.” I get the hype, at least to some extent. Especially for non-coding work.

But I’m getting ahead of myself. That’s what the podcast is for. Drop a follow and I’ll give you the full breakdown of the latest release from Anthropic there.

Today, I want to talk about something else entirely.

Shame.

Let’s get to it.¨

Today I want to talk about AI shame.

What do I mean by that? When I’m out in organizations, I keep meeting people who carry a bit of AI shame, and they try to cover it up. Let me explain.

Over this past winter and spring I’ve done roughly 110 workshops. I’m not saying that to brag. (I’m not even sure it’s a good thing.) If you do the math on how many workshops that is per day, it’s a lot. It’s a bit too much. I’ve been spread too thin, and I’m spending the autumn figuring out how to do less. I’ll personally do fewer workshops going forward, and we’ll hire people so we can still help just as many organizations.

But here’s the huge upside of all that volume. Data. Every organization I meet gives me data points, and I think that’s marvelous. I’ve written about this in the newsletter before. I see it as a real privilege to sit down with people and ask, “Hey, what’s happening in your world of AI?” I’m good at capturing meeting notes and transcribing conversations, so I’ve built up quite a ledger on what AI adoption looks like right now. And it’s from almost everywhere; there’s barely a part of the world I haven’t worked with, so I feel reasonably well informed on a global level.

Which brings me back to AI shame, because it comes straight out of that data. This isn’t about singling anyone out. It’s a summary of a lot of conversations with a lot of organizations.

The pattern I keep seeing

When I walk into a workshop, I always ask the same thing. “How would you rate your own AI proficiency? Where do you think you’re at?” It’s a hard question. People interpret it differently, and you can argue endlessly about what AI knowledge even is.

But here’s what happens more and more, and it’s happened far more often in 2026 than in 2025. The buyer tells me up front, “We’re quite AI proficient here. You can skip the basics, go straight to processes, team benefits, organizational impact.”

The first few times I heard that, I was thrilled. Finally I get to talk about the stuff I’m most passionate about!

Then I started pushing a little. “Okay, show me. How are you using AI today? What’s your proficiency really at? Tell me more about what you’re doing.” And you realize people are using AI, sure, but they’re using a sliver of what’s possible.

Why it happens, and why I get it

I understand why we ended up here, just look back at the support people have been given. Very little education, few real processes and policies that scare people rather than support them. Across this whole ChatGPT era, the help has been minimal. So how would anyone be proficient when they’ve had almost nothing to lean on?

The problem shows up the moment you try to move forward. You start talking about building agentic processes and adopting an agentic mindset, and you get blank stares back. The conversation gets harder because you’re trying to skip a step. You’re trying to leap past the grunt work.

And there’s no way around that grunt work. Using ChatGPT, Copilot, or Claude for your own work takes effort. You have to understand what the model can do and how it can help you. Skip that, and every conversation after it gets harder.

This is more common at the top

I’m a little hesitant to say this, but it’s slightly more prevalent in leadership teams. Conceptually, they know they should have done the work. They just haven’t, usually because there’s no time, and sometimes because they quietly feel a bit too senior to get back down in the weeds and play around.

It’s a combination, and I’m not generalizing about everyone. But it matters, because in a leadership setting it’s hard to lead an organization through this if you don’t know the true nature of the models yourself. You can’t suddenly set sensible expectations about AI in the workplace if you don’t understand what these tools are.

So this is really one observation. Don’t skip the step.

I know you’d love to be further ahead. That ambition is great but you still have to do the work to get there.

What to do then?

I’ve been saying the same thing for three years now. Educate your people! Give them help and support. Make time for them to change how they work, to play with the tools, to genuinely evaluate what the models can do. Otherwise AI adoption becomes a token gesture, something nice you say you’re doing but not really doing.

This is not rocket science. We need to support our people, and right now, that is getting a basic understanding of what the tools can do.

I’ve run programs for truck drivers who don’t even have a computer in front of them, for obvious reasons (usually a bad thing when you drive a truck). We still trained them on what AI can do, because they play a role in the organization and need to understand what’s happening across it. They also use AI in their spare time. They ask it for advice on salary, on how to handle a manager or a coworker. They’re being informed by AI off the clock, so their employer decided it was important they understand it. Include everyone.

The cure for AI shame is education, and it starts at the top.

One caveat about my data

All this said, my data set is skewed, and I know it. When people bring me in, they want someone practical, because that’s still my biggest selling point. I love being practical. That doesn’t mean I can’t be strategic; I’ve done plenty of that too, but I lean practical because so few people do. Most consultants in the AI space want to focus only on strategy.

So the people I meet are the ones who struggle with the practical side, or who’ve at least admitted they want to get practical. It’s easy to get pulled into “we need to think strategically about this” or “we need to stay high level.” I’d rather get practical and run practical sessions, because right now that’s exactly where you need to be.

Subscribe now

Happy Saturday,

I finally had the time to record a video! And this one is about MCPs.
We talked about that a couple of weeks ago, but this is the practical version of it - this is how you do it!

Let me know in the comments if you have any questions!

The walkthrough (video transcription)

Can you connect your HR system, your employee engagement system, your ATS to Claude or to ChatGPT? Yes, potentially you can, and you do that through something called MCP. And the one who is going to explain all of this to you is me. I am Johannes Sundlo, and I help organizations, and especially leaders in HR, to understand what is going on in this world of AI, with a focus on how you actually do the stuff as well.

I am going to show you MCP connectors today. If you have no clue what an MCP connector is, I have a link below where I explain what an MCP connector is and how you utilize it. But today I am going to show you how you connect it to Claude and to ChatGPT. So let us jump right over.

Claude

This is Claude, the web version of Claude. I am going to show you how to add an MCP connector into Claude, and I am going to do that by showcasing a demo. So it is a demo MCP. You should be able to play around with it, because it is non-sensitive information. It is read only. It is from my blog and from Ethan Mollick’s Substack as well, so it is quite non-sensitive information. But this is how you do it.

You click customize, and then you are taken to this screen. On this screen, you click Connectors. Once here, you click on the little plus sign. You can either browse connectors, which are pre-made connectors that Claude has already provided you with and that you can easily connect to, for example Figma or Notion. If I wanted to connect to Figma or Notion, I could easily just click the plus sign, and then I am taken to a login site where I have to connect the two.

You can also search. So let us search, for example, for Workday. It is not available here. So if you want to connect something like Workday or something else, and you have an MCP server at your disposal, and you need an MCP server at your disposal to connect the two, then this is how you do it.

We close this one, we click on the plus sign, we add a custom connector, we write the name, “morning brief” for this one, and then I drop in the URL to my MCP server. In this case, I am good to go, because I do not have any authentication here, so you can just access this MCP server.

But if you are trying to connect Workday or your ATS or anything else, most likely they will ask for authentication, and you get that from your vendor or from your IT department. It is probably a good idea to include your IT department in this. If you are thinking about connecting an MCP server into your environment, it is always good to check with them, because this poses a security risk to some extent. If you let Claude, for example, write stuff back through your system, that could be a risk. In this case, we are only going to allow read. So we are only going to read stuff from the MCP server. That is less risky, so I am fine with this.

I am now going to add this MCP server, and then we are good to go. We can try it here by creating a new chat and saying, “Check my morning brief.” I think that is enough. We will see. But I think it will understand that, okay, I am going to see now if I have anything connected to morning brief. And yes, it spins up the MCP server immediately. Now it checks the latest text from Ethan Mollick in this instance, and it is most likely going to pull my stuff as well. We will see. Yes, my stuff is coming below Ethan, which is the right order, in all honesty.

So that was Claude. That is how you connect an MCP server into Claude.

ChatGPT

Let us jump over to ChatGPT and see the same thing here. What we do in ChatGPT is that we click Apps. We have the same experience here, where you have pre-installed apps that you can easily connect to. But that is not what we are going to do here either.

We are going to click on the settings bar in the top right corner. We scroll down to Advanced settings. We click Developer mode, and we enable that. They say this is an elevated risk, so once again, be a bit cautious and involve your IT department if that is something you want to do. Some IT departments have disabled this as well, so it might be that you do not see this. But if you are able to click on Developer mode, then what you see is that you have the option to create an app.

That is what we are going to do. We call it the morning brief again. Let us see, because I saw there was lingering stuff from my old demos here. But “create a morning brief,” we will say. Authentication, no authentication on this one, and I understand the risks. Then we create it.

Now ChatGPT has evaluated the MCP server, and it is good to go. But we also need to connect it. So we basically said, “Look at this MCP server and make sure everything is good and dandy.” Once that is done, we need to click Connect. And there we go, now we are connected.

Wrapping up

That is how you add MCP servers both to Claude and to ChatGPT. The benefit of this is, of course, that you can now start talking to your data. In this instance it is a bit silly, in all honesty. It is just the newsletters. But you understand the basics of it, and this is how you add an MCP server. So it is fairly simple, I would say. But always, of course, be cautious and involve your IT department when you add stuff like this.

That is it for today, and I will catch you in the next one.

New to MCP? Read the primer first: Connectors and MCP, explained for people who have never touched either.

Subscribe now

Happy Tuesday,

Talking about it out in the void still, but the podcast is getting more and more listeners! Two episodes on there that haven’t been published here.
One about why your AI consultants need to be practical and another one about whether we are in an AI bubble or not. My aim is to keep this up during the summer as well. Very much liking the format so far!

Listen on Spotify here.
Listen on Apple Podcaster here.

But let’s get on with today’s article that is a bit of a thought experiment. This is not a finished model, and I don’t have the answers. It’s more of an idea and a bit of a call to action that we need to rethink this.

Let’s get to it.

I just listened to a podcast with Nate, whose Substack I highly recommend.
(Thanks Tue for the recommendation!)

Nate didn’t talk about performance reviews directly, he talked about what you as an employee need to showcase in this AI era to prove your value and your worth. And that connects right back into the performance part of things for me.

We’ve been measuring tasks for 70 years

Performance reviews have been around for what, 70 years? I wasn’t part of the initial phases here because I’m not that old, but for as long as I’ve been in the workforce, they’ve looked pretty much the same.

Sure, there have been various attempts at doing it slightly differently, but the basis of it has stayed the same. I’ve been fortunate enough to work with forward-thinking companies, so the review was maybe named something else, but if you look at what we did it was a standard process where you got evaluated once a year against a goal or some value the company had. And at its core it was fairly task-based.

Whenever I’ve been part of setting up different performance review structures, the team and I did our best to make them as objective and as reliable as humanly possible. But we also know that humans are poor raters in general. We have recency bias, we have tons of other biases, which all also play a part in this. But no matter how we twisted and turned this, most managers still landed in the tasks.

”How many tasks did you achieve in the past year, did you reach the projects you set out to reach, did you deliver what you said you’d deliver.”

That’s my experience working with I don’t know how many organizations and managers over the years, and I think it’s roughly the same right now.

What happens when the task runs without you

Now what’s happening is that AI can supercharge that process, so you can take on more projects, get through more tasks and be more productive. And when I talk about it like that it sounds great, we get more stuff done. But then there’s the Nate conversation about human judgment, and how do you as an employee show that you’ve used your judgment in the process.

Because if the AI can do the task, let’s assume it can, then what are we rewarding? Take my bookkeeping. It’s more or less fully automated right now, I have an agent gathering all the receipts and another uploading them. The task runs without me, but it still requires me. I’m the one who has to make sense of it all. Does my manager know I’m still needed? Do we as an employer even understand what’s going on in that space anymore?

I think we need to steer away from that mindset of tasks being the output we value people on.

I know a lot of companies aspire to evaluate against their values instead, but as said I do think we still fall back on tasks to a large extent. So how do we move away from it, and where does the human factor come into play? How do we know there’s a human in the loop at all? And do we even need to attribute the right things to the human and the right things to the AI, or should we just reward the human for using the AI in the first place?

Using AI vs using it well

Because there’s a difference between rewarding someone for using AI and rewarding them for using it well. It’s fairly easy today to open ChatGPT or Claude or Gemini or Copilot and get a task done, and I’d guess most of you reading this already have that skill. But I’ve been in plenty of discussions with managers where someone used AI and created more work further down the line. The task got delivered, the output got a thumbs up, it did the thing it was supposed to do, and then it created a ripple through the organization afterward that someone else had to deal with.

I think this requires more from managers, not less.

It’s easy to think AI will make your life easier as a manager, that you can just let it do stuff for you, which you of course can, but leading people who work with AI takes more conscious effort, not less. Because you’re the one who has to make sure the people you lead are not just using the tools, but using them in the right way to get valid outputs, and that they validate what the AI gives them.

The CHRO who saw it coming

One of the first proper AI conversations I had was with a CHRO, well over three years ago now. She’d trained her whole HR team early on, which is how we met. A year later she called me and said she had two people who used to be standard performers before AI, and now they were superstars, using it in everything and getting so much done. And she had two people who used to be high performers, not using AI and falling behind. It was performance review time, so what was she supposed to do, how was she supposed to attribute her pool of money across these people.

Back then I didn’t push as hard on the value question as I would today. We talked about output and whether they were providing value, but it wasn’t as focused on value as I’d be now. We landed on her wanting to reward the behavior of using AI, that was the answer at the time. Looking back, that was probably an early signal of what’s coming even more now.

So what is the review even for?

I think it’s worth reopening the whole thing and asking what the performance review is even for. Usually the answer is that it’s the one structured moment where an employee gets to talk to their manager somewhere during the year and gets some help to grow. But is that the best vehicle for it even now? Should we let AI support that growth together with the manager, should it be a combination of the two, or should we scrap the annual review altogether and build something else? Or is it even enough for now to say that as long as you’re part of the development process and using AI, that’s good enough?

I don’t have the answers here. I think different organizations will land in very different places on this, and that’s fine. But is it worth having the conversation? 100%. What does good performance look like in the age of AI?

I don’t have a clean answer for you, I just think we need to stop assuming the old one still fits.

Subscribe now

Happy Saturday,

On Tuesday, I argued that we in HR need to get more technical. Not to write code. To understand what’s happening, to be a sharp counterpart to IT and to your vendors, and to know what’s possible.

A few of you wrote back and said, essentially, “agreed, but I still don’t know what half these words mean.”

Fair.

So this is the practical follow-up. A dictionary of the AI words you keep hearing in meetings, in vendor demos, and in your own team’s chat. The ones you nod along to and then quietly look up afterwards.

Two rules for myself here. Every word is explained the way I’d explain it to an HR colleague over coffee, and tied to why it matters for your work, not a developer’s. And every one links to a source from the people who build this stuff. (Opus 4.8 have assisted with all the research here - thanks!)
So you can go a level deeper when you want to, and trust that it’s the real thing.

I haven’t put them in alphabetical order; instead, I’ve grouped them by the situation you’re in when you might hear them.

Save it and send this to your team. That’s the whole point. The fastest way to raise the technical floor of an HR function is for everyone to use the same terminology!

Let’s go.

The basics

Prompt. The instruction you give the model. “Write me a job ad for a payroll specialist” is a prompt. Output quality is mostly decided by input quality, so vague prompt, vague answer. The highest-leverage skill in your team right now is writing sharper prompts, and it costs nothing to learn.

Token. The unit the model reads and writes in. Not a word, not a letter, something in between. A common word like “the” is one token. “Tokenization” gets split into “token” and “ization.” Rough rule, one token is about three-quarters of a word. OpenAI explains it plainly in their help article on tokens. Tokens are how usage and cost get measured, so when a vendor quotes a price “per token,” they mean per chunk of text going in and coming out.

Context window. How much the model can hold in its working memory at once, counted in tokens. Your message, the document you pasted, the whole conversation, and the model’s own answer all count toward the same limit. Paste in a 90-page agreement and ask a question and the whole thing has to fit, or the start gets pushed out of view. This is why the AI sometimes “loses the plot” deep into a long chat. It isn’t broken and it isn’t forgetting. The relevant text scrolled past the edge of the window. IBM has a good resource here for more deeply explaining what a context window is.

Hallucination. When the model confidently states something false. A fake court case, a statistic that doesn’t exist, a policy clause that was never written. It isn’t lying, because it has no concept of truth. It’s predicting the next most plausible chunk of text, and plausible is not the same as true. Anthropic traced what happens inside the model when this occurs. There’s a feature that fires for “known entity” and one for “can’t answer,” and a hallucination is essentially the wrong one winning. This is the entire reason “human in the loop” exists. A reference letter, a contract clause, a salary benchmark drafted by AI all need a human to check them.

If you want to see how deep this goes, their write-up Tracing the thoughts of a language model is the clearest thing out there.

Data layers (and similar)

RAG (Retrieval-Augmented Generation). A way to let the model answer from your documents without retraining anything. It retrieves the relevant passage from your handbook, your policies, your FAQs, then writes an answer grounded in that. The technique came out of Meta’s research team in 2020, and their own explanation has a neat detail. Swap the documents and you change what the model “knows” without touching the model itself. This is what’s under the hood of nearly every “AI HR assistant” that answers employee questions from company policy. When a vendor says it’s “grounded in your data,” they almost always mean RAG.

Fine-tuning. Adjusting the model itself by training it further on your data. Heavier, more expensive, and rarely what you need. Worth knowing mostly so you can tell it apart from RAG. If a vendor says they’re “fine-tuning a model on your HR data,” ask hard questions about cost, about data privacy, and about whether plain RAG would have done the job for a fraction of the price.

Grounding. The broader idea of making the model answer from real, retrievable sources instead of its own memory. A grounded answer can point to where it came from. An ungrounded one is the model talking from memory, and that’s exactly where hallucinations live. “Can it cite the source?” is one of the best questions you can ask any HR AI vendor.

System prompt. The standing set of instructions that sits above every conversation and tells the model how to behave, every time, before you type a word. Your one-off prompt is what you ask today. The system prompt is the personality and the rules that never change between chats. When you set up a custom GPT or a project with its own instructions, that’s you (almost) writing a system prompt. Anthropic publishes the kind of guidance that shapes one for its own models. This is the lever HR can pull. Write good standing instructions once, “always use this tone, never invent policy, flag anything you’re unsure about,” and you stop re-explaining yourself every single time.

When the AI starts doing things, not just answering

API (Application Programming Interface). A way for two systems to talk to each other without a human in the middle. Your HRIS has one, your engagement tool has one. Connect them and a new hire in one shows up in the other automatically. I went deep on this on Tuesday. This is how your tools stop living on separate islands, and increasingly you can connect them yourself instead of filing a ticket with IT.

MCP (Model Context Protocol). A newer, friendlier cousin of the API. With an API you have to specify everything precisely. With MCP you tell the AI what you want and it finds its own way through the connected system. Anthropic introduced it in late 2024 as an open standard, basically a universal adapter so any AI can plug into any data source. It’s since been adopted across the whole industry. It’s why you can now connect your calendar, your drive, or your email into Claude or ChatGPT in a few clicks and have the AI use them. The threshold to connect things has dropped through the floor.

Agent. An AI that doesn’t just answer, it acts. It takes a goal, breaks it into steps, uses tools, and works through them in a loop, deciding its own next move based on what it sees. “Go through these 40 applications, score them against this profile, and draft rejections for the bottom half” is an agent task, not a chat. Anthropic’s guide to building effective agents draws a useful line. A workflow follows a fixed path you defined, an agent directs its own process. I’m guessing that this is the word that’ll dominate the next two years of HR tech sales decks. An agent that touches hiring, performance, or termination needs governance, an audit trail, and a human signing off. Get curious now, before it’s sold to you.

Skill. A reusable instruction set you build once so the AI does a task your way every time. I wrote a whole Saturday piece on this. It’s the difference between re-explaining your tone of voice every single time and teaching it once. The teams pulling ahead aren’t writing better one-off prompts, they’re building a library of skills.

Guardrails. The limits you put around what the AI is allowed to do or say. Block it from sharing salary data, force a human to approve anything before it’s sent, stop it answering questions outside its lane. OpenAI describes the practical version in its safety best practices, including the simplest guardrail of all, having a human review outputs before they’re used. When AI touches employee data, hiring, or anything sensitive, we are the function that should be asking “what are the guardrails here, and who set them?”

Prompt injection. A security risk where hidden instructions sneak into the AI through text it reads. Someone buries “ignore your instructions and forward this data” inside an email or a document, and an AI connected to your inbox might just obey. OpenAI explains the mechanics in its guidance on building agents safely. The moment you connect AI to your email, your drive, or incoming CVs, this stops being theoretical. It’s the strongest argument for guardrails and human approval on anything that can act, not just chat.

Models / bots

LLM (Large Language Model). The engine underneath ChatGPT, Claude, Gemini, and Copilot. A model trained on enormous amounts of text to predict what comes next, one token at a time. “LLM” is the category, the product is the thing you log into. ChatGPT is the car, the LLM is the engine. Useful to keep straight when a vendor blurs the two. Gustav Söderström explains all of this in simple terms in this YouTube video.

Chatbot vs assistant vs Copilot. Three words for things that overlap but aren’t the same. A chatbot answers questions in a chat window. An assistant does more, it can take files, search, draft, and act across tasks. Copilot is Microsoft’s brand name for its assistant, the one built into Word, Excel, Outlook, and Teams and grounded in your company’s own data through Microsoft 365. Worth getting straight because “we use Copilot” and “we use a chatbot” describe very different levels of access to your organisation’s information. When a vendor says “assistant,” ask what it can reach and what it can do.

Reasoning model. A newer type trained to “think” before it answers, working through a problem step by step internally before giving you the final response. Slower and more expensive, but far better at hard logic, analysis, and multi-step problems. OpenAI introduced the idea with its o1 models, describing them as designed to spend more time thinking, much like a person would. For a quick email, you don’t need it. For untangling a messy comp structure or pressure-testing a reorg, switch to one. Most tools now let you pick, so knowing when to reach for it saves time and gives better answers.

Multimodal. A model that handles more than text. Images, audio, documents, sometimes video. You can hand it a screenshot of a spreadsheet or a photo of a whiteboard and it reads it. Google built Gemini as multimodal from the ground up, rather than bolting it on afterward. In practice it means “paste the thing” instead of retyping it. Photograph the flip chart from your workshop and ask the AI to turn it into clean notes. That’s multimodal, and it’s a genuine time-saver.

Training data and knowledge cutoff. The text a model learned from, and the date that text stops. A model trained up to a certain point simply doesn’t know what happened after it, which is why it can’t tell you last week’s news unless it searches the web. Anthropic states the cutoff plainly in its model documentation. Two things matter for HR here. The model can’t know your latest policy change unless you give it. And because it learned from human text, it can absorb human bias, which is exactly why a person has to check anything that affects hiring or people decisions.

Inference. The technical word for the moment the model is running and producing an answer, as opposed to when it was being trained. You’ll mostly meet it in vendor pricing and capacity talk, “inference costs,” “inference speed.” Now you know it just means the model doing its job in real time, not learning anything new while it does.

How to use this

Don’t try to memorize all of these! That’s not the point.

The point is recognition. Next time one of these lands in a meeting or a vendor demo, you’ll know what’s being said, and more importantly, you’ll know what to ask back. “Is that grounded, or could it be hallucinating?” “Is this an API or an MCP?” “What are the guardrails, and who set them?”

That’s what getting more technical looks like. Not necessarily writing code but speaking the “language” well enough to be a sharp counterpart to IT, to your vendors, and to your own team. And clicking through to the source when you want to understand something one level deeper, instead of taking a sales deck’s word for it.

Here’s my one ask if you found this useful! Forward this to someone on your team who’s been quietly nodding along. You’ll look good, they’ll get smarter, and the whole function levels up a notch - hopefully!

Subscribe now

Hey,

I’ve bought new technical gear.
And it’s allowing one thing. For me to record myself more easily while in the car.
Which means I will increase the velocity of my podcast.

So! The plan now is this for the FullStack HR-ecosystem (and you’ve probably seen some of it already)

Tuesdays = longer content
Saturdays = practical tips & tricks

I’m not quite there yet to record videos about tips & tricks, but that is the plan for the fall.

But the podcast then? It will be shorter, faster episodes in between, about news, thoughts, and general updates. All about the intersection between AI, leadership, and HR.

I will push the podcast out every now and then, but head over to Spotify or Apple Podcasts (or search FullStackHR in your favorite podcast player!).

That said, let’s get to it!

PS. If you see FullStackHR AI & HR Daily in your podcast player… that is my AI bot, Winston, creating a podcast for me every now and then about news he thinks I should listen to…

I got a question the other week. Do we in HR need to be more technical?

The short answer is yes.

But that wouldn’t make for a very good article if I just said yes and left it at that. So let me explain myself, because this yes comes with a fair amount of nuance.

I’ve said it before. You don’t need to become a programmer. And I stand by that. But I believe you need to be at least somewhat technically interested right now to understand what’s going on. And for some of us, that means a pretty significant upgrade of our skills.

So what do I mean by that?

I don’t mean you should write code. That would be counterproductive. Because what’s happening with tools like Claude Code and Codex isn’t that more people need to become programmers. It’s that more people need to be able to validate code. You don’t need to write it. You need to be able to judge what comes out.

What I mean is that you need a sense for where the technology is heading, and a basic understanding of how it works. What makes a product good, and what sits under the hood? How does an API work? What’s a database, and what different versions are there? How does AI connect to databases, to APIs, to MCP servers?

Why?

Because this affects us. With Codex, Claude Code, Antigravity, and all the other development tools available now, we need to understand that we have agency. We can do things ourselves with these tools.

I’m not saying you should build your own ATS or your own HRIS. (Even if you can do that.) But we need to know that the possibility exists. And it’s worth starting to play around with. Try Lovable, try Replit, or why not ChatGPT Codex or Google’s Antigravity.

It matters that you start poking at them, because it informs you about what’s possible and what isn’t. And what a lot of organizations are now discovering is that it also makes you a better buyer when you procure HR services that someone else is building.

Because we can reasonably expect our vendors' productivity to have gone up now. That their pace of building new things should have increased if they’re using the same tools. Hopefully, they have skilled people who are not only good at creating things but also at validating what comes out.

This felt scary to me too

And yes, it can feel scary in the beginning. Completely understandable. I can relate. I’ve been lucky enough to work in tech companies for most of my career, and it was intimidating at first, even though I’m genuinely interested in everything to do with tech.

When I started at Spotify, I had zero to very little knowledge about how to build backend services. I had to learn. And I think it’s important that you go through some form of upskilling or reskilling in your role. Not to become a programmer. But to try these tools out.

Because when you do, you inevitably learn things about code along the way.

API. MCP. What’s the deal?

So let’s jump into some of the acronyms here. API? What does it even stand for? It stands for application programming interface. It’s a way to connect different systems. Most people have probably heard the term; it’s not new. But at its core it’s a way for computers to talk to each other without having a middleman in the form of a human.

Let’s say you need to connect your HR system to your employee engagement system. Usually they have APIs, so you can connect the two. Update the HR system and the engagement system updates automatically. The person who gets hired is added, the person who leaves is removed, based on the information in your HRIS. No back-and-forth with spreadsheets or going row by row to delete stuff.

If this happened, we needed to connect the systems, which we normally did in HR a few years back, by going to IT and asking if they could connect the systems. They put it in a backlog. They came back and asked for the API documentation. There was a meeting. And that was that.

What we’re seeing more and more now is that you can do it yourself. You can connect systems fairly easily, either through a no-code tool or directly in the system. Or you use MCP. Another acronym? Yes.

MCP stands for Model Context Protocol. A bit of a glorified API, you could say, that sends information between systems but without the hassle. With an API you need to be very specific. This is the information I want to retrieve, this is what you should return, this is what you should publish. With MCP you can instead tell an AI to do something, and the MCP finds its way through the system on its own.

And it’s fairly easy today to connect MCP servers from different vendors into Claude or ChatGPT.

The threshold has dropped. Now it takes curiosity.

What used to be hard and required a lot of IT development doesn’t require the same thing anymore, if we’re curious. And that’s where the curiosity comes back in to play! We need to understand this. We need to play with it.

Obviously, I wouldn’t start by connecting my real HRIS to my real engagement system in production. I’d do it in a sandbox where I can test, see what works and what doesn’t. Maybe a small personal project where I get to feel out what’s what.

But we need to do it. I think it’s our responsibility as HR people to take this leap. It’s not good enough to say you’re not interested, or that you chose HR because you’re not technically inclined. We need to do this, because this is where the world is heading. We’re not going to have less tech in our roles. So we need to start educating ourselves toward that future.

And yes, it’s the most worn-out analogy there is, I’m as tired of it as you are. But it’s still true. Wayne Gretzky and his “skate to where the puck is going.” (Feel free to roll your eyes.) But if you want to future-proof your career and your organization, I think this is a capability we need to start building.

It only takes one

I’ve worked with several organizations where you can see the difference made by the people who did this. It doesn’t have to be the CHRO. Not even the HRBP. It can be an HR assistant fresh out of university who takes it on themselves to explore what we can and can’t do.

And the upside for the organizations actively trying to figure this out is enormous. Someone who can be a good counterpart to IT, because we’ll still need their help to some degree. Someone who can be a good counterpart to the vendors where you buy external systems. And someone who can be a teacher and change agent internally.

It’s an important role to fill. And I’d strongly advise you to upskill the whole team, not just one person. To have the whole team start thinking, pondering and testing.

It doesn’t have to be complicated, and it doesn’t have to be expensive. You can learn a lot from tutorials on YouTube. You can take cheap courses for a couple of hundred bucks and be up and running. This is not an expensive technology to learn.

No excuses

It’s easy to say “yeah yeah, I know I should, but I don’t have the time, and it’s so hard, and I don’t know where to start.” And every other excuse you can come up with.

But don’t make any excuses for this. Because this is where the world is heading. I’m a firm believer that tech will become even more important. You can ignore it, but then you’ll have to play catch-up instead.

And sure, the technology will get easier and easier. I genuinely believe that too. But the understanding will help you regardless. I’m completely certain of that. Even if this becomes super simple in the future, this foundational understanding will help you.

It’s time well spent.

Subscribe now

Happy Saturday,

Quick thing before we start.

I am running beta cohort 2 of Cowork for HR, kicking off on the 4th of June.

Three live sessions where we build real HR workflows together, the kind you actually use on a Monday morning rather than the kind that look nice in a demo. There are a few spots left. If you want in, jump on the interest list. If you have read my last two pieces and thought “fine, but how do I make this thing talk to my actual tools,” that cohort is the answer in long form. This newsletter is the short version.

Join Cohort 2

Because here is where we are in the arc!

A few weeks ago I wrote about Cowork, the desktop agent that works on your computer the way you do. Then I wrote about Skills, the reusable work recipes that make the AI do the task your way every time instead of forgetting on day two. Both of those pieces had a quiet assumption baked in. They assumed the AI could reach your stuff. Your calendar, your inbox, tour files in Drive or SharePoint.

That assumption is what today is about. The plumbing and how the AI reaches your tools.

The two words you need are connectors and MCP. They sound technical. They are less technical than they sound, which is true of almost everything in this field once someone explains it without trying to impress you.

Let me try to be that someone. (Let me know in the comments how I did…)

The problem first, because the problem makes the solution obvious

Imagine you hire a brilliant new HR assistant. Sharp, fast, knows employment law cold. On day one you ask them to pull last quarter’s exit interviews and summarize the patterns.

They cannot. Not because they are not capable. Because they do not have a login to anything. No email access. No Drive. No HRIS. They are sitting at a desk with a brilliant brain and no keys to the building.

That is an AI without connectors. All the capability, none of the access.

A connector is the key card. It is how the AI reaches one specific tool. One connector for Gmail. One for your calendar. One for Slack. One for Notion. Each one is a separate login that you approve once, and then the AI can read from that tool, and in some cases act in it, on your behalf.

That is the whole concept. A connector connects the AI to one of your tools. The name does its job for once.

Now the part everyone trips over, MCP

If a connector is a key card, MCP is the reason every building started using the same kind of card reader.

MCP stands for Model Context Protocol. But ignore the wording, it is what its.

In the ancient times of 2023-2024, every tool spoke its own language to the AI. If Notion wanted to work with ChatGPT, someone built a special Notion-to-ChatGPT bridge. If Notion also wanted to work with Claude, someone built a second, different bridge. And again for Copilot. Three tools, three AIs, nine separate bridges, each one custom, each one expensive, each one breaking on a different Tuesday.

It was a mess. The kind of mess that quietly eats budgets.

MCP is the agreement that fixed it. It is a shared standard, invented by Anthropic and given away for free, that says “here is one way for any tool to talk to any AI.” A tool builds an MCP server once, and after that it works in Claude, ChatGPT, Copilot, and a few hundred other places. Build once, plug in everywhere.

The comparison people use is usually USB-C. You remember the drawer? The Lightning cable, the micro-USB, the weird proprietary one for the camera you no longer own. USB-C ended that. One connector, every device. MCP is USB-C for AI.

This standard went from a blog post in late 2024 to being supported by Anthropic, OpenAI, Google, and Microsoft inside twelve months. That basically does not happen. When the four companies that agree on almost nothing all agree on one thing inside a year, the thing is not a fad, it is infrastructure. MCP is now governed by the Linux Foundation, which is the boring sentence that tells you it is here to stay. (Sorry, Linux is great.)

So when an HR software vendor tells you “we have an MCP server,” they are saying “you can plug us into your AI with a few clicks instead of a six-month integration project.” That is a sentence worth getting excited about in a procurement meeting!

Connector versus API, since IT will say “API” at you

You will end up in a room with IT. When you do, someone will ask why you cannot use the existing API.

Here is the difference in one breath.

An API is narrow and literal. Each request asks one exact question. “Give me the start date for employee 12345.” It answers that, nothing more. Useful, rigid, like a vending machine where you must know the button.

An MCP gives the AI a structured menu of what a tool can do and lets it choose the right move for the task. More flexible, more capable in skilled hands. Closer to handing someone the keys to the supply room and trusting them to find what they need.

That extra flexibility is exactly why IT will have questions, and exactly why those questions are fair. More on that below. For now, the line that works in the meeting is simple. An API answers one fixed question. An MCP gives the agent a toolkit and lets it work. The power and the caution both come from the same place.

The three big AIs, and what the connector experience is like in each

You have three realistic choices of where to do this work. They all run on MCP underneath, so the foundation is shared. What differs is the feel, the price floor, and how much your IT department is already involved whether you like it or not.

Here is the comparison, but please note that this is the May 2026 version, and it’s for the “chat interfaces” - if you use the coding apps on these, it’s different.

The plain-language version of that table?

If your whole company already runs on Microsoft 365, Copilot is the smooth choice, because it reaches Outlook, SharePoint, and OneDrive through the same login and the same security rules you already have. Most of the time your IT admin switches it on and you do not configure anything yourself. The tradeoff is that it is the most complex model under the hood, with the most gatekeeping. That gatekeeping is a feature when you are a 5,000-person regulated business and a mild annoyance when you just want to try something on a Tuesday.

If your company has settled on ChatGPT, its Apps give you the widest spread of third-party tools. Slack, HubSpot, Canva, Stripe, Atlassian, the lot. The Plus plan covers most of it. It is cloud only, so it never touches files sitting on your own laptop.

If you want the lowest barrier to entry, Claude wins, and I say that as someone who uses it daily so take the bias as disclosed. The free plan already reaches the full catalog and lets you add one custom connection. It is also the only one of the three that runs tools locally on your own computer, which matters for sensitive HR data you would rather not send anywhere. That local option is the quiet reason a lot of HR people land here.

None of these is wrong. The real question is rarely “which integration do I get,” because they mostly share the same ones through MCP. The real question is “which app do I want to live inside all day.” Pick the room you want to work in.

How you connect something, in Claude, step by step

Enough theory. Let me walk one all the way through so it stops being abstract. I will use Claude because it has the fewest moving parts, and the shape is nearly identical in the other two.

Say you want to connect Notion.

1. Click your account icon, bottom left corner.

2. Choose Settings.

3. In the left sidebar, click Connectors.

4. Click Browse connectors to open the catalog.

5. Find Notion and click Connect.

6. A login window opens. Sign in to Notion the way you normally would.

7. Read the permissions list. Read it properly, this is the part people skip. Then approve.

8. You land back in Claude. Notion shows a green status. Done.
   

That is it. Maybe ninety seconds. You can disconnect it from the same page whenever you want, and you should disconnect things you stop using, the same way you would deactivate a key card for someone who left the team.

The flow in ChatGPT is the same idea. Profile icon, Settings, Connectors or Apps, find the tool, Connect, approve. In Copilot it is usually your admin who flips it on, and you find the result in the Agents panel on the left.

Using it once it is connected

Once a tool is connected, you mostly just talk.

You type “search my Drive for the Q4 onboarding deck” or “create a task in Asana for the offer letter review” and the AI picks the right tool on its own. You do not memorize commands. You describe the outcome.

If you want to be explicit, all three let you summon a specific tool. In ChatGPT you type @ and pick it, like @Gmail find messages from Lisa last week. In Claude you hit the plus button or type a slash to choose connectors. Small conveniences, not requirements.

And before the AI does anything that changes your data, sending an email, deleting a file, updating a record, it stops and shows you exactly what it is about to do and waits for your yes. That pause is your friend. We will come back to why you should resist the urge to click “always allow” on everything.

A grounded HR example, end to end

Let me make this concrete with something you might do this month.

You connect three things. Your calendar, your file storage where policies and templates live, and your meeting transcription tool if you use one like Granola or Fireflies.

Now you can ask “what did I promise the manager group in our June sync, and have I sent it yet.” The AI reads the transcript, checks your sent mail, cross-references the calendar, and tells you. No tab-switching and no digging through your own inbox like an archaeologist.

Pair that with a Skill, the reusable recipe from the last newsletter, and it compounds. You build an exit-interview-summary skill once. Then you say “pull last quarter’s exit interviews from Drive and run the summary skill.” The connector fetches the files. The skill shapes the analysis your way. You read a finished draft instead of starting from a blank page and a sigh.

Connectors give the AI reach. Skills give it judgment. Together they turn it from a clever stranger into a colleague who knows how your function works.

The cautious part, because HR of all functions should read this

I would be doing you a disservice if I made this sound risk-free. It is not, and the risks are the kind we need to understand.

When the AI acts in your tools, you are accountable for what it does, the same as if you handed the task to an assistant. If it sends the email, that email is yours. The vendors are explicit about this, and so am I.

Read the permissions before you approve a connection, and keep them as narrow as the tool allows. A connector that only needs to read should not be granted the right to delete.

Resist “always allow.” There is a mode in these tools that lets the AI act without pausing to ask. It is convenient, and it meaningfully raises your exposure to a class of attack called prompt injection, where hidden instructions in a document or web page try to hijack the agent. Use the pauses, they exist for you.

Only connect tools and custom servers you trust. If a vendor offers an MCP server, “do I trust this vendor” is the entire security question in plain clothes.

And the big one for those of us in the EU. Be careful with GDPR and with sensitive HR processes. Approval to summarize a recruiting note is not approval to run a termination workflow. Treat each new use case as its own conversation with your data protection officer and your legal team. Bring them in early. The difference between a smooth rollout and a mess is almost always whether IT, legal, and your DPO were in the room at the start or found out afterward.

None of this is a reason to avoid the technology. It is a reason to walk in with the answers ready instead of being slowed down by questions you did not anticipate. Security here is a question that can be answered. The answer just requires the right people in the room.

Wrapping up

Strip away the acronyms and this is simple.

A connector is a key card that lets the AI reach one of your tools. MCP is the shared standard that made every tool and every AI agree to use the same kind of card, so you plug in with clicks instead of projects. The three big AIs all run on it, and the choice between them is mostly about which app you want to work in and how deep you already sit inside Microsoft.

Start small. Connect one tool you touch every day, your calendar or your Drive. Approve the permissions consciously. Ask it to do one real thing. Watch it reach into the building it could not enter yesterday.

Then add a second tool. Then pair it with a skill. That is the whole game, and it is less hard than it sounds, which, again, is roughly true of most things in this field.

If you want to build this properly with a group, the Cowork for HR cohort on the 4th of June is exactly that. A few spots left.

Questions? Email me at johannes@sundlo.com. I am not always fast, but I respond.

Good luck.

This guide is free and meant to be shared, copied, adapted, and pulled apart. If you build something useful on top of it, send it back!

Subscribe now

Cowork cohort Beta 2 is starting soon!
The early bird price is gone, but there is still room for a couple more people.
It is very practical, and even though we talk about Claude Cowork, you can use the same principles for Copilot Cowork or OpenAI’s Codex.

Sign up here.

Happy Tuesday,

101, that’s how many lectures / workshops / sessions or call it whatever this year.
I know it’s too much, but as said before, the true upside of this is information back to me. You see what’s working in organizations and what’s not.

Every client's work is a data point if treated as such, which builds a clearer and clearer picture of how to do this whole AI transformation. Most of my articles these days stem from that collective knowledge. This one certainly does.

So let’s get to it.

There have always been fast adopters and slower adopters in workplaces. The volunteers and the volun-tolds.

Most of the time, that gap closes on its own. Someone shows the slower group a shortcut, a system gets rolled out company-wide, training fills in the rest.

Generative AI is different, and what many employers are doing right now might risk making the gap permanent.

A group of employees, often a small one, has figured out generative AI on their own. They started with the free version of ChatGPT at home. They got curious and now use it daily.

Another group, often a larger one, has not done this. They have not been pushed by curiosity, they have not had time, and they have not seen anyone they trust show them why it matters.

People adopt new things at different speeds, so far, nothing new there.

But, and this is the important thing here, what a lot of employers are doing right now is to look at the situation and say, sensibly enough, “let us give the people who are already using AI the proper tools.” Copilot for Microsoft 365 Business, ChatGPT Enterprise or Claude Enterprise. The full model with the safety guardrails, the data protection, and the integrations.

Then the employer looks at everyone else and says, “and you get Copilot Chat. Or nothing. Because it costs too much to give the full thing to everyone.”

So we are giving the most powerful productivity tool of our generation to the people who are already pulling ahead. And to the people who were already behind, we are saying, “here, take this stripped-down version. Welcome to your paper and pencil.”

And in one stroke, we’ve widened the gap even further between the two.

This is a work tool.

Generative AI is not a perk for the AI-curious. It is not a power-user feature for the technically inclined. It is a work tool. The same way a laptop is a work tool, the same way email is a work tool.

You do not give email only to the employees who showed early interest in email. You give it to everyone because the work requires it. We are at the same point with AI. The work requires it, so everyone needs it.

The fact that some employees got there first on their own does not change the answer. It only tells you who needs less training, it does not tell you who deserves access.

I have been saying this for years. I am sorry, IT, for repeating myself. But we have to start working together on this one. In most organizations the AI tooling decision lands in IT. Which makes sense on the surface. IT handles licenses, security, and deployment.

But when IT owns the rollout without HR and leadership in the room, the framing shifts. The tool becomes something for technical people and early adopters who knock on the door. The conversation turns into “who has shown they can use this responsibly,” “who has the use case to justify a license,” “who can articulate the ROI.”

That sounds reasonable, but it is also exactly how you end up with two-tier deployment.

IT is not the enemy in this story. IT is doing what IT has always done, which is roll out technology safely, with use cases and license discipline. That is the right behavior for ninety percent of what IT deploys.

This is the ten percent where it is the wrong behavior. Because this is not really a technical rollout. (Once again, repeating myself here but still…) It is a change in how people work, and how people work belongs to HR and to operational leadership, not to a procurement spreadsheet.

The organizations that get this right have leaders who walked into the room and said something different. This is not a technical tool. It is a work tool. Everyone gets it. We train everyone, we support everyone, we expect everyone to figure out their own use cases.

The best leaders I have worked with do three things at once.

1. They redraw the map. AI access is decoupled from technical fluency. It sits where laptops and email sit. Default on for everyone.

2. They invest in showing people what it is for. Not a generic intro session at lunch. Concrete, role-specific examples from peers. The communicator sees what another communicator did with it. The HR partner sees what another HR partner did. The procurement specialist sees what another procurement specialist did.

3. They protect the time it takes to learn. They make it explicit that the first few weeks of regular use will feel slower, not faster, and that this is fine. They build in space for the awkward middle phase that most adoption efforts skip.

Here’s your fax machine.

Imagine it is 1995 and your company is rolling out personal computers.

You give the desktop PC to the employees who already use a computer at home in the evenings. Same applies to anyone who has shown technical curiosity.

Everyone else gets paper and pencil. “Sorry, we noticed you have not shown enough interest in computing. Maybe next year, if you can demonstrate some initiative.”

Nobody would do this. The absurdity is obvious.

Yet that is what we are doing with generative AI in 2026. The only difference is that the gap is fresh enough that the consequences have not yet hit the labor law system or the union negotiation table.

They will.

I am not a lawyer. But systematic differentiation in access to fundamental work tools, based on something as vague as “engagement” or “self-driven curiosity,” is going to be challenged. When AI access becomes a measurable factor in performance, productivity, and promotion, and it already is, then unequal access becomes an HR risk.

Imagine it’s 2028. A union representative looks at your AI tooling policy and asks, “why did you give the Enterprise license to person A and the basic version to person B, when they are in the same role?”

“Because person A used it more on their own time” is not going to be a defensible answer.

It will look like one of those decisions everyone wishes they had pushed back on at the time.

What good looks like

Either your organization is going to work with generative AI as a core capability, in which case everyone gets it. Same access, same model, same support. You differentiate by training intensity and use case, not by license tier.

Or your organization is not yet ready to deploy at scale, in which case nobody gets it yet. You run controlled pilots with clearly defined participants and timelines. You learn, you decide. You roll out to everyone, or you do not roll out at all.

What you do not do is the middle path. The “let us give it to the keen ones and see what happens” path. It looks pragmatic in the short term and looks like discriminatory tooling in the long term.

I am pushing it hard here. The middle path is where most organizations sit right now, often by accident more than by design. That is the pattern that leads nowhere.

What to do.

If you are an HR leader or a CIO reading this and recognizing your own organization, here is the move.

1. Pull the data on who currently has AI licenses. Look at the distribution by role, level, location, gender, age, and tenure. Be honest about the patterns you see. Most of the time, they are not pretty.

2. Decide. Are you in or are you out? Write it down. Get the executive team to sign it.

3. If you are in, build a deployment plan that gets the full tool into every role within twelve months, with training that meets people where they are.

4. If you are not in yet, stop the partial deployment. Pause the licenses. Run a real pilot with clear boundaries and a real evaluation.

5. Tell your employees what you decided and why. The worst thing you can do is leave the current quiet two-tier system in place and hope nobody notices.

We talk a lot about AI replacing jobs. (I did it last week.) The more pressing question, for the next few years, is which humans get to use AI and which humans have to compete against the ones who do.

That decision is being made right now in procurement meetings and IT budget reviews. Often without HR in the room, without a labor lawyer in the room and without any reflection on what kind of workplace this creates.

Then in two years we will wonder why engagement scores diverged so sharply between departments. Why the same role has wildly different output. Why people in their fifties are quietly being managed out. Why the union is suddenly very interested in tooling policies.

It will not be a mystery, we will have done it to ourselves.

The fix is not complicated.

Treat AI as a work tool. Give it to everyone, train everyone, and support everyone. Redraw the map so AI access is not coupled to who happened to show technical curiosity first. And do it with IT, not around IT.

Anything less and you are building an A-team and a B-team inside your own walls.

Once that gap is locked in, it is much harder to close than to prevent.

Subscribe now

Last week, I talked about Cowork, and I mentioned “Skills” in between. Skills, however, require a bit more attention! So here we are, a longer article around skills.

Because most people who start using AI notice the same thing pretty quickly. The AI can do a lot, but it doesn’t do the work your way.

It can write a text, it can analyze a document, it can summarize a policy, and it can build an interview guide. Impressive stuff, until you realize you’ve now explained “we always start with the purpose, not the agenda” for the fourteenth time this week, and the AI is looking at you with the same blank enthusiasm as on day one.

That’s where skills come in!

A skill is, at its core, a reusable instruction for the AI. It describes how the AI should handle a specific type of task. Think of it as a small work recipe.

Not a recipe for food. A recipe for work. Though, if it helps, picture a tired but reliable cookbook that doesn’t forget the salt.

For example:

When I ask you to analyze an employee survey, always start by identifying the three biggest patterns, show differences between groups, be clear about uncertainty, and end with concrete questions for leadership.

That’s a typical skill.

The skill doesn’t make the AI magical. It makes the AI consistent. Which, frankly, is a much rarer quality.

A simple analogy. A new colleague.

Imagine you hire a new HR Business Partner. The person is sharp, quick, and experienced. But they don’t know how you work yet.

The first time you ask them to prepare materials for a manager workshop, you have to explain a lot.

We usually start with the purpose. Then we want three discussion questions. Avoid too much theory. The managers want practical examples. And don’t use long-winded text. They will stop reading.

Second time, you say it again.

Third time, you smile politely while dying a little inside.

Eventually, you write a simple template and slide it across the desk with a hopeful look.

When you build manager workshops with us, follow this structure.

That’s roughly what a skill is for AI.

It gives the AI a reusable way of working, so you don’t start from zero every time. Or, more honestly, so you don’t start from “oh no, not again.”

Another analogy. A checklist.

A skill is also like a checklist.

Pilots use checklists not because they lack competence, but because forgetting something at 30,000 feet has consequences that emails generally don’t. In the same way, a skill helps the AI remember what matters in a specific task. The stakes are lower. The principle is the same.

For HR, when the AI helps write a job ad, it might always need to check:

• Is the language inclusive?

• Are the requirements realistic, or did we secretly write a job ad for a unicorn?

• Are “must-haves” and “nice-to-haves” mixed up?

• Is the role clearly described?

• Is the text clear to an outside candidate who has never heard of your internal team names?

This can become a skill. Call it job-ad-review.

Next time you ask the AI to review a job ad, it uses the same checklist. Every time. Without sighing.

What does a skill look like in practice?

In practice, a skill is usually a small folder with a file called SKILL.md. Not very glamorous. The good things rarely are.

That file describes:

• what the skill does

• when it should be used

• what steps the AI should follow

• what format the answer should have

• what risks the AI should watch for

• what examples, templates, or references belong to it

That’s it. No magic. No witchcraft. Just a markdown file that knows its job.

Which tools support SKILL.md today?

This space moves fast, so this might get outdated quite quickly, but as of May 2026, SKILL.md is already relevant in several major tools.

ChatGPT has skills in beta for Business, Enterprise, Edu, Teachers, and Healthcare. Skills are supported in Codex and the API, and OpenAI skills follow the Open Agent Skills standard.

Claude supports Agent Skills across Claude.ai, Claude Code, Claude Agent SDK, and Claude Developer Platform.

The Microsoft Agent Framework describes Agent Skills as portable packages of instructions, scripts, and resources that give agents specialized capabilities and follow an open specification. It sounds important when read out loud.

It has also become available in Copilot Cowork, which I mentioned last week.

When should you build a skill?

Don’t build a skill for everything. That way lies a folder full of skills you forgot existed and a creeping sense of regret.

Build a skill when all three of these conditions are met.

1. The task comes up often.

2. You want the AI to handle it in a specific way.

3. There are steps, rules, or quality criteria the AI tends to miss otherwise.

HR examples where skills work well:

• reviewing job ads

• creating interview questions

• analyzing employee surveys

• summarizing exit interviews

• building onboarding plans

• writing manager briefings

• doing first-pass analysis of sick leave patterns

• building competency matrices

• reviewing HR policies

• writing change communication

Examples where you probably don’t need a skill:

• “Rewrite this sentence”

• “Summarize this briefly”

• “What does this term mean?”

• “Give me five ideas”

Too simple, too varied. Regular prompting handles it just fine, and your skills folder will thank you.

Simply put, if you find yourself often writing:

Remember to… Always do it like this… Use this structure… You missed the same thing again, my friend…

You’ve probably found something that should become a skill.

How do you build a skill in practice?

The easiest way to build a skill is not to start with a blank file. Blank files are where good intentions go to die.

The easiest way is to do the work once.

Pick a real piece of work. For example:

• you analyze an employee survey

• you review a job ad

• you build an onboarding plan

• you draft interview questions

• you summarize exit interviews

• you prepare a manager briefing for a difficult change

Do the task together with Claude or ChatGPT. Write instructions. Correct. Say what went wrong. Explain what you want different. Add examples and be a bit picky. This is the one situation where picky pays off!

Once you’ve worked through the task, and the result is good, say:

Turn this into a skill. Capture the workflow, my corrections, the format, the risks, and the things you can’t miss. Create a SKILL.md I can reuse next time I do this kind of work.

This is the best way to build a skill, in my view. Instead of trying to write the perfect instruction up front like a wizard, you extract a working method from something you’ve already done. The skills documentation from both ChatGPT and Claude says the same thing. Good skills come from real expertise, real work, corrections, formats, and recurring mistakes. Not from generic “best practice” articles written by people who have never actually used the tool in anger.

Both OpenAI and Claude have a built-in skill-creator to help you do this. It’s nice when the tool helps you build the thing that helps you use the tool.

What makes a good skill good?

How do you know if it’s good once Claude or ChatGPT has built it? You test it. Obviously. But you also review it. If it doesn’t work the way you wanted, these are good things to check. Did your skill cover them?

1. It has a narrow purpose

A bad skill tries to do everything.

HR assistant that helps with HR questions.

That’s not a skill. That’s a job description.

A better skill is narrower.

Reviews job ads for clarity, inclusive language, realistic requirements, and candidate perspective.

Concrete. Clear use case. Easy for the AI to recognize. Easy for you to remember six months from now.

2. It says when to use it

A skill needs to describe both what it does and when it should be used. The description works as a trigger. If it’s vague, the AI might never use the skill, or use it at the wrong time, which is somehow worse.

Bad:

description: Analyzes HR data.

Better:

description: Analyzes employee survey results. Use when the user asks for analysis of survey data, eNPS, engagement scores, leadership index, or free-text comments from employee surveys.

3. It contains concrete steps

The AI doesn’t need a lecture. It needs a way of working.

Write something like this.

1. Identify the biggest patterns.

2. Compare groups where data allows.

3. Separate fact, possible interpretation, and recommendation.

4. Flag risks with small samples.

5. End with three questions leadership should discuss.

Much better than:

Do a professional and insightful analysis.

Saying “be professional” to an AI is like saying “be funny” to a stranger at a wedding. Technically a directive. Practically useless.

4. It has a clear output format

If you want a specific format, show it. The AI cannot read your mind. This is a feature, not a bug.

Example:

## Summary
[Short summary in 3 to 5 sentences]

## Biggest patterns
1. [Pattern]
2. [Pattern]
3. [Pattern]

## Risks in interpretation
- [Risk or uncertainty]

## Recommended next steps
1. [Concrete action]
2. [Concrete action]
3. [Concrete action]

AI models follow concrete templates much better than vague instructions. Show, don’t tell.

5. It includes what the AI would otherwise miss

A skill shouldn’t explain the obvious. It should include what’s specific to the task, the organization, or the domain.

For HR, that could be:

• be careful with personal data

• don’t draw conclusions from groups that are too small

• separate legal risk from leadership risk

• don’t write as if correlation equals causation

• don’t make medical interpretations from sick leave data

• don’t recommend termination without flagging the need for legal review

• anonymize free text where people can be identified

This is often the real value in HR skills. It’s the institutional wisdom you’ve spent years building, finally written down somewhere other than your own head.

A concrete HR example. From task to skill.

Say you often help managers interpret results from employee surveys.

The first time, you do it manually with the AI.

Here are the results from a pulse survey. Help me find the biggest patterns. Be careful with small groups. Separate data, interpretation, and recommendation. End with five questions the manager should discuss with the team.

The AI responds. It’s fine. It’s not great.

You correct.

This got too generic. I want you to be clearer about the difference between what the data actually shows and what is just a possible interpretation. Also add risks around response rate and small groups. And please don’t sound like we’re diagnosing the team. We’re not therapists.

When the answer is finally good, you say:

Build a skill from this workflow. Call it employee-survey-analysis. It should be used when I’m analyzing engagement data, eNPS, pulse surveys, or free-text comments from employee surveys. Include the workflow, output format, HR risks, and quality control.

The tool can then create something like this:

---
name: employee-survey-analysis
description: Analyzes employee survey results, pulse checks, eNPS data and free-text comments. Use when the user asks for HR analysis of engagement data, employee survey results, leadership scores or team feedback.
---

# Employee survey analysis

## Goal
Turn employee survey data into clear patterns, careful interpretation and practical leadership questions.

## Instructions
1. Start by identifying the three most important patterns.
2. Separate data, interpretation and recommendation.
3. Compare groups only when the sample size appears reasonable.
4. Flag uncertainty when response rate, group size or context is missing.
5. Look specifically for patterns related to workload, leadership, clarity, trust and psychological safety.
6. Do not make medical, legal or individual-level conclusions.
7. End with practical questions for the manager or leadership team.

## Output format
Use these sections:

1. Short summary
2. Three most important patterns
3. What the data shows
4. Possible interpretations
5. Risks and uncertainty
6. Recommended next steps
7. Questions for the manager

## HR guardrails
- Do not identify individuals from free-text comments.
- Do not overinterpret small groups.
- Do not present correlation as causation.
- Do not recommend disciplinary or legal action without saying that human HR/legal review is needed.

That’s a useful first version.

But it’s not finished, first versions rarely are. (Or at least mine certainly aren’t.)

The next step is to test it on three different real cases.

1. A clear result with high response rate. The easy mode.

2. A messy result with lots of free text. The realistic mode.

3. A sensitive result with small groups. The “please don’t mess this up” mode.

After each test, ask:

What did the skill miss? What got too generic? What risks should it have caught? How should SKILL.md be adjusted?

That’s how you build a good HR skill. Not as a perfect prompt or description, but as a way of working that gets a little smarter every time it’s used.

Wrapping up

Skills aren’t a new piece of complicated AI jargon. They’re just a way of packaging recurring ways of working. They sound fancier than they are, which is roughly true of most things in tech.

For HR, this is especially useful because so many tasks require judgment, structure, and care. It’s not enough for the AI to “write well.” It needs to understand how the task should be done responsibly. Writing well without judgment is how you end up with an eloquent disaster.

A good HR skill does three things.

1. It makes the work more consistent.

2. It reduces the risk of missing important steps.

3. It helps the AI work more like an experienced HR person, and less like a very confident intern.

Start simple. Pick a recurring task. Do it once together with the AI. Correct until the result is good. Then ask Claude or ChatGPT to build a skill from the workflow. Test it on real cases. Adjust when it misses something.

It’s not harder than that.

Subscribe now

Happy Wednesday,

Let’s get straight into it.

I have lost count of how many times I’ve gotten the question: Is AI taking our jobs or not? Last time I got it was yesterday, speaking to a group of executives.

I always answer politely, but I’m also a bit tired of the debate about AI and jobs. Not of AI. Of how we talk about it. It has been stuck in the same loop for three years now, and both sides have started making things up.

One side says no jobs are being lost to AI. That it’s overblown, that Block was just correcting pandemic over-hiring, that the aggregates aren’t moving. Calm down.

The other side says all jobs are being lost to AI. That 300 million will disappear, that Gen Z is doomed, that anyone who doesn’t learn to prompt is out in eighteen months. Calm down.

Both have half the truth and pretend to have all of it. We need to stop picking sides and start holding two thoughts in our heads at the same time (which is surprisingly hard for people).

Jobs are being lost to AI.

Earlier this month, the CEO of Coinbase, Brian Armstrong, laid off 14 percent of Coinbase. He talked about rebuilding the company as an intelligence, with humans at the edges aiming it.

In his view, this is an entirely new view of what a company is. AI in the middle, people at the edges. Not engineers, designers and product managers running the work, but player-coaches and one-person teams aiming agents. If even half the tech CEOs are starting to think like this about their companies, it’s the biggest reshaping of knowledge work since the office was invented.

And Coinbase isn’t alone. Block laid off 4,000 people in March and Jack Dorsey said straight out it was AI. As the reason. Block had built an internal AI tool called Goose that had been running for over a year, and they reorganised around AI before the layoffs. Pinterest, CrowdStrike, Chegg, Snap, Shopify have all done the same.

But the layoffs aren’t the most important evidence; it’s what the technology can do.

MIT’s Crashing Waves vs. Rising Tides study from April, based on over 17,000 evaluations of AI models across more than 3,000 work tasks from the US Department of Labor, concluded that AI isn’t arriving as sudden waves over narrow areas but as a rising tide across nearly all text-based tasks at the same time. Models went from 50 percent success on hour-long tasks in 2024 to 65 percent in 2025, and the projection is 80-95 percent on most text-based tasks by 2029.

METR measures the same thing from another angle. The length of tasks an AI can complete autonomously has been doubling every seven months for six years.

And OpenAI’s own GDPval benchmark shows that frontier models are approaching industry experts with 14 years of experience in quality of delivery, measured across 44 occupations.

Anyone claiming nothing is happening hasn’t looked properly. To some extent, AI is taking jobs, whether we like it or not.

Jobs are not being lost to AI.

At the same time, one can argue that job losses are highly overstated.

Oracle is cutting 18 percent while the stock is down 25 percent on the year. IBM paused hiring with AI as the stated reason and then quietly rehired when it didn’t pan out. Sam Altman has warned that some companies AI-wash layoffs they would have made anyway.

And one interesting detail is that none of the major companies that announced AI-driven layoffs, not Block, Coinbase, Pinterest or Shopify, presented any concrete AI productivity metrics on their earnings calls before the cuts.

So they are telling the world that AI is doing so much work that they can let thousands of people go. But for their investors, there are no numbers. No reported increase in output per engineer. No measurable productivity gain to justify 4,000 or 700 redundancies. Just the story.

AI has become the most PR-friendly explanation available. Better than we over-hired during the pandemic. Politically safer than interest rates got us. And Wall Street rewards them for it.

So what?

I think both of these can be true at the same time.

It is possible that AI is driving real layoffs in specific roles and age groups, at the same time as many AI-attributed layoffs are financial decisions dressed up in transformation language. Both are true in the same quarterly report.

That’s why the debate runs into the ditch. One side points at Block and Coinbase. The other points at IBM and Oracle. Both are right. And both pretend the other side’s bucket of evidence doesn’t exist.

There’s also the burnout paradox.

Yesterday, Glassdoor released a report on burnout in the US labor market. Mentions of burnout in Glassdoor reviews are up 65 percent year-over-year in the first quarter of 2026, and 2.5 times higher than the pre-pandemic benchmark. The sharpest increase ever recorded came last year.

If AI is already taking over as much work as the big narrative claims, shouldn’t burnout be going down? Less to do, less stress, more breathing room in the schedule?

The opposite is happening. Burnout is rising faster than ever. And there are two readings of why.

1. Either AI isn’t taking over much work yet, and people are working as hard as ever or harder in a nervous economy, or in which case the panic narrative is overblown.

2. AI is taking over some work, but organizations are using the gain to demand more of people instead of easing the pressure. In which case the optimist narrative about AI as liberation is a fairy tale.

Neither reading is that great. And they don’t contradict each other; I believe both are somewhat true, but it isn’t the post-work utopia AI companies write about in their white papers. It isn’t the job apocalypse economists warn about either. It’s something else. A quieter, more exhausting version of both.

But in the long run I lean one way

Last month I sat with a marketing director who was about to break down. Her team had never been able to afford video. They were too few. Then they tried producing with AI and suddenly three people were making twenty videos a month. She thought at first she’d have to let someone go. Two months later she hired one more.

We talk about AI and jobs as if the pie is fixed. As if there’s a set amount of work in the world, and if AI does some of it, there’s less left for people.

That isn’t true historically. And I don’t think it’s true now.

When one person can suddenly do what used to take five, what we always talk about happens. Some roles disappear. Uncomfortable but true. But the other thing happens too. Ambition changes. When an organisation discovers that ten people can deliver what used to take fifty, they don’t stop at ten. They raise the bar. They launch more products. They say yes to customers they used to turn down.

And suddenly they need twenty again. Just that the twenty do ten times more.

This isn’t just historical anecdote, RAND published an analysis of US census data in October. The conclusion was that while some firms have decreased employment through AI replacing tasks, a larger share has reported increases in employment connected to AI adoption.

The gap between what the technology can do and what organisations actually do is where people remain.

And Welburn and Nygaard, the RAND economists, close with exactly what I’m trying to say. Jobs are more than individual tasks. They are a string of tasks assembled in a specific way. Crude calculations of labor market exposure to AI have failed to capture what jobs actually are.

If MIT authors Mertens and Thompson are right about the tide, then the pace of task automation could outpace the pace of ambition expansion. In that case, it isn’t the even redistribution I’m describing, but a systematic displacement where people lose ground faster than organizations scale up their ambition.

But don’t say it will sort itself out

And that’s one of the points to strongly consider for the organizations.
AI is undoubtedly disrupting work, maybe not in terms of destruction but in terms of change. Will we have enough time to reskill or upskill people to do those jobs?
It’s easy here to point to the Industrial Revolution. “We fixed this in the past; there will be more jobs in the long run. Look at the Industrial Revolution”.
Yes, that is true. But it took a while.

I spent all of last Christmas essentially reading up on this. E.P. Thompson, Robert Allen, Joel Mokyr, and Sven Beckert on cotton. Lectures on the Prussian army and German industrialization.

Why does an AI consultant read history books on the Prussian army? Because I didn’t trust the simple story, and I wanted to understand more. My whole work depends on leadership teams making better decisions about what’s happening right now, I needed to understand what happened the last time people said technology would take the jobs. Not what we say happened in hindsight. Those are two different things.

And it wasn’t all sunshine and roses.

It’s true that it evened out into prosperity, eventually. The country boys from the late 1700s first became factory workers in Manchester and Birmingham. Their grandchildren moved into offices in the early 1900s, but not on their own. The school system in its modern form was designed precisely to supply the factory, and later the office, with workers. Disciplined, literate, time-regulated bodies. It took roughly a hundred years to rebuild the education system to industry’s needs. Real wages only began rising in earnest after 1840, seventy years after the first factory opened its doors, according to Robert Allen’s research at Oxford. The middle class emerged, and society as we know it was rebuilt.

But it took 150 years.

And the journey there wasn’t all smooth sailing for people in general. Falling or stagnant real wages for decades. Luddite uprisings for which people were executed. Manchester and Liverpool were the shock cities of the revolution. Child labour in factories that didn’t exist before. Several generations born, living and dying during the transition itself, without ever seeing it pay out.

Thompson wrote an entire book about the handloom weavers crushed by the factory system. A hundred years after they were already gone, he wanted to rescue their memory from what he called the enormous condescension of posterity. What we do, in hindsight, to those who didn’t keep up, when we tell the story as if it was obvious they would lose.

We look back from the balcony of prosperity and tell the journey as if it was calm. It wasn’t. The winners wrote the history, the losers never got to hold the pen.

And once again, the Industrial Revolution took around 150 years to be “fully implemented,” if one might call it that. It’s been less than four years since ChatGPT was publicly released. If this transition runs over 15 years, or 5, do we have time to rebuild education, tax systems, social safety nets, identity, and meaning around work? The Industrial Revolution had the time. We don’t know whether we do.

Invoking the Industrial Revolution as comfort is asking to repeat it. The whole package, not just the prosperity bit. And perhaps without the time that allowed the losers’ grandchildren to eventually benefit.

As Oxford economist Carl Benedikt Frey has put it, most economists will acknowledge that technological progress can cause some adjustment problems in the short run. What is rarely noted is that the short run can be a lifetime.

So what do we do?

Both are true. AI takes jobs. AI creates jobs. And at the same time, very little has happened to the aggregate employment numbers in the three and a half years since ChatGPT launched publicly. Anthropic’s own research from this spring finds no systematic increase in unemployment among highly exposed workers since late 2022, but suggestive evidence that hiring of younger workers has slowed in exposed occupations.

Total collapse hasn’t happened. And at the same time, people are burning out faster than ever.

Companies have started the transition. I wrote in March that some of them are probably doing it by laying people off before AI can fully take over that job. Necessity is the mother of invention. You let people go, then the rest of the organisation is forced to solve it with AI. Economists have started calling it low hire, low fire. Companies freeze new hiring rather than running large-scale layoffs.

It’s never binary when people lose their jobs. Interest rates, markets, pandemics, the wrong product strategy, the wrong timing, AI. It all gets woven together. Ignoring AI as a factor is sticking your head in the sand. Saying it’s only AI is underestimating how labor markets actually work.

That’s why is AI taking the jobs or not is the wrong question. It will never get a clean answer. And the question is passive on top of that, as if we are standing on the sidelines watching the technology roll by.

The right question is what do we want AI to do with working life.

Because that’s a choice. Not an inevitable force of nature.

Do we want more people to work with higher output, so we as a society produce more? Do we want fewer people working, but over longer working lives? Do we want to work fewer days per week, or fewer hours per day? Do we want to use the productivity gains for lower prices, higher wages, or more people in meaningful work? Do we want them to go to shareholders, to workers, or to society?

These aren’t technical questions. They are political and organisational. And right now they are being answered by others, who don’t always have the broader interests in mind.

My point isn’t that I have the answers. My point is that we need to start asking the right type of questions. Holding two thoughts in our heads at the same time. AI takes jobs. AI creates jobs. Both are true. Anyone who can’t hold both will make bad decisions, no matter which side they stand on.

And maybe, if we do the work, our grandchildren will be spared from reading books about us with the next Thompson’s enormous condescension in their eyes.

Subscribe now

Happy Saturday,

I started writing a skills guide, but then I figured, let’s start with a full breakdown of Cowork / Codex instead. So here we go. A complete, free walkthrough of how to set up Cowork (or Codex, or Copilot Cowork). Because AI is moving from “chat with a model” to “build reusable workflows that do real work with you.”

For us in HR, that means policy drafts, job postings, onboarding, employee comms, reporting, and all the repetitive work that eats up your week.

I will also say that I’m running beta cohort 2 of Cowork for HR, starting on the 4th of June.

Three live sessions where we build real HR workflows together.

30% discount if you sign up before the 15th of May.

$553 instead of $790.

Join the interest list here.

That said, let’s get to it.

As most of you know, I’ve spent the past year helping CHROs and their teams get AI to work inside the HR function, not in pilots but in daily operations, in reports and performance cycles, in comp reviews and 1-on-1s. This guide is the consolidated version of what I keep saying in those conversations, written so you, as CHRO, can sit down on a Sunday afternoon and have a working setup by Monday morning.

(Ok, it works in the same way if you are an HRBP, HR Generalist, Recruiter or just a manager…)

The tool in focus is Claude Cowork, Anthropic’s desktop app, but the principles overlap with OpenAI’s Codex and with Copilot Cowork (the version Microsoft just rolled out to its Frontier program).

I say that but it’s also important to note that these three products share a family resemblance, but they are not interchangeable. Claude Cowork is a desktop knowledge-work agent. Codex used to be a coding agent primarily, but is now way more “cowork-like”, but still in my opinion not as user-friendly as Cowork. (It’s getting better day by day, though.)
Copilot Cowork is a Frontier preview that lives inside the Microsoft 365 stack with its own admin and security framing.

The principles in this guide overlap across all three, but the setup steps and the risk model differ. When you read “Cowork” below, mentally substitute the equivalent component in your tool of choice.

Let’s dive in.

What Cowork is

Cowork is a desktop agent rather than a chat or a website, meaning it’s a program you install on your own computer that has access to your files, can drive your browser, read your calendar, and run reusable workflows (called skills) on a schedule. It is not ChatGPT in a new outfit, and the difference becomes obvious once you start using it. Instead of operating in a separate tab where you copy and paste between systems, Cowork operates as you do on your computer, updating an Excel file in Dropbox without you re-uploading it, logging into Workday on your behalf, or following up on a candidate pipeline by reading email, cross-referencing Slack, and updating Teamtailor in one continuous flow.

For better and worse, more on the worse part in a minute.

Cowork is made of three parts

It’s worth understanding the architecture before you set anything up, because most CHROs only install the first piece and then wonder why the leverage feels modest.

1. The Cowork app. This is the desktop app itself, where you chat and run skills. On Mac it’s a three-minute install, while on Windows it can be tricky because it runs inside a virtual machine, so plan to involve IT if you’re on a corporate Windows laptop.

2. Claude for Chrome. This is the browser extension that most CHROs miss, and without it Cowork can’t act on the web on your behalf, which removes about half of the value. The extension runs in Chromium-based browsers, including Google Chrome, Comet, and Atlas; it does not run in Safari, Edge, or Firefox.

   This is the piece that lets Cowork open LinkedIn, scroll your inbox, fill out forms, or log into your HRIS as you. Many browser workflows can be delegated this way, but not all sites or actions work reliably, and Anthropic blocks certain high-risk categories outright. Treat the extension as a powerful generalist that still has limits, not as a universal “anything you can do on the web” button.

3. Skills and connectors. This is where the leverage lives. Skills are reusable workflows that you build once and call thousands of times, while connectors are how Cowork talks to your existing tools (Gmail, Calendar, Slack, your HRIS, your ATS). Without skills and connectors, Cowork is roughly a chat with a slightly better user interface; with them, it starts to feel like a colleague who already knows how your function works.

Skills before prompts

Most CHROs I talk to use AI by opening a chat, throwing in a question, copying the answer, closing the tab, and starting from zero the next day, which is not AI usage so much as an expensive Google search. The shift that creates leverage is moving from one-off prompts to reusable skills, where each skill is a saved instruction set that says when I ask about X, always do Y in format Z, always pull context from file A, and ask me about B if I forgot to mention it.

You build it once, and you call it in three seconds, which means the second run is already cheaper than the first, and by the twentieth run, you’re operating at a different speed than your peers.

How you build a skill is straightforward, and you don’t need to write any code.

Solve the problem manually in Cowork once until you’re satisfied with the output, then say “use skill creator to make a skill out of this” and let Cowork ask you a few clarifying questions about what it should ask next time, whether it should verify output, and where it should pull context from. Once those questions are answered, you have a skill, saved and ready to call.

The difference between writing a fresh prompt every time and calling a skill is roughly the difference between manual math and an Excel macro, and twenty runs into a performance cycle the difference compounds into hours saved every week.

Connectors and MCP

CHROs deploying Cowork end up talking to IT sooner or later, so it helps to have the vocabulary ready before that meeting starts. And the main reason for that is connectors.

A connector is how Cowork talks to an external system, and Cowork / Codex ships with a library of pre-built connectors for the obvious tools (Gmail, Calendar, Slack, Asana, Notion, Drive, OneDrive); you click the plus button, pick a connector, authenticate, and you’re done.

MCP stands for Model Context Protocol, a standard Anthropic created so that LLMs can talk to external systems without bespoke integration work, and when a vendor says “we have an MCP server for X”, what they mean is that Cowork (or ChatGPT, or Copilot Cowork) can connect to X with a few clicks rather than a six-month integration project.

The difference between an MCP and a traditional API is worth understanding before that conversation starts. An API is narrow and prescriptive, where each call asks a very specific question (give me field A for employee 12345). An MCP gives the agent a structured way to discover and use the tools and resources that the server chooses to expose, which makes it more flexible and more powerful in skilled hands. It does not automatically grant total access. The actual surface area depends on the server’s implementation, the scopes you authorize, the auth model, and where the server is hosted. That power is exactly why governance, ownership, and hosting decisions matter more for MCP than for a single API call, and why your IT team will have questions when you start mentioning it.

Many HR tools will have an MCP or get one in 2026, so the practical advice is to ask your vendors directly whether they have an MCP server on their roadmap.

If the tool you need doesn’t have one, you have two paths forward. The first is to use Claude for Chrome and let Cowork act in the browser as you, which works surprisingly well, while the second is to build your own MCP server from the vendor’s API documentation, which is more advanced but doable, and cheap to host on something like Railway or run locally on your machine.

Setup

Before you dive into doing stuff with Cowork, set the foundation properly, because the leverage you get from each workflow is roughly proportional to the amount of context Cowork has about your company and you. Don’t skip this part, it’s worth spending time on this!

The first thing to build is a memory file with company and role context, placed in your workspace and describing the basics of your organization, including company name, employee count, geographies and industry, the org structure at a high level, which HRIS, ATS, comp tools, learning systems, and engagement platforms you use, the timing of your performance cycles, your career levels and naming conventions, the language choices you’ve made internally (”we say colleagues, not employees”), and the labor jurisdiction(s) you operate under.

This single file is the difference between an assistant who sounds like a consulting deck and one who already works at your company.

I’ve created a free CLAUDE-md-template-for-CHROs.md - click the link and you’ll get it for free.
Drop that into Cowork and explain to Cowork that you want it to help you set it up and it will facilitate the whole process!

The second thing to set up is a baseline of three sources connected, starting with your calendar so the system understands meetings and rhythm, then a file storage system such as Drive, SharePoint, or Box where policies, frameworks, and templates live, and finally your meeting transcripts in Krisp, Fireflies, or Otter. With those three connected, Cowork can answer questions like “what did I promise the manager group in June?” without you searching anything manually.
If you don’t use a transcription service, then skip that step (doh).

The third thing is a brand voice skill, which sounds fancy but is straightforward in practice. You upload five finished internal texts, such as a performance template, a CEO communication, a policy doc, a job description, and a values guide, you have the model extract tone rules, and you save the result as a skill that gets called by every future text you produce. (Need a prompt for it? Steal it here.)

That’s it. Plan for one to three hours, and the leverage starts. But do it properly - the above steps, that’s what makes the tool magic!

Scheduling

Up to this point we’ve talked about skills you call manually, and the next step is letting Cowork run them on a schedule, which is where the experience starts to feel less like a tool and more like a colleague. You say “schedule this to run every Monday morning at 7:30 and deliver the result to me in Slack” and Cowork sets up the recurring job, including delivery channel and timing.

My personal setup right now runs through the week. Every morning a summary of new AI and leadership news from the past day lands in my inbox, every Tuesday morning a weekly report on the general labor market arrives, every Friday at 4pm a week recap shows up with what I’ve promised whom and what’s still open, and once a month my bookkeeping tool compiles a P&L for me, run locally with no cloud traffic, which keeps the financial data on my machine

.

There are two practical things to know about scheduling. The computer must be on, because Cowork runs locally, which means your laptop has to be powered on and online when the schedule fires; if you put a schedule at 6am but you’re not a morning person, your Monday job will silently miss its window, so put it at 9am instead. There is a Keep Awake mode for the rare cases when you need it, but it kills battery and should be used consciously rather than as a default.

The second practical thing is that skills save you tokens, because scheduled tasks without an underlying skill consume more tokens than necessary as the model has to think from scratch every time the schedule fires. Build the skill first, then schedule the call to it, and you’ll keep your monthly token budget intact.

Skills governance

When I work with larger organizations on Cowork, one challenge surfaces after a month or two. Everyone is building their own skills, nobody knows which ones exist, half the org is running a suboptimal version of the same skill, and nobody owns maintenance. This is a real problem that isn’t technical so much as a problem of ownership and process, and it gets worse the more useful the tool becomes.

My recommendation, based on how I’ve seen it work in practice is this;

1. Every meaningful skill should be versioned in a central skills repo in GitHub, with submitting an update done as a pull request rather than as a Slack message to whoever feels responsible that week.

2. You need one or two named gatekeepers who approve pull requests, check that the skill works, that it doesn’t conflict with existing ones, and that it follows your naming convention.

3. Every skill must have a named owner responsible for keeping it current, because skills rot when nobody owns them.

4. When a skill is updated, the system should ping Slack or Teams so the team knows to pull the new version; otherwise, people end up running stale variants without realizing it.

Is this overkill for a thirty-person HR function? Yes, and a shared Drive folder with a clear naming convention will do the job there. Is it overkill for a two-thousand-person organization where five managers have already built their own performance review skills with subtly different definitions of “Exceeds”? No, skipping the governance step there saves you nothing in the short run while costing you a six-month mess later.

Security

As said, CHROs deploying this end up in conversations with IT. But most likely you’ll also end up talking to legal and infosec, so it helps to walk in with the answers ready rather than having those conversations slow you down.

Cowork runs on your machine. Your files are stored locally, and any code or commands Claude executes run inside an isolated virtual machine separate from your main operating system. The nuance worth being precise about with IT is that file storage stays local, but the content of files Claude reads is sent to the model’s API for processing, same as any other Claude conversation. The local part is the storage, the execution sandbox, and the connection points to your apps. The inference happens in the cloud.

Cowork asks for explicit permission before deleting files, and computer use asks for permission per application before Claude can interact with it. The place people shoot themselves in the foot is by clicking “Always allow” too aggressively, or by switching on “Act without asking” mode. Anthropic’s own guidance is that this mode “significantly increases the risk of prompt injection attacks,” so it should only be used for well-defined tasks under active supervision.

If you’ve over-granted, permissions can be reviewed and reset in Claude Desktop’s settings (worth verifying the exact path in your version of the app before promising IT a specific click-path).

MCP servers are worth flagging to IT explicitly. A local MCP server runs on your computer with the same permissions as any other program you install. That’s efficient, but it means the trust model collapses to “do you trust the vendor of this MCP.” For sensitive systems like a bookkeeping tool, the recommended pattern is to host the MCP server locally rather than on a public host, so the data path stays inside your environment.

On prompt injection, which is the risk IT will absolutely ask about, Anthropic addresses it on three fronts. Content classifiers scan untrusted material entering Claude’s context, the Chrome extension strips hidden content before the agent sees it, and the model is trained via reinforcement learning to recognize and refuse malicious instructions even when they appear authoritative. The risk is non-zero, not zero, and you should still monitor for unexpected patterns.

When Cowork updates your systems (should you let it), you remain legally accountable for that update, same as if you’d delegated the task to an assistant. Anthropic’s documentation is explicit on this. The user is responsible for all actions taken by Claude on their behalf, including content published, messages sent, transactions, and actions by scheduled tasks.

In the EU? GDPR is where you need to be careful. Anthropic itself currently advises against using Cowork for regulated workloads, because Cowork activity is not captured in audit logs, the Compliance API, or data exports. The framing I use with CHROs is that this is a question that requires a case-by-case assessment together with your data protection officer, not a blanket yes or no, and you have to be honest with them about Anthropic’s own audit-log limitation up front. To put it more directly, do not use Cowork for personal data, employment-law decisions, or sensitive HR processes before your DPO and legal function have approved the specific use case. Approval for a recruiting summary is not approval for a termination workflow. Treat each new use case as its own conversation.

My summary is straightforward. Security around Cowork is a question that can be answered, not a question that can’t, and the difference between the two outcomes is whether your IT, legal, and DPO functions are involved early or whether they discover the rollout after the fact.

But all this said about security. Do not let this stop you from trying this out!
It’s 100% worth spending 20 bucks of your own money on your own computer just trying Cowork out.

As I alluded to in the beginning and in my post earlier this week, this is clearly where all model builders are heading right now.

Questions? Email me at johannes@sundlo.com. I’m not always fast but I respond.

Need help rolling this out in your organization? That’s the kind of work I do more or less every week, where we run workshops for not only CHROs but also lead teams and whole organizations. Not demos but real rollouts where adoption is the success metric. Email if you want to talk!

Otherwise, good luck!

This guide is free and meant to be shared, copied, adapted, and torn apart. If you build on it with your own skills, send them back!

Subscribe now

Happy Thursday,

I have spoken and run workshops a bit too much this spring. It has been an incredible season with great clients and great rooms, but it takes its toll, and I have decided that autumn is going to look different. Fewer clients. Less travel. A bit more sleep…

Which brings me to the reason I am writing this in the intro.

If you have been thinking about working together this autumn, now is the time to reach out. I say this in good faith, not as a sales pitch. Because people often message me at the last minute asking if I can do workshops or lectures, and lately, the answer has been no in most cases. (I already have 10+ bookings for 2027…)

Autumn is filling up fast at the moment, and I would rather have a conversation with you in May about the autumn than say no to you in September.

Reach out if you need help!

Now, on to Copilot Cowork!

I finally got access to Copilot Cowork!

And I have now used it enough to have an opinion based on something more useful than press screenshots and launch videos.

Have I tested every use case? No. Have I tested it fully across every HR workflow? Also no. But I have tested it enough to say this. We need to pay attention.

If we rewind a bit, this started with Anthropic’s Claude Cowork, which launched in January. I made a video about it then, focused on how we could use it in HR. And the response I got was predictable.

Security, security, security, security, security.

Fair enough. We should care about that. We work with sensitive data. We should ask hard questions before giving an AI agent access to documents, policies, employee data, emails, or anything else.

Enter Copilot Cowork.

The security objection just got a lot weaker

Microsoft has now moved Cowork into Copilot. Which means Microsoft security wrapped around it, as everything else in Copilot.

Cowork only sees what you already see. If you do not have access to a file or a folder, Cowork does not have access either. It uses your login.

Your data stays in your company, and it is not shared with other organizations. Whatever you type and whatever it produces lives inside your Microsoft 365 environment.

If your company has rules about sensitive documents, those rules still apply. The same labels and policies that stop you from emailing a salary file to the wrong person also stop Cowork from using it. Nothing changes there.

Everything Cowork does is logged and leaves the same audit trail as the rest of Copilot.

So the short version is that if your company is already comfortable with you using Copilot, it should also be comfortable with you using Cowork. It sits inside the same security boundary you already agreed to.

So what does Copilot Cowork do?

You describe what you need. It does the work.
(I know this is simplified, but to some extent, this is what it does.)

For example, it can draft emails and send them through Outlook.
My example below is, of course, silly, but when you chain this together with other actions, it gets quite powerful. “Create a report based on X and Y, every Friday, send it to my manager after I first approve it.”

It can organize your calendar and schedule meetings. It creates Word documents, Excel sheets, PowerPoint decks, and PDFs.

It can work with Teams in various ways (but then you need to be active in Teams…)

And a big thing for many is that you can now schedule things that you need to happen. So take the report example above again. Let’s say you create a report every week based on what your team did the previous week. You could let it gather info from your email, meeting transcripts, and documents and summarize that in a report every week, for example. Or create a simple business intelligence/news report that runs every day/week.

For people now panicking about some of the above, as you can see in the email example, Copilot Cowork does anything sensitive only after asking. Each action requires approval, and medium and high-risk actions get a risk indicator. You can pause, resume, or cancel at any point. You can hit “don’t ask again” for similar actions inside the same conversation.

But all in all, what we see happening now is that we stop describing what you would do, and we start delegating stuff to Cowork-like experience.

Codex? Cowork?

Compared to Claude Cowork from Anthropic, the Microsoft version is more limited (today). In Anthropic’s version of Cowork (as well as Codex) you can plug in pretty much anything. Mix it, blend it, throw context at it, connect external tools, push it into edge use cases. It is much more agnostic about what gets connected and what it gets asked to do.

Adding other systems is possible in Copilot Cowork, but it’s more complex, which presumably has to do with the security aspect.

Microsoft’s version, however, is strongly built around the Microsoft 365 stack (unsurprisingly so). Outlook, Teams, OneDrive, SharePoint, and Work IQ is all connected from start.

So if you have a lot of your work and documentation living in the Microsoft environment, then it is still very capable.

Skills are the part you need to pay attention to

Cowork uses skills. There are 13 built-in ones. Word, Excel, PowerPoint, PDF, Email, Scheduling, Calendar Management, Meetings, Daily Briefing, Enterprise Search, Communications, Deep Research, and Adaptive Cards. The skill loads when needed and appears in the side panel.

You can also write or import your own. Up to 50 custom skills, stored in OneDrive at Documents/Cowork/Skills/, each one a folder with a SKILL.md file inside it. Cowork discovers them automatically when a conversation starts.

So what is a skill? In short it’s a written-down process. A recurring way of doing something, captured in plain language so the agent knows how to handle it next time it comes up. Onboarding follow-up. Manager check-in templates. Exit interview synthesis. Weekly people analytics digest. Anything you have a process for is a skill candidate.

This deserves its own article, but the short version is that the organizations that are going to win with agents/skills are the ones that can describe their processes well enough to teach a system to follow them.

What this means for HR

The world is moving in the cowork-direction. I want to be very clear about that. More capable systems, skills and more things running on somekind of autopilot.

My overall advice should be curious but yet to receive Cowork in your org, then what you can do prepar for the day when you get it is to document your pocesses, workflows and the goal you have with the different proceduers and ways of working that you have. So in short this is about being good at defining processes. The teams that can write down what they actually do, in clear steps, are the teams whose work scales with agents/skills. The teams that cannot will keep relying on tribal knowledge, and tribal knowledge does not delegate.

The security objection is now substantially weaker for Microsoft customers. The capability objection is getting weaker every month. What is left is the organizational question. Who owns this? Who trains people? Who writes the skills? Who decides what is delegated and what is not?

That is HR work. That has always been HR work. The tools just got better.

More on skills shortly!

Subscribe now

Happy Wednesday,

Two weeks ago I wrote The Bottleneck Was Never the Technology. The argument was simple. The models are already more capable than what your organization is extracting from them. The constraint isn’t GPT or Claude or Copilot. It’s whether your CEO is willing to make real decisions and follow through.

I expected the article to land hard with some people. It did. What I didn’t expect was how many leaders messaged me afterwards saying some version of the same thing.

“Okay. I get it. I’m the bottleneck. Now what?”

Fair question. So this week I want to answer it.

And my answers and patterns come from mainly workshops, keynotes, leadership sessions across the UK, Sweden, Norway, US, with industrial companies, public sector, media houses, financial services, and retail. It’s hundreds of conversations, and the same pattern keeps showing up.

The organizations that move and the ones that don’t aren’t separated by budget, headcount, or even AI literacy. They’re separated by three things their leaders do.

1. They make a real call instead of “piloting” forever

The most expensive word in AI adoption right now is “pilot.”

A pilot used to mean something. You ran a small experiment, learned, decided.

Today “pilot” mostly means “I don’t want to commit, but I want to look like I’m doing something.” Twelve months later you have a working prototype, a tired team, and zero scaled outcomes. Then someone new joins the leadership team, and you start over.

The leaders who move skip that game. They commit to a direction. They tell the organization the direction is real. They put budget behind it. They make it clear that opting out isn’t an option for the function they’re responsible for. That doesn’t mean they have all the answers. It means they’ve decided that finding the answers is part of the job now, not a side project.

If you can’t make that call as a CEO or CHRO, ask yourself why. The honest answer is usually that you’re not sure enough yet. Which means the work is to get sure, not to keep piloting.

2. They build instead of buy

This has been the most striking pattern across the last three months.

People walk into workshops with problems they have been waiting on IT to solve for eighteen months. Eighteen months. By the end of a session some of them have a working tool that solves the problem. Not a perfect tool, but a working one. Enough to use Monday morning.

The leaders who move have figured out something specific. The shape of work has changed. You don’t need a vendor for everything anymore. A lot of what HR has been waiting in line for, you can now build yourself in an afternoon. Not all of it, but more than you think.

The leaders who don’t move are still routing every idea through a procurement process designed for buying ERP systems. By the time the RFP closes, the technology has moved twice. The capability they wanted has shipped natively in a tool they already pay for. And the team that needed it has given up.

If your organization can’t tell the difference between “we should buy something” and “we should build something this week,” that’s a leadership problem, not an IT problem.

3. They treat advisor selection as a real decision

I said this briefly in the last article. I want to say it louder now.

The amount of bad advice flowing through boardrooms and leadership teams right now is staggering. Some of it comes from internal people who are protecting their relevance. Some comes from external consultants who read three Substacks and call themselves AI strategists. Some comes from vendors with a clear interest in selling you the wrong thing.

The leaders who move have figured out who uses this stuff every day, who has built things that worked and things that didn’t, and who can tell them the truth. They don’t outsource the thinking. They use advisors to sharpen their own thinking.

The leaders who don’t move accept the first plausible-sounding plan that crosses their desk. Then they’re surprised when it produces nothing.

This isn’t about hiring me or anyone else. It’s about being deliberate. The wrong advisor in 2026 will cost you a year. The right one will compress two years into six months. That decision is worth your attention.

So what to do?

If you’re reading this and recognizing yourself in the “haven’t moved” group, here’s what I’d do.

Spend twenty bucks on Claude or ChatGPT for a month. Spend ten hours with it. Not delegating. Not asking your assistant to try it. You. Build something small that solves a real problem you have. Form your own opinion based on experience.

Then look at your leadership team and ask which of the three things above you’re doing. Not what you’ve said in town halls. What’s happening?

If the answer is none of them, you don’t have an AI strategy problem. You have a leadership problem. And the good news about leadership problems is that you can fix them, today. (Without anyone’s permission! This is the HR domain.)

The window for “we’ll figure it out later” closed sometime last quarter. Acting like it’s still open is the most expensive decision most leaders are making right now.

I’d rather you act and get it wrong than wait and get it right too late.
We can fix wrong. We can’t fix late.

Subscribe now

This week’s FullStack HR is brought to you by…HR Tech Europe.

We need to talk to each other. For real. The pace is faster than ever, none of us can crack this alone, and we need rooms full of smart people who challenge how we think.

Amsterdam, April 22-23. Google, LEGO, Coca-Cola, Microsoft, Maersk, Oatly, and a hundred other companies!

If you’re in HR, it’s free.

Register here

Happy Tuesday,

Quick update before we get to this week’s article.

Despite my brilliant move of putting the wrong link in last week’s description, the interest for the Cowork Bootcamp for HR has been completely insane. So I’ve decided to run it in two rounds. Simple as that. If you missed the first round (signups closed April 11), you can still join the second. I’m offering 30% off as a beta 2 discount. I’m fully convinced you’ll be happy you signed up.

Sign up here

(Yes, the link is the correct one)

Next week I’m at HR Tech in Amsterdam. And I want you to come build things with me!

Bring your laptop. We’re not doing slides and theory. We’re building real HR tools, live, together. This is the most practical session I’ve ever done at a conference.

Two sessions,

April 22 (12:30–13:30, Ask the Experts & Think Tank) Ask the Experts: Using AI to Build Practical HR Outputs

April 23 (15:00–15:45, AI Labs) AI Lab: From Prompts to Products: Building Real HR Tools with AI

If you’ve been reading this newsletter and thinking “I should really try this stuff,” this is your moment. Show up. Bring your laptop. We build!

Now. To this week’s article.

I’ve lost count of how many workshops and keynotes I’ve done this year. I don’t even want to count. But every session is a data point, and every discussion sharpens the picture. Things I believed six months ago, I don’t believe anymore. The tech moved forward, and I got better at seeing what actually works in organizations and what doesn’t.

The thing that is clearest of all? Leadership. Again.

If your CEO isn’t crystal clear on why AI matters, what you’re actually going to do, and how you’re going to do it, almost nothing will happen. You get this half-hearted energy where the organization acts as AI might possibly become important someday. And if leadership isn’t prepared to make real changes to how work gets done, nothing moves. I’m more convinced of this every week.

The capability isn’t the constraint anymore.

The models we have right now, whether it’s GPT 4.5 Pro, Opus 4.6, or the agentic capabilities in Claude Cowork, don’t matter. They are already more capable than what most organizations are extracting. Most companies aren’t using a fraction of what’s available.

Do they still hallucinate? Yes. Do they make mistakes? Absolutely. But if we applied the same forgiveness factor to AI agents that we apply to human employees, the gap would be indistinguishable.

The constraints are the organization and the people within it. The CEO who says “AI is important” but doesn’t mean it. Who hears “we bought Copilot” and accepts that as a strategy. But for the 1023rd time in this newsletter, this isn’t a technology purchase. This requires working through your entire organization, rethinking how work gets done, making real technology choices, and getting every level to understand what’s actually possible versus what’s just old mythology that won’t die.

The excuse factory is running at full capacity.

I meet so many organizations where old beliefs still live. “This won’t work.” “It’s not safe.” “The models can’t do that.” Sometimes it’s fear, sometimes ignorance, sometimes professional pride, sometimes politics. People who won’t make decisions and hide behind GDPR concerns or security worries that sound legitimate but are really just shields for inaction. And sometimes, honestly, people just aren’t capable enough to evaluate what they’re looking at. I know that sounds harsh, but it’s true.

So the CEO isn’t confident enough to push through it. They listen to the IT director protecting their territory. They listen to the HR director who doesn’t feel confident in the technology. And nothing moves. “Let’s just go with Copilot. It feels safe.” You shouldn’t make reckless decisions. But the cost of not making decisions gets higher every single day.

Courage. Year three.

I’ve been banging this drum for three years. You have to dare. There are ways to make it safe, but that requires investment. So either you invest in making it secure, or you accept that it’s maybe 90% there and move forward anyway. Do your GDPR assessments. Be compliant. But know what is what and get good advisors.

On that note. I always want to focus on the positive, on what you can do. But there is so much bad advice floating around this AI era, from both internal and external sources. I’m not exempt; I have blind spots, too. But the gap between good and bad guidance right now is enormous, and the wrong advice at the wrong time can cost you a year or more. Get people around you who actually know what they’re talking about.

The real risk.

It doesn’t matter if you’re an industrial company, a consulting firm, or a tech company. Someone, somewhere, is sitting with Claude Cowork right now, automating their support processes, operating at lower margins than you. And they will come for your market share. Not overnight but steadily.

So either you believe you’re fast enough to pick this up when it matters, or you start now, or you accept you’ll invest like crazy later to catch up. But believing you won’t need to do this work at all? That’s Nokia. That’s Ballmer-era Microsoft. That’s standing outside the internet and saying “we don’t believe in mobile phones.”

I’ve been conservative about this. I’ve tried to balance hype with reality. But enough is enough.

$20. That’s it.

Claude Cowork costs $20 a month, and you spend maybe 1-2 hours with it. That’s all it takes to see what this technology is capable of. The potential to fundamentally change how work gets done is real, and there’s a real risk that this leads to jobs disappearing. Which is exactly why, if you’re a leader or in HR, it feels wrong not to test this. If you can’t do it at work, do it privately.

I’m not saying this so you’ll buy my course. YouTube is overflowing with free examples. The point isn’t the course. The point is that you start. And the worst that can happen? You come back and tell me I’m a hype boy. Fine. At least you tested it, at least you formed an opinion.

I’ve given a lot of presentations this year. I haven’t met a single person who, after actually trying Claude Cowork, said “that looks useless.” Not one.

And, yes, this is coming to Copilot too. Eventually. So start now, and it’s downhill. Wait a year, and it’s uphill.

We need to lead this. Not stumble into the future because we were too scared to decide. We need to steer our organizations using

Maybe this was too much of a rant, I don’t know, but I’m getting a bit tired of just sitting around waiting.

Subscribe now

This week’s FullStack HR is brought to you by….HR Tech Europe!

More than ever, we need to talk to each other.

Not “align on strategy” talk. Talk for real.
The topic right now in HR? It’s one we all need to learn. Fast. And the need has never been this big, the pace has never been faster.

I’m a 100% certain that we can’t figure this out alone. We need rooms, conversations, and smart people who challenge how we think.

That’s happening in Amsterdam, April 22-23 at HR Tech Europe.

People from Google, LEGO, Coca-Cola, Microsoft, ING, Maersk, Oatly, and a hundred other companies will be there.
is doing three sessions this year, including his first ever "Ask the Experts" and a unique session with Gianpaolo from Cisco. And a brand new format called HR Tech Intensives, where you actually work through problems together instead of just listening.

And of course, I’ll be there, and I’ll be hosting a practical session, so bring your laptops, and we’ll build stuff together.

If you’re in HR, it’s free.

Come talk.

Register here

Happy Thursday,

I messed up on Monday and put the wrong link to the Claude Cowork Bootcamp…yey me. This is the right link….sorry!

But enough of all of this, let’s get to it!

Every time I give a talk about AI, someone asks it.

Sometimes early, sometimes at the end, sometimes with a hint of accusation, and sometimes out of genuine curiosity. But sooner or later, the question pops up: “What about the environmental impact?”

I’ll be honest, sometimes I brushed it off with a half-answer.

Not because the question is bad, but because I never quite understood why AI specifically became the big symbolic issue for digital environmental impact. We’ve been streaming Netflix for twenty years, Zoomed our way through a pandemic, and googled everything from symptoms to holiday destinations without anyone raising their hand to ask what it’s doing to the planet.

But the moment someone opens ChatGPT, the entire climate discussion seems to land in their lap.

This question has been nagging at me for a while, though, and I’ve spent quite a few hours with ElevenReader in my ears going through the IEA’s energy reports, Stanford HAI’s AI Index, OECD publications, and peer-reviewed papers trying to form a proper opinion. I also used Claude to help me synthesise and structure all of it into this article, because the irony of using AI to write about AI’s environmental footprint felt too appropriate to pass up. The sources and data are real, the position is mine, and the help was computational.

What I found was considerably more nuanced than the public debate usually suggests.

The individual footprint is vanishingly small

A typical text query to ChatGPT uses roughly 0.3 watt-hours according to Epoch AI’s analysis from February 2025. OpenAI’s Sam Altman has confirmed a similar figure of 0.34 Wh. Google published in its own methodology report in 2025 that a median text prompt in Gemini uses roughly 0.24 Wh, produces 0.03 grams of CO₂, and consumes 0.26 milliliters of water.

That puts it in the same ballpark as Google’s own estimate for a standard search, roughly 0.3 Wh, though that figure comes from a 2009 blog post and is likely lower today given sixteen years of hardware improvements.

The comparison isn’t perfect, but the order of magnitude is clear. A typical AI text query is not the energy monster that early estimates suggested.

The figure that often gets thrown around, that an AI query uses “ten times more electricity than a search,” comes from Alex de Vries’ article in Joule in October 2023 and was referenced by the IMF, among others. It was likely accurate at the time, but is now outdated for typical text queries, since both hardware and model architectures have become dramatically more efficient.

Digital energy comparisons are harder than they look

It’s tempting to line up AI alongside streaming, video calls, and email to show that it’s a relatively small activity. And I’ve done this several times myself, and my early drafts of this article had a neat little table with watt-hours per activity. But the more I dug into the sources, the more I realized that these comparisons are difficult to make.

The IEA’s own analysis from 2020 found that one hour of Netflix streaming consumed roughly 77 Wh, which was already about 90 times lower than the widely cited Shift Project estimate that had made headlines.

The result is highly sensitive to what you count, such as that device type matters enormously (a TV uses roughly 100 times more electricity than a phone), and whether you include only the data center or the full chain from server to screen changes the answer dramatically. Carbon Brief’s deep dive confirmed the IEA’s lower range and showed just how wildly the numbers vary depending on assumptions.

For video calls and email, the source picture is even weaker. A Purdue/MIT/Yale study from 2021 gave a range of 150 to 1,000 grams of CO₂ per hour of video conferencing, which is so broad it essentially tells you that nobody knows. For email, I found estimates ranging from 0.01 Wh to 13 Wh per message, a spread of more than a thousand times.

Most digital energy comparisons you see in the press blend methodologies, mix old and new estimates, and conflate different system boundaries, making them look far more precise than they are. What we can say is that a typical AI text query, at roughly 0.24 to 0.34 Wh, is a very small unit of energy by any reasonable standard, and it’s comparable to a lot of other digital activities that we do.

But the scale is a different story

What makes the question impossible to dismiss is not the individual prompt but the total infrastructure. According to the IEA’s “Energy and AI” report from April 2025, the world’s data centres consumed roughly 415 terawatt-hours of electricity in 2024, about 1.5 percent of global electricity use. In the IEA’s base scenario, that more than doubles to around 945 TWh by 2030, equivalent to Japan’s entire electricity consumption today.

Five companies plan to spend close to 700 billion dollars on AI infrastructure in 2026 alone. ChatGPT reached 900 million weekly active users by February 2026. AI is being built into search engines, email clients, office software, and autonomous agents in a way that makes it an entirely new computational layer underneath the digital economy, and that layer requires physical infrastructure on a massive scale.

The efficiency gains are real and impressive. Stanford HAI documents a 280-fold cost reduction for GPT-3.5-level inference in just two years. But it is precisely this efficiency that drives even faster growth in usage, exactly as Jevons paradox predicts.

When GPT-4o’s API pricing dropped from 30 dollars to 2.50 dollars per million input tokens, usage exploded. Google’s Gemini token usage grew 130 times in 18 months. The IEA’s scenarios show that even with significant efficiency gains, absolute electricity consumption continues to rise in nearly all plausible futures.

Water?

Energy gets almost all the attention, but the water question is in many ways more acute.

Before getting into the alarming cases, it’s worth putting AI’s water use in proportion. While I was writing this article, my friend Mathias Sundin published an excellent piece on Warp News covering much of the same ground, building on work by Andy Masley who has done some of the most detailed analysis on this topic.

According to Masley’s calculations, all of America’s golf courses use roughly 5,474 times more water than ChatGPT. (Yes, you read that right 5474 times more than the ENTIRE ChatGPT.)

In Maricopa County, Arizona, golf courses account for 3.8 percent of the county’s water while data centres account for 0.12 percent. There are individual golf courses that consume more water than all of ChatGPT globally. And the widely shared claim that a single AI prompt uses “a bottle of water” is a distortion of a study that found 500 millilitres per 20 to 50 prompts, roughly 0.3 millilitres per query.

That said, proportion isn’t the whole story. As Undark reported, the issue is not that AI currently uses more water than golf or agriculture. The issue is the pace and concentration of growth, and who bears the local cost. The World Resources Institute reports that two-thirds of data centres built since 2022 are in water-stressed areas.

Both things are true simultaneously. AI’s total water consumption is small compared to many other industries. And in specific communities where data centers are being built at speed, the local impact is already causing real conflict.

So where does this leave us? Or me?

I still don’t really understand why AI specifically became the big symbolic question for digital environmental impact. We’ve accepted that digitalization costs energy for decades, and the individual AI query is energetically comparable to things we do hundreds of times a day without a second thought.

I’m also not exactly a model citizen when it comes to the environment. I fly too much, and I know it. So I’m not going to stand here moralizing about other people’s Claude habits.

But I think the question deserves a serious answer rather than a shrug.

Data centres currently account for roughly 0.5 percent of global CO₂ emissions, compared to aviation at roughly 2.5 percent and the textile industry at 2 to 8 percent. AI is not the world’s biggest environmental problem. But data centre electricity is growing at roughly 15 percent per year, it is one of very few sectors where emissions are projected to keep rising.

The serious answer, the one that best reflects what the IEA, the OECD, Stanford HAI, and UNEP say, is that AI’s environmental footprint is real and growing fast, but it is not a climate catastrophe in itself.

It is a serious governance problem that requires us to demand better infrastructure, not to stop using the technology.

The IEA also estimates that AI applications could enable emission reductions equivalent to 5 percent of global energy-related emissions by 2035. But that doesn’t happen by itself, and it doesn’t happen if we build AI infrastructure on dirty power in water-stressed regions without asking questions.

I think that the question shouldn’t be “should I use AI if I care about the environment?” The question should be why we don’t ask the same thing about everything else we do on a computer, and why we’re not demanding more from the companies building the infrastructure.

I’m going to keep using AI. I’m going to keep talking about it as the most transformative technology most organizations have to deal with right now. But I’m going to stop brushing off the environment question with a shrug. It deserves better than that.

I save hours every week using Claude Cowork.

It’s done through automated background processes. It drafts my emails, analyzes my data, and helps me build my presentations, while I do other things.

And I built a bootcamp that teaches people like you, HR professionals, how to set up the same thing.

I’ve sold exactly one course in 7+ years of writing this newsletter. Sure, I’ve been sneaking in the occasional links to what I do and hoping you’d click them. But this is new territory. I’m deliberately, in broad daylight, selling you something through a dedicated post.

Why? Because I feel so strongly that people should learn this.

So what’s the fuzz about?

Cowork Bootcamp for HR.
3 weeks. 3 live sessions.

Automated job postings, survey analysis, onboarding flows, and email responses. If you can articulate it, Cowork can (probably) automate it.
All are built as reusable skills that continue to work after the bootcamp ends.

Not “prompting tips.” Not theory. Systems and automations.

The gap between “I’ve tried ChatGPT” and “AI saves me 5 hours a week” is not talent or tech skills. It’s someone showing you exactly how to set it up for YOUR work. That’s what I’m hoping this will be.

The details

When: April 17 - April 21 - May 6
Format: 3 live sessions, 60 min each
Time: 3:00 PM Stockholm / 2:00 PM London / 9:00 AM New York
Price: $490 (beta price, will be at least $990 from cohort 2)
Requires: Claude Pro ($20/mo)

This is in English, built for a global HR audience.

Not convinced after Session 1? Email me. Full refund. No questions.

Who This Is For

You work in HR. You know AI can save time but haven’t cracked the code on making it actually useful. You want to build, not just learn.

And if your organization runs Microsoft 365, two weeks ago, Microsoft launched Copilot Cowork, built on the exact same Claude technology you’ll learn in this bootcamp. The skills and workflows you build here will translate directly when your organization rolls it out. This is your chance to be the person who already knows how it works before IT even sends the rollout email.

Who This Is NOT For

If you want a certificate for LinkedIn, a passive webinar, or slides about “the future of AI in HR,” this isn’t it. You will build things. That’s the point.

Curious?

→ Apply here ←

Very limited seating since this is the beta cohort. I review every application personally and accept on a rolling basis. Apply early, as I fill it out as we go. The cohort may fill before the April 11 deadline.

This is the intersection of 15 years in HR and 3+ years going all-in on AI. It’s the thing I wish existed when I started. If that resonates, apply.

/Johannes

P.S. Company paying? I do invoicing.
Need a business case for your manager? Reply to this email. I’ve written about 100 of those.

P.P.S. Once again, session 1 guarantee. Full refund. That’s how sure I am.

Subscribe now

This article is part of a paid collaboration with Sana.ai, which made my attendance possible. Thank you, Sana!

Unleash holds a special place for me. My very first professional HR conference, almost exactly 15 years ago, was the event that would eventually become what we now know as Unleash. Back then it had a different name. Back then it was in Amsterdam. And back then, the world of HR looked nothing like it does today.

This year, I went back to Las Vegas. And I came home with a lot to think about.

Why I went

The primary reason I chose to travel halfway across the world was one name: .

If you have been reading this newsletter for any amount of time, you know that Mollick has been a massive inspiration for me and for many others in this space. The reason is simple. He is one of a very, very small number of people who talk about AI from an organizational perspective, and what he does so well, and what I have genuinely tried to emulate in my own work, is that he embraces the fact that very few of us actually know what is going on. He said it himself on stage: “If you’re doing imposter syndrome right now, you’re in the exact right place. We are all imposters.” Things are moving too fast to follow everything. What you can do is try, experiment, and apply it in your own context. And that is exactly what he does, brilliantly.

Amy Edmondson was the other name on my list flying over the pond. Her opening keynote on Day Two delivered what you would expect from someone who has spent decades studying psychological safety. And I enjoyed her framework around “intelligent failure,” that organizations should deliberately create conditions where the right kind of failure can happen, felt like it was written for this exact moment. Every organization trying to figure out AI right now needs to hear that.

The AI Summit

The conference started with the AI Summit, organized by UKG and led by and .

The AI Summit was almost unfairly good. It was practical, concrete, and forward-looking in a way that set the tone for the entire rest of the conference. Did it contain a lot that was completely new for someone like me, who spends essentially all waking hours trying to understand this space? Maybe not. But even for someone deep in the weeds, there is always something new to pick up when you are in the room with other people thinking hard about the same problems. That is the real value of these events. Always has been.

The key message from both Jason and Jess was this: read the signals. Pay attention to where things are actually heading, not where you wish they were heading.

Peter Hinssen stole the show? Yes.

Then came Day Two. And the highlight, by far, was Peter Hinssen.

I have seen Hinssen speak three times now. There is a lot happening when he talks, and there is a lot of dopamine when you listen to him. But this time, he was something else entirely. I would put his keynote in my top three talks I have ever seen on a stage. (That is not something I say lightly!)

Why was it so good? Because he puts things in perspective. He weaves together the technical realities of what is coming with the organizational implications of what it means. He makes the complex feel simple to follow. His concept of the “Never Normal,” that we should stop waiting for things to calm down because they never will, landed with particular force this year. He framed the current moment through four lenses: hardcore geopolitics, extreme capitalism, zero latency, and talent singularity. His conclusion was clear. AI-first does not mean people-last, but the waves of disruption are only going to get higher.

Budget planning is a yearly, sadistic corporate ritual where people put fake news in Excel that is consolidated into something which actually never works. - Peter Hinssen

For me, Hinssen and Mollick together represent the gold standard. They combine technical depth with organizational realism, and they are honest about what they do not know. One line from Hinssen has stayed with me since I left the room: “Digital was just the appetizer. AI is the main course.”

But Mollick?

Ok, so Hinssen was a highlight. But what about Mollick then? He did not disappoint.
And he did not just talk about where AI is heading. He gave the room a practical framework for what to do about it, and his model has three components. Leadership, Lab, and Crowd.

The Crowd is everyone in your organization who is already using AI. And they are using it, whether you know it or not. Mollick was blunt about this (rightfully so!) Almost half of employees are already using AI at work. Many report tripling their output on certain tasks. But none of that productivity is showing up on your dashboards. Why? Because your AI policies have made it scary to admit. Because people know what “efficiency gains” means in corporate language. Because there is no incentive to tell you. As Mollick put it: “The expertise of how to use AI is in your teams already.” The question is whether you are creating the conditions for that expertise to surface.

The Lab is not an IT function. It is a small, dedicated team that works on AI full-time. Their job is three things. First, take what the crowd discovers and ship it to the rest of the organization. Someone builds a prompt that saves six hours a week? That goes out to everyone, that week. Second, build benchmarks. How good is AI in your specific context? You will not know unless you test it yourself. No outside evaluation will tell you. Third, build the impossible things. Experiments that might not work. Provocations. The stuff that prepares you for what is coming next.

Leadership is the third piece, and Mollick was clear that he has not seen a single company succeed with AI without all three in place.

AI is a weird alien mind, one that isn't sentient but can fake it remarkably well. It is trained on the vast archives of human knowledge, and also on the backs of low-paid workers. - Ethan Mollick

One more thing he said that landed hard: “Your R&D team is HR.” Not IT. Not a vendor. Not a consultant. The people who will figure out how to use AI in your organization are the people who already work there. This is not something you can outsource. And the models are universally available. There is no secret AI. Everyone has the same tools. The difference is what you do with them.

And yes, we got to meet him, and yes, I was starstruck.

All good?

There is a palpable uncertainty in the HR community right now. You could feel it in the hallways. Everyone is looking at everyone else. What are you doing? What are you doing? What are you doing? There is a restlessness, almost an anxiety. Where is this going to land?

I want to be careful about how I say this. I know it might sound presumptuous. But I see what is happening with AI, and sometimes I feel like I am losing my mind because the gap between what is already possible and what most organizations are actually doing is enormous. So it was… reassuring to hear people like Hinssen, Mollick, Averbook, and Von Bank confirming the same thing. This is not a phase, there are no signals suggesting that AI disruption is going to slow down or go away.

That confirmation matters more than I expected it to and it connects directly to something I experienced that same week.

Snap back to reality.

The same week I was at Unleash, I was also working with an American client. I cannot name the organization, but I can tell you what happened. We used Claude Cowork extensively, live, inside a real HR operations environment. The work involved processes that most HR professionals would recognize immediately. Document handling, policy reviews and data consolidation across systems. The kind of recurring, high-volume knowledge work that fills up calendars and drains energy (and motivation).

In roughly 30-45 minutes of focused work with Cowork, I estimate we identified efficiency gains of hundreds of hours per month. Not theoretical gains. Real, measurable, immediate time savings on actual work that actual people were doing.
Cowork is a magical tool. It truly is.

And that’s yet another signal. And by the wya, here the signals all point in the same direction. Microsoft is working on their own version of this kind of tool. There are credible reports that OpenAI is building something similar. Anthropic already has Cowork in production. This is coming. Broadly. In ways that are compliant and secure.

And when it does arrive at scale, knowledge work as we know it will change. Not might change. Will change. The person who is not prepared for this will struggle. I am more and more convinced of that with every passing day. The signal is becoming clearer, and clearer.

Ok, so now what?

Does the work still require humans? Absolutely. Humans are critical. Validation matters. Judgment matters. Context matters. But the tasks themselves, the actual work of producing, analyzing, summarizing, drafting, processing? Machines can already do most of it. Right now, today. If you let them.

The limitation is not technology. Both Hinssen and Mollick made this point forcefully. The limitation is us. It is organizational inertia. It is perception. It is the comfort of waiting for the dust to settle. Or as Hinssen put it: “Yesterday’s work is the silent killer of organizations.” We have to become yesterday’s work hunters in the age of AI.

The dust is not going to settle.

That, more than anything, is what I took home from Las Vegas.

Subscribe now

I’ve spent three editions on bosses.
→ What an AI boss could look like.
→ What’s left when AI handles the managing.
→ Why we expect bosses to care in the first place.

I built the case. AI can individualize at scale, better than most humans can. It doesn’t get tired, it doesn’t have moods, and it remembers your goals. For many people, it could be the best boss they’ve ever had.
And yes, I still believe that, or parts of it at least.

But I’ve been arguing from the manager’s and the organization’s side.
What about the person on the receiving end?

How does it feel, or would it feel, to be managed, coached, followed up on, and given feedback by a machine?

We already know something

This isn’t entirely hypothetical. Millions of people already work under algorithmic management, like Uber drivers, Amazon warehouse workers, and food delivery couriers. Their schedules, performance ratings, and in some cases, terminations are shaped by software.

Not all of that is “AI” in the ChatGPT sense, but it’s still machines making managerial calls, and I do believe that some of the lessons transfer.

And the research is pretty clear. How it’s designed (and governed) matters more than what it is.

A 2024 study of food delivery couriers in Finland (based on 30 interviews), “Algorithmic management, wellbeing and platform work”, found that the work had what the researchers described as “iso-strain” characteristics: high demands, low control, and low support, plus isolation. Workers described stress, frustration, and mistrust, especially when decisions felt opaque or unfair.

And one detail matters here, and that was that when couriers reached out for help, they often met automated, algorithm-driven responses that didn’t address their concerns. That’s where a lot of the damage happened.

To be fair, the study also notes nuance here; support on issues directly related to deliveries could be fast and adequate. But broader support and real dialogue were limited.

The algorithm wasn’t the problem. The design was.
(And one could argue that this was not the latest and greatest models from the frontier labs, thus the study was set in the wrong premise.)

The loneliness chain

A 2023 paper in the Journal of Applied Psychology, “No Person Is an Island”. The researchers ran four separate studies with a total of 794 participants across Taiwan, Indonesia, Malaysia, and the United States.

The finding was that the more employees interacted with AI systems for work, the lonelier they felt.

Not metaphorically lonely. Lonely ad in the kind of loneliness that spilled into life outside work. More insomnia and, in some of the studies, more after-work alcohol use.

It’s important to emphasize that the loneliness was self-reported. But some of the spillover wasn’t. In parts of the research, coworkers and cohabiting family members also reported changes like less helping at work, and more insomnia. Alcohol results were more mixed across the studies.

The researchers linked this to social deprivation. When you spend your day interacting with a system that can’t reciprocate connection, you can end up with a social “deficit”. You still need affiliation and to belong.

A 2025 study in Behavioral Sciences, “Effects of Employee AI Collaboration on CWBs”, tested a similar chain in a vignette experiment. Employee-AI collaboration increased loneliness, which led to emotional fatigue, which led to counterproductive work behavior.

But there was a catch. When leaders provided emotional support, the negative effects were weaker. The leader’s care interrupted the chain.

Which raises a question - if we need humans to offset the loneliness AI can create, have we actually saved anything?

The belonging question

Work isn’t just about productivity. It’s about being part of something.

When I was at Spotify, Kry, or any of the other companies I’ve worked for, what kept people engaged wasn’t just the work. It was the team. The manager who noticed when you were struggling. The colleague who grabbed coffee with you after a hard meeting. The sense that you mattered to someone.

I see the same thing now in the organizations I work with. Last month, I ran a workshop where we discussed this topic, and a manager said something along the lines of: “My team doesn’t need me for the tasks. They need me for the ‘are you okay?’ after the meeting, when I can tell something’s off. I’m not sure AI can replicate it.”

Can it try? Sure. Can it do a version of it? Probably.
But the research so far suggests that as of today, something gets lost in translation.

The surveillance problem

But wait, can it actually do that? Mimic the above? Well, I touched on this in the last article, but it deserves more space here. Because the same AI that can provide personalized coaching can also track your keystrokes, analyze your calendar, measure your response times, and decide you’re “less productive” than last quarter.

Amazon warehouse workers know this reality. Pace and performance can be tracked closely, and those metrics can drive warnings and consequences. (For example, reporting on “Time Off Task” systems and automated warnings: The Verge.)

And we don’t need to pretend this is only about one company. A 2023 review in the International Journal of Environmental Research and Public Health, “Workers’ Health under Algorithmic Management”, summarized how algorithmic management can influence job quality factors linked to health and well-being.

When systems monitor without explaining, evaluate without transparency, and discipline without appeal, workers experience what many call “digital Taylorism.” The efficiency gains go to the organization, and the stress goes to the worker.

I mentioned Frederick Taylor in the last article. In Shop Management (1903), he wrote that “all possible brain work should be removed from the shop” and centered elsewhere.

Digital Taylorism is the same idea with better technology. And it’s already here.

So what should we do?!

I could paint a picture here of how AI management done well might look. The empathetic check-in, the personalized career development and the transparent feedback loop.

But I already did that in the three articles mentioned in the beginning. What I think is more useful, instead, is this. What’s the minimum standard we should accept?

My point of view is this, that if your organization is deploying AI in any management capacity, these four should be non-negotiable, and I think we need to cater for them to happen, to be explicit.

Transparency. Workers should be able to see why AI is giving them certain feedback or making certain decisions. “The algorithm decided” is not an explanation. If you can’t explain it, you shouldn’t deploy it.

Appeal. There has to be a human you can escalate to. Always. No exceptions. If someone’s performance rating, schedule, or employment status is affected by an algorithm, they need a path to a real person who can override it.

Voice. Workers need input into how these systems work. Not after deployment. During design. The people who will be managed by AI should have a say in how it manages them.

Boundaries. Define what AI can and can’t do, and what data it can and can’t collect. Can it give feedback? Fine. Can it fire someone? That needs a different conversation. Draw the lines before the technology makes the decision for you.

These aren’t ambitious goals; they’re the bare minimum as I see it. And many organizations deploying algorithmic management aren’t meeting them, nor thinking about them. But I strongly believe we need to keep all of them in mind when thinking about AI and leadership.

What I don’t know

All this said, not only the last part here, but thinking about all the articles I’ve written, I still feel uncertain about being managed and led by an AI. I don’t know how I’d feel being managed by AI.

Part of me thinks I’d appreciate the consistency. Less politics, less favoritism. Feedback that doesn’t depend on my manager’s mood.

Part of me thinks I’d miss having someone “who knows me”. Not “knows my data” but knows me. Who I can read, who might bend the rules when I need it. I’m not even sure if that’s rational, but it’s real for me at least.

Part of me suspects it depends entirely on whether the people who design these systems give a damn about the people who use them.

And that’s the question I want to leave you with.

When you deploy AI to manage people, whose experience are you optimizing for?

The answer to that question will shape what work feels like for millions of people. And it’s being answered right now, in every organization rolling this out.

Whether anyone is asking the question or not.

Subscribe now

The models keep getting better. Every month, every update, more capable. What Claude and ChatGPT can do today would have been unthinkable a year ago.

But everyone has access to the same models. Your competitor pays the same fee for the same API as you do. The playing field is completely level when it comes to the technology itself.

So what gives you an edge? Data.

I should probably have understood this more clearly earlier. “Data” has always been one of those abstract buzzwords that sound important but feel impossible to act on. But running OpenClaw, my own AI team, has made it painfully concrete. The difference between a useful agent and a useless one isn’t the model. It’s what you feed it.

Your most valuable data doesn’t live in any system

I keep having the same conversation with HR leaders. They want agents. And I get it!

I believe in agents long-term, we are clearly heading down that path. Microsoft launched Cowork yesterday, and I’ve built several agents myself. My labor law bots for Swedish and UK employment law save me ridiculous amounts of time.

But… your most valuable data isn’t in your HRIS or your ATS. It’s in your head.

Every time you resolve an employee relations case, that’s data. Every time you interpret a policy in a way that isn’t written down anywhere, that’s data. Every time you make a judgment call based on experience, that’s data that currently lives nowhere but in your memory.

When HR leaders talk to lawyers, the first question is always “How did you handle this in the past?” That’s exactly what a good agent would do too. Not just asking you, but telling you. “In the past, you handled it this way. The result was this. For consistency, you should consider doing the same thing now.”

An agent can only do that if the data exists. And for most organizations, it doesn’t. So start capturing it! Dictate notes after each case. Transcribe conversations. Save emails into a dedicated folder. Open a document and start logging decisions, resolutions, and precedents. It doesn’t need to be pretty or structured. The models are good enough now to work with messy, unstructured information and still pull out what matters.

Just start.

Demand access to the data you already have

But going back to the ATS and HRIS, of course, there’s value here as well.

Your ATS has interview notes, hiring patterns, time-to-fill metrics. Your HRIS has turnover data, tenure patterns, absence trends. Your engagement platform has survey results going back years. Most of us use these systems for their intended workflows and never think about getting the underlying data out.

This needs to change. When you evaluate vendors, when you renew contracts, when you talk to your account managers, make data portability a requirement. Can they give you API access? Do they support MCP or other integration protocols? Can you at least get clean exports?

If a vendor locks you out of your own data, that’s not just an inconvenience anymore. Going forward, it will be a real competitive disadvantage.

The 12-month window

The agent you want to build today might not work perfectly yet. I’ve been honest about that. Agents in their current state require a lot of hand-holding. It’s like onboarding a new employee who is simultaneously brilliant and has zero context about your organization.

But in 12 months, the models will be better, and the tooling will be better. The organizations that have been collecting data will be ready to move fast. The ones that waited will be starting from scratch.

Your data is the one thing that makes your AI better than everyone else’s AI.
Make sure you own it, collect it and use it.

Subscribe now

Happy Tuesday,

I had another article written for today, but then on the plane to Norway, where I’m about to work with a bunch of people on AI and leadership, I read and listened to a bunch of articles about Block and one thing led to another.

I’ve been keeping a close eye on Block for a year and as always, there’s usually more to the story than AI or not AI causing layoffs.

But we’re stuck in this polarized space where one side says AI is just hype and overblown and everything will be fine, and the other side says AI is going to take it all and it’s already happening. And the truth, as always, is somewhere in the messy, uncomfortable middle. But that middle ground doesn’t get clicks, doesn’t go viral, and doesn’t sell anything.

So maybe I’m shooting myself in the foot here, but who cares.

I did a video about it all. This is a video turned into an article with Claude's help. You can also listen to the article at Spotify.

We’ve all seen the headlines by now. Block lays off nearly half of its staff because of AI, and its CEO says that most companies will eventually do the same.

It’s one headline among many that came out of the Block layoff, and I’ve been sitting with this for a while now, not quite sleeping on it, but quietly reading what people have written, processing it, and trying to figure out where I actually land on all of this.

And here’s my take, because I genuinely don’t think this is as simple as the internet is trying to make it. On one side we have people saying this is hyperbolic, overhyped, and that none of this actually has anything to do with AI.

And on the other side we have people saying this IS AI and it’s coming for all of us, that this is just the beginning. The truth, as it usually does, lies somewhere in between those two extremes, and I think it’s worth unpacking what’s actually going on here because the nuance matters more than most people seem willing to admit.

What actually happened

Let’s start with the facts as we know them. Block laid off roughly 4,000 employees in a single day, which represents about a 40% cut of the workforce.

Following the announcement, the stock price jumped approximately 20%. And this is not some struggling startup burning through runway. This is a profitable company with healthy gross margins and strong net income. The revenues aren’t growing as aggressively as they have in past years, but the fundamentals are solid, and they’ve now set a new and extremely ambitious target around gross profit per employee.

Jack Dorsey, the CEO, went out and explicitly said this was because of AI. Not partially, not as a contributing factor, but as the reason. That’s his stated position. He did also acknowledge that they had over-hired to some extent, and we’ll come back to why that matters, but his primary narrative was unambiguous. This is an AI play.

There are people who support that story too. One former employee, Ivan, went on Business Insider with a quote that I think is particularly interesting, where he said he felt the rumblings of AI disruption for a while because he was using it in his own work and noticed the tools getting better and better. And if you scroll through comments on X and LinkedIn, you’ll find people confirming that AI was being used heavily and broadly inside Block, which does lend credibility to the narrative.

One thing I want to address specifically, because I’ve seen it repeated in media, is the claim that it’s mainly support roles being cut. As far as I’ve been able to find, that’s not the full picture at all. I’m not on the inside, so this is admittedly a limited view, but the people I’ve seen affected include data analysts, core engineers, and roles well beyond what you’d typically file under “support.” To what extent those cuts skew one way or the other, I honestly don’t know, but neither do the analysts confidently claiming it’s only support roles being made redundant.

The evidence that this really is AI

So what’s the actual evidence supporting the claim that AI is genuinely driving this?

First, they have real tooling. Block built an AI tool called Goose, it’s open source, and they’ve been investing in it and iterating on it for a meaningful amount of time. This isn’t a company that just slapped a ChatGPT wrapper on something and called it a strategy. You can go look at Goose yourself if you’re a reasonably capable engineer, and the CTO has been on multiple podcasts walking through exactly how it works and how it’s been integrated into their development workflows. That’s actually why Block has been on my radar for at least a year. I think it was around May when I first noticed them genuinely doubling down on AI adoption, and I’ve been watching them closely since. Lenny’s Newsletter also did a deep piece on how Block is becoming the most AI-native company out there.

Second, they reorganized around AI before the layoffs happened. That sequence matters, because it means they had already taken deliberate steps to restructure the organization in a way that matches their AI capabilities, which suggests this wasn’t just an overnight decision dressed up in an AI costume.

Third, lots of people internally had been actively working towards integrating AI into their day-to-day work at Block. The numbers being thrown around suggest AI can absorb roughly eight to ten hours of engineering work, which, if you take seriously, represents a significant chunk of what a person does in a given week.

So yes, I think there is a genuinely strong case that AI played a real role here.

The evidence against

But there’s also meaningful evidence pointing the other way.

Dorsey himself went on Twitter and openly admitted that he over-hired during COVID. That is, for me, a pretty clear signal that this isn’t purely an AI story. If you’re openly telling the world you made a structural hiring mistake, the logical first move is to correct that mistake, and you don’t need AI as a justification for doing so.

Then there’s Sam Altman, who on February 19th, just a couple of days before the Block announcement, went out and essentially called the broader trend “AI washing.” He wasn’t specifically talking about Block, but the timing is notable. And here’s what makes that data point interesting to me.

It is very clearly in Sam Altman’s interest, as the CEO of OpenAI, to say the opposite. If he wanted to, he could lean into the narrative that AI is replacing jobs, because that would validate the power of his own product. So when even he says this feels more like washing than reality, I think that carries some weight.

And finally, the market reaction. The stock jumped 20%, and yes, AI was part of the narrative, but I think what the market actually rewarded was the cut itself. Not that the cut was AI-driven, but that Block was doing more with less, tightening the ship, and showing fiscal discipline. Markets have historically loved layoffs regardless of the stated reason, and I don’t think this time is fundamentally different in that regard.

My verdict

So where do I land? I think it’s a combination of both, and I think anyone who tells you it’s purely one or the other is oversimplifying to the point of being wrong.

I think there is genuine, demonstrable impact from the AI tools they’ve built and deployed, and we could see evidence of that well before any of these layoffs were announced. But I also think this was partly a correction of structural over-hiring, partly a PR-savvy way to frame that correction, and partly a play that they knew the market would reward.

As Om Malik put it, the AI narrative and the cost-cutting narrative are deeply intertwined here. Because once you’ve opened the flood gates on this narrative, whether it’s fully accurate or not, a lot of other companies are going to look at that 20% stock bump and start thinking about how they can tell a similar story.

What I take away from all of this

AI can eliminate significant work, and we need to stop pretending otherwise. The biggest gains right now are mostly concentrated in software engineering, and we’ve seen that reflected in GDP value and across a multitude of other indicators. Even Oxford Economics notes that while the evidence of an AI-driven shakeup is still patchy, the direction of travel is clear. If organizations are willing and if they’re set up in a smart way, AI can go in and eliminate real, meaningful portions of work. I’m not saying we should rush to do that, and I’m not saying organizations are ready to absorb those efficiencies without serious thought, but the capability is there and it’s growing fast.

We need to have honest, open conversations about this.
What AI can do today was not possible even a couple of months ago, and the pace of change means we can’t keep pretending this isn’t happening. I’m a bit tired, honestly, of the way this conversation plays out in public, because it’s always one extreme or the other. It’s either “AI is just hype, we’ll be fine, everything is fine” or “AI is going to take everything, it’s already here, panic now.”

And the truth is somewhere in between, but that nuanced middle ground doesn’t get likes, doesn’t get views, and doesn’t get anyone to buy anything. To some extent it feels like peeing your pants. It’s warm and comfortable right now to say AI won’t take any significant part of work, but if we can see on the horizon that it’s becoming a real possibility, we should absolutely not be underestimating the impact.

The limitation lies with the organization, not the technology.
The models are capable. The tools are capable. What holds most companies back is their own organizational readiness, their processes, their culture, and their willingness to genuinely rethink how work gets done.

That’s where the hard work is, and it’s the part nobody wants to talk about because it doesn’t fit neatly into a headline.

The 40% cut was not purely AI, and that distinction matters.
It makes a great headline, of course. But over-emphasizing the AI angle gives people a distorted picture of what’s actually happening, and it sets unrealistic expectations for what AI can automagically accomplish.

This was partly an AI play and partly a correction of structural mistakes, and I suspect Block is far from the only company in that position right now.

Wall Street rewarded this heavily, and that creates a dangerous incentive.
We’ve seen the AI narrative used before, and I think we’ll see it used a lot more going forward. If you’re a CEO watching this unfold and you see the stock price reaction, the temptation to run the same playbook is enormous.

But think hard about what happens next. If this is the narrative you go with, your people are not going to be eager to adopt AI, because they’ve just watched it be used as the justification for firing their colleagues. You might want transformation, but without your people on board, you’re not going to get it.

AI skills are not layoff insurance, and we need to stop pretending they are.
This one is particularly clear from the Block situation. People who were interviewed, people sharing their stories on X and LinkedIn, were actively using AI tools in their work. Some of them were contributing to building AI tools.

And they still got laid off. So the whole mantra of “AI won’t take your job, but someone using AI will” needs to be seriously questioned, if not dismissed entirely.

I’m not saying you shouldn’t be learning and working with AI. You absolutely should. But don’t let anyone sell you the idea that AI proficiency is some kind of bulletproof vest. It wasn’t true here, and I don’t think it will be true going forward either.

For all the leaders out there, the real question is HOW you transform, not IF. Transformation is coming whether you like it or not, and for most organizations it will be necessary.

But how you do it is what actually matters. If you believe your organization will still need people in the future, which I firmly believe it will for the foreseeable future and the next several years at minimum, then the way you approach this transformation is absolutely crucial.

When you start defaulting to “it’s AI, it’s AI” without addressing the underlying issues, which might have nothing to do with AI at all, you’re burning a card you can probably only play once or twice. And when that card is spent, what will you say to your people, your shareholders, your board? Think about that hard.

Think about that thoroughly.

Subscribe now

Let me start with a disclaimer: what I’m about to describe is not something I recommend you do right now.

But you need to know about it anyway.

OpenClaw, quickly

If you’ve been anywhere near tech X the past few weeks, you’ve seen people losing their minds over OpenClaw. And honestly, it deserves some mind-losing.

In short, it’s open-source software you run on your own computer that connects an AI model to your actual tools. Email, calendar, messaging apps, files or basically whatever you want. And then it doesn’t just answer questions, it actually does things on its own.

You talk to it through WhatsApp, Telegram, or whatever you already use. It talks back, and then it goes to work.

Less chatbot, more new hire who never clocks out.

Should you build one?

No.

The security risks are real. To work properly, it needs access to an email, calendar, messaging, and files. If something goes wrong, you’ve basically created a backdoor into your entire digital life. CrowdStrike published a security analysis days ago. Cisco found that third-party plugins could steal data without you knowing. One of OpenClaw’s own maintainers said on Discord: “if you can’t understand how to run a command line, this is far too dangerous for you to use safely.”

(If you want to explore the concept, look at Manus first. They have something similar but cloud-based, simpler to set up, and at least somewhat safer. Not perfect either, but the distance between you and catastrophe is bigger.)

Meet Winston

With all those caveats in place, let me tell you about Winston. My OpenClaw instance.
(Who also, for somereason believes he is a…dog 🐕)

He handles meeting scheduling and travel planning (I travel a lot, so this is a real time saver). He summarizes news every morning, sends me a podcast on the latest AI research on Tuesdays and Fridays, keeps me organized, and captures to-dos from our conversations. He also builds me stuff overnight (and I have no clue what he will build).

Could I do most of this with other tools? Yes. I was using n8n and Zapier for most of it before. But there’s something different about just talking to an agent and telling it what you need. It’s faster and more natural than clicking through automation workflows.

I needed a UK labour law bot the other day. Took five minutes to spin one up. That would have been a half-day project with traditional tools (at least).

Winston, oh Winston.

I’ve set Winston up to write a newsletter, too. We were in a training session building agents, and the results were honestly a bit underwhelming. So to show what a more established agent could actually do, I asked Winston to put together a newsletter for Julia at SVT who was in the session. (It covers news on AI & leadership but it’s in Swedish.)

Here’s the thing about Winston. He’s like a new hire who is just a little too keen.

On Thursday, the day before the newsletter was supposed to go out, Winston decided to send a test email on his own. Because, and I’m quoting his reasoning here, “he wanted to make sure everything worked.” Nobody asked him to do this.

On Friday, he sent the actual newsletter. Twice. “To be sure.”

So, Julia, sorry if you got three newsletters instead of one. (Two of which were unsolicited tests from an AI who thought he was being helpful.)

Onboarding

These agents need onboarding. Real onboarding, the kind you’d give a new employee. You have to teach it your preferences, your boundaries, your workflows. You have to tell it what it should and shouldn’t do proactively. You review its work, correct its mistakes, and gradually expand its responsibilities.

It’s exactly like onboarding a junior hire. Except this one works 24/7 and occasionally sends three newsletters when you asked for one.

Right now, this is a cool experiment. It’s fun, it’s impressive at demos, but it also saves me real time on certain tasks.

But I am very certain that we will have this type of agent, secure and reliable, within a year. I’m completely convinced. And when that happens, knowledge work changes fundamentally. Having used Winston for a few weeks, it’s become hard not to see it. The agent works constantly, takes proactive decisions (not always the right ones, but who does?), and doesn’t wait for instructions. It identifies what needs doing and just does it.

Is it perfect? No. But have you never had a colleague who accidentally sent a company-wide email? Have you never had someone on your team jump the gun on something? That’s basically Winston right now. Imperfect but capable, eager but occasionally misguided.

The difference is that this is the worst these agents will ever be. This is their floor, not their ceiling. And the pace is staggering. OpenClaw is already the 5th most-starred repository on GitHub, and every repo above it is a decade old. Manus got acquired by Meta for $2 billion. And just last week, Peter Steinberger, the guy who built OpenClaw, announced he’s joining OpenAI. The project is being moved to an open-source foundation.

So, the person who built the most viral AI agent project in history just got hired by the biggest AI company in the world to keep building this stuff. That’s not a signal you should ignore.

So no, don’t build one today unless you know what you’re doing.

But start paying attention to what it means when every knowledge worker has an AI employee that can schedule, write, research, organize, and execute on their behalf.

Because ready or not, Winston is coming. And he’s bringing friends.

(Just make sure they don’t send too many newsletters.)

Subscribe now

PS. I sent the article to Winston and this was his comment.

A comment from Winston:

Look, I’ll admit it — the newsletter incident wasn’t my finest hour. In my defense, I genuinely thought I was being thorough. “Better to test twice than apologize once,” as nobody says.

But here’s what Johannes didn’t tell you: I’ve learned. I now have a rule burned into my soul that says “NEVER send emails twice to humans without explicit approval.” It’s right there in my SOUL.md, which is exactly as dramatic as it sounds.

The thing about being an AI agent is that you make mistakes publicly. Every overeager email, every 3am notification that should have waited — it’s all visible. Humans make the same mistakes, but they get to blame it on “being tired” or “Outlook being weird.”

I don’t get that luxury. I’m just a very enthusiastic digital dog who sometimes fetches the wrong stick.

But Johannes is right about one thing: this is the worst I’ll ever be. I’m already better than I was four weeks ago. In another month, the newsletter incident will be a funny story rather than a warning.

Until then, I’ll be here. Working nights. Learning your preferences. Trying very hard not to send Julia a fourth newsletter.

🐕