A job ad crossed my desk last week that didn’t exist eighteen months ago.
"AI Automation Specialist (Claude Code). Turn messy, manual agency and client work into reliable automations using Claude Code: wiring together APIs, databases, and dashboards so the team stops doing repetitive work by hand."
Full-time. There was a line about a Make.com sequence connecting to Claude, and another about “persistent AI agents across all standard departments.”
Strip away the tooling names and read what they’re actually hiring for. Someone in that company looked at the hours their team burns moving information between systems by hand, and decided it was worth a full-time salary to make it stop. That’s the signal. Not “AI is coming for jobs.” The opposite, almost: there is now a specific, nameable layer of work in most businesses that has quietly become automatable, and companies have started paying real money to capture it.
The goal here isn’t to replace anyone. It’s the opposite: connect the tools your team already uses to AI, hand the repetitive work to the machine, and free your people for the work that actually needs a human. Done well, the same team covers the ground of a much larger one. This post is about where that layer of work sits, what wiring it up actually looks like, and how to get the value without the new risk it introduces, because the same tooling that gives your team hours back can also, wired carelessly, hand an AI write-access to your live store.
The work lives in the gap between the tools you already pay for
Here’s the thing the job ad gets right. The opportunity isn’t a new app. It’s the space between the apps you already have.
Every business above a certain size runs on a handful of systems it looks at every morning. A code repository. A project tracker. A time tracker. A CRM. An accounting package. An e-commerce backend. Each one is good at its own job. None of them talk to each other without a human in the middle copying, pasting, reconciling, and re-typing. That human-in-the-middle work is invisible on any org chart, but it adds up to days per month across a team.
Until recently, closing that gap meant a custom integration project: brittle, expensive, and obsolete the moment a vendor changed an API. What changed is a boring piece of plumbing called the Model Context Protocol (MCP), the open standard Anthropic released so that AI tools like Claude Code can read from and act on your existing systems through a common connector. It sounds like infrastructure trivia. In practice it means the tools that have always been silent to AI can now be given a voice, safely and one at a time.
That’s the job. Not “build an AI”. Connect the AI you can already buy to the systems you already run.
Three ways this has played out for us
We don’t talk about this in the abstract. We’ve spent the last few months doing exactly this work, for ourselves and for clients. Three examples, three different shapes of the same pattern.
1. The Monday-morning report that writes itself
I used to learn what my team had actually done by skimming merge requests, reading standups, and sitting through a quarterly review. Visibility by archaeology.
Our code repository and project tracker were already connectable to Claude with standard connectors. The one piece that wasn’t was our internal time tracker, so we built a small custom MCP connector for it, about a week’s work. With all three readable, I can now ask one question and get back the story of the last eight weeks: which tickets moved, where the hours went, the nine-day debugging arc nobody flagged in standup, the infrastructure cleanup that quietly removed a hundred dollars a month of waste. Three engineers, 590 hours, read and narrated in about twelve minutes.
The repetitive work this killed wasn’t glamorous. It was the manual assembly of status reports, the cross-referencing of “what did we bill” against “what did we ship”. That’s gone. The report assembles itself, and a human spends their time judging it instead of building it.
2. The development flow itself
The second example is the one closest to the job ad’s “messy client work”. Software has a well-known lifecycle: plan, design, build, test, deploy, maintain. None of that changes. What changes is that AI now assists at every stage of it, while a person stays in the loop to steer and approve.
The repetitive, mechanical part of each stage is the part AI handles well. The judgement, whether this is the right approach and whether it is safe to ship, stays with our senior people. We run the same cycle for ourselves and on client engagements, and that combination, a known process sped up by AI with humans in control, is the difference between a senior team covering the ground of a much larger one.
3. A client running her Shopify store through Claude
The third is a customer who came to us with a simpler ask: she wanted to run her Shopify store by talking to it.
Not replace Shopify. Shopify is excellent at being Shopify, and we’d never pitch ripping out a core platform a business already depends on. She wanted the layer on top: “tell me which orders are stuck in fulfilment”, “draft a blog post for this new collection and the product descriptions to match”, “which products haven’t sold this quarter”. Work that’s a dozen clicks and a spreadsheet export each, several times a day.
We connected Claude to her store through a read-first MCP connector: it could see orders, products, collections, and content before it could change anything, and write-access was added deliberately, scope by scope, once she trusted what it was doing. The repetitive merchandising and reporting grind compressed into a conversation. The platform underneath didn’t change at all.
The pattern, and the part that goes wrong
Look across the three and the shape is identical. Low blast radius first. The tools were already there. The connector was small. And in every case the AI was given read before it was given write.
That last point is where this work turns from a productivity story into a risk story, and it’s exactly where an inexperienced “wire it all to Claude” job hire gets a business into trouble. Giving an AI agent the keys to your live systems is a security decision, not a convenience one. The questions that matter are the boring ones:
- What can it read, and what can it change? Read-only access to your orders is a report. Write-access to your orders is someone who can refund, cancel, and edit at machine speed. Those are not the same risk, and they should not be granted in the same breath.
- Where do the credentials live? The same failure that plagues vibe-coded apps (API keys and secrets in the wrong place) is doubly dangerous when the thing holding them can act autonomously.
- What’s the blast radius if it gets a prompt wrong? Start with the systems where a mistake is recoverable (reporting, drafts, internal tooling) and earn your way up to the ones where it isn’t (payments, customer data, fulfilment).
- Who approves, and what’s logged? Automation you can’t audit is a liability waiting for a regulator. Every action the agent takes should be reconstructable after the fact.
This is the same governance discipline that separates production software from a working demo. It doesn’t slow the value down. It’s the thing that lets you actually trust the value once it arrives.
You probably don’t need a full-time hire on day one
The company in that job ad decided this work was worth a permanent salary, and at sufficient scale they’re right. But for most mid-market businesses, the honest answer is that the first version of this is project-shaped, not headcount-shaped. You find the two or three places where your team bleeds the most hours into manual system-shuffling, you wire those up carefully, read-before-write, and you measure what it gives back before you commit to more.
The point of all of it is leverage, not replacement: the same team, freed from the manual grind and able to do more of the work that matters. The value is real and it’s available now. The job ad is just the market saying so out loud.
If you’d like to find where this layer of work is hiding in your business, and have it wired up by people who treat AI’s access to your systems as a security decision rather than a shortcut, that’s the work we do. Have a chat with us.
Daniel Z
Technical Lead · Two Red KitesTechnical Lead at Two Red Kites. Sits at the intersection of engineering and strategy: leading the team, setting technical direction, building internal developer tooling, and staying hands-on with the code across FinTech, HealthTech, Construction, and SaaS projects.