Every agent is a coding agent

I’ve started to see coding agents less as a category and more as a foundation. That view came from building Akarii, not from drawing an architecture diagram.

Akarii began as a coding agent for a team. Once people used it, the agent kept proving useful for tasks that weren’t really about code. What mattered was its ability to inspect files, use tools, and act inside a computer. Writing software was one application of that ability.

Why it starts with code

Agents live inside computers, and models happen to be very good at understanding code. Code gives them a general way to operate the machine, including when the task itself has nothing to do with programming.

A coding agent can read files, run commands, call tools, and write a small script when no ready-made button exists. Those capabilities cover a surprising amount of computer work. A domain agent can build on the same base, then add the context and tools of a particular field.

Every domain agent is one of these, pointed somewhere

A legal, sales, or science agent doesn’t need a completely different core. It needs the right context, permissions, tools, and domain instructions. Omaru runs tasks for people building businesses, which looks far removed from coding, but its underlying agent still works this way. Unsurprisingly, it is strongest when the task touches software.

You can see the same pattern in Anthropic’s products. The agent behind Claude Code expanded into Cowork, which applies similar capabilities across files and applications. Plugins then supply the context for areas such as sales, legal, and finance, while Claude Design points the agent at a particular craft. The specialisation sits on top of a general computer-operating agent.

The mistake is thinking in workflows

A lot of “agent” designs still begin as workflow diagrams: boxes and arrows, one fixed step after another, like an automation assembled in n8n.

Those workflows can be useful for predictable processes. They become restrictive when the task is messy or the route can’t be known in advance. Current agents can decide between tools and recover from small surprises, so prescribing every step often throws away the capability you wanted in the first place.

A fixed workflow can only handle situations its author anticipated. Add enough branches and the diagram becomes difficult to maintain; miss one and the process stalls. I ran into this whenever real work refused to follow the neat route I had drawn for it.

Rules, tools, guardrails, not boxes

I now prefer to define behaviour rather than a path: what the agent is trying to achieve, which tools it may use, when it needs approval, and what it must never do. Within those boundaries, it can choose the steps. That approach has held up better when tasks take an unexpected turn.

This is harder to present in a tidy diagram. A flowchart shows an exact route; an agent may take a different one each time. The design is still there, but it lives in the boundaries, tool descriptions, and evaluation rather than in a sequence of boxes.

Start from the coding agent

If I were starting a domain agent today, I’d begin with a capable coding agent and adapt it to the problem. I’d add domain knowledge and narrow its permissions before I considered building a bespoke chain of model calls.

The distinction becomes obvious once you build one. The first time an agent finds a reasonable route you never explicitly wired up, a workflow diagram starts to feel like the wrong description of what you made.