AI Agents Let Domain Experts Build Systems

By August 2026, the evidence supports a more precise claim about AI agents: they can let domain experts turn their knowledge into working systems with less day-to-day dependence on software engineers. They have not made expertise optional. The scarce skills are shifting from writing every implementation detail to defining the problem, supplying context, testing outcomes and controlling what the system may do.

The strongest recent usage data shows that division of labor emerging in practice. A June 2026 Anthropic analysis of roughly 400,000 Claude Code sessions found that people made about 70% of planning decisions while Claude made about 80% of execution decisions. The study covered sessions from approximately 235,000 users between October 2025 and April 2026; it also found that task-specific expertise was associated with higher success, even when the user was not a professional programmer.

What agents change about building a system

A chatbot primarily produces an answer. An agent can work through a sequence: inspect files, call tools, edit an artifact, run checks, observe the result and revise its approach. That loop makes it possible for one person to create something closer to a small operational system than a collection of disconnected prompts.

The distinction matters. A reusable system has inputs, rules, state, outputs and a definition of success. A sales operations specialist might specify how incoming records should be classified; a researcher might define how documents should be collected, compared and cited; an individual might create a workflow that organizes notes and produces a weekly review. The agent can implement much of the machinery, but the user still has to know which distinctions matter.

This is why “no-code” is an incomplete description. Natural-language direction may replace some syntax, yet it does not replace decisions about data quality, exceptions, permissions or acceptable failure. The interface has become more accessible; the underlying responsibility has not disappeared.

The new advantage belongs to people who can specify the work

Domain knowledge becomes operational when it is expressed as rules an agent can follow and tests it cannot casually satisfy. An accountant may not know the programming language used to build a reconciliation tool, but may know that refunds, partial payments, currency conversions and month-end cutoffs require separate treatment. That knowledge is more valuable than a vague request to “automate reconciliation.”

A useful agent-built system therefore starts with a compact specification:

the exact input and where it comes from;
the transformation or decision the system is allowed to make;
the cases that must be escalated to a person;
the evidence required to accept an output;
the actions that require approval or must remain unavailable.

This specification also makes iteration cheaper. When the first version fails, the user can identify whether the problem lies in missing context, an ambiguous rule, inadequate tool access or a weak test. Without that diagnosis, repeated prompting may produce a more polished system without making it more dependable.

Corporate adoption adds governance, not just scale

Inside a company, a useful prototype is only the beginning. The system may need access to customer records, internal documents, communications or transaction tools. That turns identity, authorization, auditability and rollback into product requirements rather than administrative details.

The current status of one prominent offering illustrates this boundary. OpenAI’s workspace-agent page lists the product as a research preview for ChatGPT Business, Enterprise, Edu and Teachers plans. It describes role-based controls, activity monitoring and approval gates for sensitive actions, alongside agents that can run scheduled workflows and work across connected applications. In other words, easier construction is being paired with centralized limits on deployment.

That separation creates three distinct roles. A subject-matter expert defines the workflow and evaluates its output. Technical or security staff decide which systems and data it may reach. An accountable business owner determines whether its speed and consistency justify the operational risk. One person may fill more than one role in a small organization, but the decisions do not vanish.

Corporate systems also need versioning and evaluation. A change to a model, instruction set, connected database or external service can alter behavior without changing the apparent interface. Teams therefore need saved test cases, traceable changes and a way to stop or reverse consequential actions. A successful demonstration cannot substitute for that operating discipline.

Personal systems are easier to start—and easier to neglect

For an individual, the same technology can connect notes, files, calendars, scripts and research routines into a personal workflow. The practical benefit is not that the agent becomes an all-knowing “life operating system.” It is that one person can encode a recurring process without first turning it into a conventional software project.

The best personal use cases have observable outcomes: files are renamed according to a rule, expenses are placed into review categories, cited notes are assembled from a defined folder, or a recurring report is produced from specified inputs. Tasks such as deciding a life priority or judging the truth of an unfamiliar claim remain poorly served by automation without independent evidence and human judgment.

Maintenance is the hidden cost. Connections expire, file formats change, instructions accumulate contradictions and old assumptions remain embedded in templates. A personal system should therefore expose what it changed, preserve original material where possible and make destructive actions reversible. Convenience is valuable only while the owner can still understand and correct the workflow.

Capability benchmarks do not prove general autonomy

Agent capability is improving, but benchmark results need careful interpretation. The METR task-completion methodology updated in May 2026 measures the human-expert duration of tasks that an agent is predicted to complete at a stated reliability level. Its suite contains more than 100 primarily software-engineering, machine-learning and cybersecurity tasks that are comparatively self-contained, well specified and automatically scoreable.

METR explicitly warns that these results do not mean an agent can automate every job, or even every real-world task of the same duration. Professional work often depends on tacit context, interaction with other people and success criteria that cannot be reduced to a clean automated score. Performance also varies sharply across domains and agent configurations.

This limitation explains why agents can appear remarkably capable in one workflow and unreliable in a neighboring one. A system that passes deterministic software tests may be ready for supervised use; a system making subjective legal, medical, employment or financial judgments faces a different standard. Longer autonomous operation is not itself evidence of better judgment.

The threshold for building has fallen, not the threshold for responsibility

The meaningful change is that implementation is becoming available to more people. A domain expert can increasingly move from an idea to a functioning, testable workflow without waiting for every step to pass through a traditional development queue. Organizations can also distribute approved systems so that one person’s process knowledge benefits a wider team.

The durable advantage, however, comes from knowing what to build and how to recognize failure. The most effective builders will combine subject expertise with explicit acceptance tests, limited permissions and human checkpoints for consequential actions. AI agents compress the distance between intention and implementation; they do not close the distance between a plausible result and a trustworthy one.

AI Agents Let Domain Experts Build Systems—but Expertise Still Sets the Ceiling