Every agent is a coding agent

Under every serious agent, whatever industry it is built for, there is a coding agent. I did not get to that from theory.

Akarii began as a coding agent for a team. It wrote code, and then it turned out it could do plenty of things that were not really about code at all. That was when it clicked. The coding was not the use case. It was the foundation.

Why it starts with code

Agents live inside computers, and the thing models are almost unreasonably good at is understanding code and driving a machine. That is where an agent naturally begins. Not because the job is programming, but because code is how you get a computer to do anything at all.

A coding agent can read files, run commands, call tools, and write a small script for the thing that has no button. Give it that and it can reach most of what a computer can reach. Everything narrower is a subset. The most general agent you can build, then, is one that operates a computer through code, and every other agent is that same thing, aimed.

Every domain agent is one of these, pointed somewhere

So I do not really think a legal agent or a sales agent or a science agent is a different species. Underneath, each is a coding agent given the right context, the right tools, and a domain to work in. Omaru looks like it is drifting away from code, it runs tasks for a person building a business, but the engine underneath is the same, and the tasks it handles most easily are the ones that live in software.

You can watch the frontier build exactly this way. Anthropic took the coding agent behind Claude Code and widened it into Cowork, which works across your files and applications to handle knowledge work. The same foundation then gets applied in every direction, at roles like sales, legal, and finance through plugins that turn it into a specialist, and at whole crafts like design with Claude Design. One agent that operates a computer, turned toward one field after another.

The mistake is thinking in workflows

Most people are not seeing this yet. When they imagine building an agent, they imagine a workflow. Boxes and arrows, this step then that step, the kind of thing you wire together in a workflow builder like n8n.

There was a window where that made sense, when stringing a few steps together with a model in the middle was genuinely useful. That window is closing. The agents we have now do that automation and far more, so a workflow is not just limited. It is the wrong level to be thinking at.

The real problem with a workflow is that a person fixed the steps ahead of time. Everything else follows from that. The intelligence is capped at whatever someone thought to wire up, and the whole thing breaks the first time reality does something that is not on the diagram. You cannot draw enough boxes to cover the world.

Rules, tools, guardrails, not boxes

The right abstraction is not a diagram of the path. You give the agent rules for how to behave, tools for what it can touch, guardrails for what it must never do, and then you let it choose the steps itself. It is a different way of thinking, and it is the one that holds up when the task gets messy.

It is also harder to picture, which is part of why the workflow idea hangs on. A flowchart is easy to see. An agent you have handed rules and tools and set loose is not something you can fully draw in advance. It is just the thing that works.

Start from the coding agent

So if you are setting out to build an agent, even one with nothing to do with software, I would start from a coding agent and aim it at the problem. The people in the middle of this already build this way. Most of the world is still drawing boxes.

The distance between those two is not really about tools. It is about understanding what an agent is. And the fastest way to understand it is to build one, and watch it do something you never wired it to do.