Agents for everyone

Or: Don’t let your engineers hoard the best tools.

I’ve been doing a lot of non-engineering work with engineering tools lately.

A few weeks ago I needed to figure out how a company might behave after being acquired. Not a question you can Google. I used Claude Code to synthesize press releases, earnings calls, job postings, past acquisitions — looking for patterns in the acquirer’s history, building an argument from evidence. The files weren’t code. The work wasn’t engineering. But the tool could access the files, write code to analyze them, and give me a verifiable answer instead of a plausible-sounding summary from its uninspectable heart.

The pattern keeps working. Competitive research. Content management for this Substack. Synthesis across messy sources. Every time, I reach for the “developer tool” and use it for work that has nothing to do with development.

And every time, I notice that many of my “non-technical” colleagues — most knowledge workers, really — can’t do this. Not because they lack the ability, but because they don’t know what to ask for, and nobody has given them access to the tools or shown them how to use them. They’re stuck in chat.

What’s different now

A year ago, AI tools for knowledge work meant chat interfaces. Ask a question, get a response, start over next time. Useful for drafting and brainstorming, but limited.

Now there’s a different category: agentic tools that can access your files, write code to analyze them, observe the results, and iterate. They don’t just generate plausible-sounding answers — they compute verifiable ones by writing code that you can run repeatedly and get the same answer.

The distinction matters. “What should our messaging emphasize?” is a thinking question — it requires judgment, and there’s no way to verify the answer. But “What patterns exist in these 500 support tickets, and which issues come up most often?” is a checking question. There’s a real answer, and a tool can find it and show its work.

Not every question is obviously one or the other. “How might this competitor behave post-acquisition?” sounds like a thinking question, but I turned it into a checking question by reframing: “What patterns exist in this acquirer’s history with previous acquisitions?” That’s computable. I can verify the answer against the evidence. The computed answer then becomes input to judgment about what might happen next.

Most knowledge work has both kinds of questions. The checking questions are often the tedious ones — the weekly reports, the data reconciliation, the pattern-finding across messy sources. These are the tasks that eat hours. And these are exactly the tasks that agentic tools can handle.

The math adds up fast

A weekly report that takes three hours to compile. Someone pulls data from multiple sources, reconciles discrepancies, formats the output, spots patterns worth highlighting. Every week.

With the right tool, that same person describes what they need, the tool writes code to produce it, they verify the output once, and then they run the same analysis every week in minutes. Three hours becomes fifteen minutes. Every week. That’s over 100 hours a year, from one report.

Multiply that across every recurring analysis in your organization. The savings compound.

The fluency barrier is real, but lower than you’d think

There’s a catch: these tools currently require some technical fluency. Comfort with a terminal. Basic familiarity with how code works — not how to write it, but how to read it well enough to spot when something looks wrong. A sense for when to trust output and when to verify.

They also require policies and guardrails — not because the tools are dangerous, but because organizations need to think through questions they haven’t had to answer before. What data can flow through these services? Who approves workflows that touch sensitive information? When does a “quick script” need review before someone relies on it for decisions? These aren’t blocking questions, but they do need answers. The companies moving fastest on this aren’t the ones ignoring these concerns; they’re the ones who’ve already thought them through and written down reasonable defaults.

This is why these tools have mostly stayed with engineering teams. But here’s what I’ve observed: knowledge workers with no engineering background can develop this fluency faster than you’d expect, especially when they’re motivated by a specific problem they want to solve.

The barrier isn’t writing code — the AI does that. The barrier is knowing what questions to ask and whether the answers make sense. Your analysts and ops people already have that skill. They’ve been doing it with spreadsheets and SQL queries for years. This is the same muscle, applied to more powerful tools.

What organizations are missing

Most organizations haven’t given non-engineers access to these tools yet. The reasons are familiar: unpredictable costs, liability questions, “this is an engineering tool” assumptions, shadow IT concerns. These aren’t unreasonable — but they’re causing organizations to miss something important.

The opportunity cost is invisible. You see subscription costs on a line item; you don’t see the 100 hours a year someone spends on a report that could be automated. You don’t see the analysis that never happens because no one has time. You don’t see the patterns hiding in data that no one’s looked at systematically.

The verification skill already exists. Your non-engineers aren’t going to blindly trust AI output any more than they blindly trust a spreadsheet formula. They already sanity-check data pulls. They already spot when numbers don’t add up. That skepticism transfers directly.

And motivation solves the learning curve faster than training does. The people most frustrated by tedious work are the ones who’ll push through the friction to eliminate it. You don’t need to mandate adoption — you need to make adoption possible for people who are already looking for a way out.

There’s a signal in what gets built, too. When someone creates a throwaway script and it sticks around because it actually solves a problem, that’s information. It tells you where the real pain points are. You learn what matters by watching what people reach for when given the chance.

Your competitors who figure this out will move faster. Not because they have better engineers — because they have more people capable of turning questions into answers without waiting in a queue.

What this looks like in practice

I’m not suggesting you mandate that everyone learn Claude Code. I’m suggesting you make it available to people who want to try it, with some guardrails:

Start with volunteers. Find the people already frustrated by repetitive work. They’re motivated to push through the learning curve.

Pair them with someone technical. for the first few projects — not to do the work for them, but to help them recognize when output looks right and when to be skeptical. The code these tools generate can still be wrong. Sanity-checking the output matters, especially early on.

Focus on recurring tasks first. Weekly reports, monthly reconciliations, regular data pulls. These have the easiest wins and create reusable workflows.

Expect some throwaway code to become essential. When someone builds a script that solves a real problem, it tends to stick around. This is actually good — it tells you which problems are worth investing in properly. When that happens, someone needs to own it — document it, maintain it, or hand it to engineering if it’s critical. The throwaway version is how you discover what’s worth building for real.

A real example — and what’s still missing

At Swarmia, I built a set of tools for our content marketing team. Skills for outlining posts, generating drafts, ideation, fact-checking, continuity checking across the content library. The content team still writes everything — these tools just make the iteration cycle faster. Instead of waiting for someone to review a draft for consistency with previous posts, they can run a check themselves. Instead of manually hunting for claims that need sources, a tool flags them.

It works. But I could build these tools because I know what’s possible and how to break down the problem — and that’s exactly the gap. Even with purpose-built tooling, the barriers for the people using them are real. Using these tools still requires a Claude Code subscription, running an installer from the command line, and answering technical questions from the tool itself (“Do you want to allow this command?”). These aren’t insurmountable — the content team figured it out — but they’re friction that shouldn’t exist.

What I want is the ability to package up skills like this so people can use them in a more familiar interface. A web app. A Slack bot. Something that doesn’t require finding the terminal in an IDE. The underlying capabilities exist — the gap is in how we deliver them to people who aren’t comfortable with developer tools.

Anthropic’s Claude Cowork is a step in this direction — it puts agentic capabilities in a desktop app instead of a terminal, with a folder-permission model instead of command-line navigation. That’s real progress. But it’s still macOS-only, still requires a per-seat subscription, and still assumes users can evaluate whether output looks right. It lowers the floor, but it doesn’t eliminate the need for verification skills. And it doesn’t yet solve the workflow problem: the ability to run the same analysis every week, or to package a skill someone else built so your ops team can use it without understanding how it works.

This is the remaining gap. We have powerful agentic tools, but they’re wrapped in interfaces built for engineers. Until that changes, adoption will stay limited to people willing to push through the friction. That’s a smaller group than it needs to be.