After I wrote about working through agents, the most common response wasn't disagreement, it was confusion. Smart people asking: "Isn't this just semantics?"
Here's the clearest way I can explain why it isn't.
The F-35 test
When you fly an F-35, you don't actually fly the plane. The plane flies itself. You focus on the mission.
That's the distinction: working with AI means you're still flying the plane, just with better instruments. Working through AI means the plane flies itself while you focus on mission objectives.
What this looks like in practice
Imagine two engineers asked to fix a broken pipeline.
Engineer A opens a browser, pokes around the logs, googles the error if it's unfamiliar, copies suggestions into VS Code, makes changes, triggers the pipeline, waits. If another error appears, the cycle repeats. AI helps with one specific thing at a time, but the workflow is still people doing the work.
Engineer B opens Claude Code and says: "Fix this pipeline." The agent reads the logs, identifies errors, applies fixes, reruns the pipeline, watches the output, iterates. The engineer watches the trajectory, says "that looks good," and tells the agent to commit and open a PR.
Same task. Same outcome. Completely different relationship.
The first is working with AI, the second is working through it. The difference isn't the tool, it's whether AI handles isolated tasks within your workflow, or whether AI is the workflow.
By working through an agent, I mean that the agent becomes the primary execution environment. It's not an assistant. It's the place where the work actually happens.
What this looks like for me
This site is a custom platform built from scratch in Rust, created entirely through Claude Code. No framework bloat, no features I'll never use. Single binary, scales to zero, content negotiation that returns markdown if you request it. Just Claude Code, custom skills, and MCP servers. I never left the terminal.
The agent ran the deployment, wrote and ran tests, committed code, pushed to the repository. Cover images, audio overviews? All automated. Was I programming? In the traditional sense, no: I was steering, reviewing, deciding. The agent did the engineering.
This isn't theoretical. It's Tuesday.
The barriers that stop you
Most infrastructure isn't built for this yet.
Think about where documentation lives in most organisations. SharePoint sites with nested folders and inconsistent permissions. Internal portals that require browser auth just to see the content. Custom wikis compiled into something an agent can't parse without wasting context on noise.
People can barely navigate these. Agents can't at all.
Even when documentation is accessible, there's another problem: most docs were written without agents in mind, padded with unnecessary context, sprawling across dozens of pages nobody maintains. Once they get long, people stop updating them, agents ingest outdated information, and context rot sets in fast.
Writing for agents means being concise by default, leaving out what isn't needed, and that constraint also makes documentation easier to maintain. Shorter docs get updated. Long docs get abandoned.
The typical response is to throw money at the problem: vector databases, embedding pipelines, RAG architectures that chunk your content so AI can search through it. Expensive infrastructure to make AI-hostile formats slightly less hostile.
But for anything net new, there's a simpler approach: make it AI-friendly from the start.
Store facts in plain, structured formats, then generate the polished documentation from that. The AI-readable version becomes the source of truth; the branded PDFs and wiki pages are derived outputs, tailored to whoever needs them.
We keep waiting for one AI solution to fix all our access problems. Meanwhile, we keep creating the very problems we're waiting to be solved.
What's emerging
Some vendors are catching on: Atlassian provides MCP servers for Confluence, so agents can query documentation directly. If your docs are there, you're already ahead, but most internal tooling hasn't made this shift.
If your documentation were accessible via MCP, agents could consume it directly. People would consume it through their AI assistants. Making something agent-friendly makes it people-friendly too, because the agent layer sits between them.
Emerging protocols let agents generate UI components dynamically. These protocols solve slightly different problems, which I'll dig into in a future article. For now, imagine a user guide as an MCP server with a thin UI layer that talks to it: agents query the server directly, people get a browser experience rendered on the fly. Same source of truth, different access patterns.
This site does something simpler: request the page asking for markdown and you get markdown back, not HTML. Agents get clean text, people get the formatted version. Tools like Claude Code and Copilot CLI already request markdown by default, and if the server doesn't support it, they get HTML anyway, so there's nothing to lose.
Where this goes
Eventually, users could set preferences: "I'm technical, skip the background" or "I'm new to this, give me more context" or "Format this for a leadership presentation." The content morphs to match, rendered dynamically by an agent that understands both the content and the user.
This already happens with CVs: there's no "my CV," only "my CV for this role." You reformat every time because different audiences need different presentations of the same facts.
Design for agents, and everyone benefits.
The thought experiment
Try this: imagine your entire workday executed through a single agent session.
You'll immediately identify the blockers: services requiring browser auth, documentation locked behind JavaScript, workflows assuming someone clicks buttons, context from meetings that never makes it back to your agent.
Some blockers you can remove. Others, like meetings, you work around: if there's no automatic transcript feeding into your agent's context, you summarise the key points yourself. The goal isn't to eliminate human interaction, it's to close the loop so your agent stays informed.
The organisations addressing these barriers fastest will move more of their work into "through" mode. Everyone else will keep context-switching between modes, losing efficiency at every transition.
So what?
The question "is this just vocabulary?" is fair. "With" and "through" are vague enough to mean almost anything.
But the underlying distinction is real: are you using AI to accelerate isolated tasks within your workflow, or is AI executing the workflow while you provide direction?
Both are valid, but they require different infrastructure, different skills, and different ways of thinking about your role. The datacentre investments being made today will push inference costs down, and what's premium access now will become standard. More of us will become AI wranglers and orchestrators: less doing, more steering.
If you're in "with" mode everywhere, you're leaving capability on the table. Start asking "what would it take to do this through an agent?" and you'll find the barriers.
Every barrier you remove is one less thing pulling you back to "with" mode.
Thanks to Darragh McConville for his review, critique and insights on this article. His Substack is worth checking out.
A note on privacy: Working through AI, just like working with AI, should be done using inference that is opted out of training on your data. If you're doing this at work, use tools that are approved and vetted by your organisation.