Domain-specific AI agents are agents built for one profession's work: software engineering, media production, finance, legal, cybersecurity, science. The argument for building them this way is not that general models are weak. It is that an agent is mostly its domain, and the parts that make it usable inside a company cannot be generic.
An agent is a model inside a harness: tools, permissions, context, budgets, logs and checks. The model can be shared across every domain. Almost nothing in the harness can, because its contents come from the domain.
What domain-specific AI agents get from the domain
Four things, and each is a concrete artefact rather than a flavour.
- The tools. What the agent can do. For software engineering: a repository, a shell, a test runner. For media production: a script, a storyboard, a renderer, a timeline. For finance: a ledger, market data, a reconciliation. For legal: a document corpus, a citation check, a redline. For cybersecurity: a scanner, logs, a ticketing system. For science: a protocol, an instrument, a simulation.
- The data rules. What may enter the agent's context and what may leave it. Source licences and secrets in code; unreleased material in media; material non-public information in finance; privilege in legal; indicators and victim data in security; subject and patient data in science.
- The evaluation. What correct means and how it is checked. Tests pass. The episode plays and the characters hold their look. The numbers reconcile. The citation exists and says what is claimed. The finding reproduces. The experiment replicates.
- The review gate. Who signs off and in what form. A code reviewer on a diff. An editor on a cut. A controller on a close. A lawyer on a filing. An analyst on a finding. A principal investigator on a result.
Each of these already exists in the profession. The agent does not invent them; it is wired to them. That wiring is most of the work and all of the trust.
Why a generic agent lacks all four
A general-purpose agent ships with general-purpose tools: a browser, a shell, a file system. It has no data rules, because it does not know what privileged, non-public or licensed mean in your context. Its evaluation is whether the output looks plausible to the person reading it. Its review gate is whoever happens to be watching.
That is fine for a demo and unacceptable in a company, where the first three questions are what it can touch, what it may see, and who checked. A generic agent cannot answer them, not because the model is weak but because nobody built the domain into the harness.
Making a general agent safe for one profession means adding the domain's tools, rules, checks and gate. At that point it is a domain-specific agent with a general model inside, which is the same thing built in the harder order.
Agents for coding versus agents for work
Coding agents are ahead of every other domain, and the reason is structural rather than a matter of effort. Software engineering happens to supply all four things in an unusually usable form.
- The artefact is text, so the model can read and write it directly.
- The check is executable: tests pass or fail without a human opinion. That property is what let SWE-bench turn real repository issues into a benchmark.
- Version control gives every change a base, a diff and a rollback for free.
- The review gate already exists and is already enforced: pull requests and required checks.
An agent for work, meaning general knowledge work, has none of these by default. The artefact is a document or a decision, the check is a person's judgement, there is often no version control, and the gate is a meeting. Such an agent either borrows a domain's structure or has none, and an agent with none is an assistant with a longer leash.
The second agent on the Runix stack is in media production, and the same test applies there. A comic drama has a script, a board, an episode and a publishing step: a production line with artefacts and checks at each stage, even though none of them is a unit test.
The data layer's domain rules come first
An agent reads domain data through its tools, is evaluated on domain data, and is sometimes trained on it. If the data has no rules, the agent inherits the absence. That is why, on the Runix stack, the domain rules live in the data layer and the agents layer sits on top of it.
Runix Data covers six domains, each with its own rules and the public standards they follow: code, which is the focus, finance, cybersecurity, legal, embodied AI and AI for Science. Across all six, every record carries its provenance and licence, personal data is masked before a training set and the masking fails closed, and evaluation data is split from training data by source so that near-duplicates cannot sit on both sides.
The code domain shows what a domain rule looks like when it is executable: a code task is run in a clean container, the target tests pass with the patch and fail without it, and the rest of the suite still passes. That is the same check a coding agent is held to, applied to the data before the agent exists. A finance or legal agent needs its domain's equivalent of that executable check, and until the data layer has one, the agent has nothing to be grounded in or evaluated against.
Two agents today
The agents layer of the Runix stack is organised by professional domain, and it is short. Two agents exist today, both in development: Runix Code, for software engineering, and Runix Comic, for comic dramas in media and entertainment. Each is designed to run as an independent agent for its domain with its own harness; Runix Router is optional in front of their model calls.
The other domains named in this post are data-layer domains, not agents. The prerequisite for an agent in any domain is the one described above: its tools, data rules, evaluation and review gate have to exist first.
That ordering is the point of presenting the layer by domain. An agent is the top of a stack that starts with data rules, and the honest statement of where Runix Lab is today is two agents, both in development, with the layers beneath them further along.
Questions this raises
What is a domain-specific AI agent?
An agent whose tools, data rules, evaluation and review gate come from one profession, such as software engineering or media production. The model inside can be general; the harness around it is built for the domain.
Why are coding agents ahead of agents for other fields?
Software engineering supplies the four things in a usable form: the artefact is text, tests give an executable check, version control gives diffs and rollback, and code review is an existing gate. Most other domains have to build equivalents first.
Which agents does Runix Lab have today?
Two, both in development: Runix Code for software engineering and Runix Comic for comic dramas. The other domains on the stack are data-layer domains, not agents.