When Human Language Becomes the Automation Language

In early February, Anthropic released a legal plugin for Claude. Not a chatbot that answers questions about case law, but a structured tool that connects to legal research databases, drafts documents using firm-specific templates, and manages review workflows. Legal tech publications covered it as a turning point for the profession, and it's easy to see why. This wasn't a generic AI feature bolted onto an existing product. It was a purpose-built automation layer for a specific domain, described and configured in plain human language.

The legal plugin is worth paying attention to, but not because of what it means for lawyers specifically. It's one example of something much broader that Anthropic is enabling: the ability to describe complex business workflows in plain language, connect them to real tools and systems, and have an AI agent execute them with a human reviewing the critical decisions. Law is just the most recent domain to get this treatment. Accounting, HR, compliance, procurement, marketing operations, really any white-collar function that runs on documents, data, and defined processes is a candidate for the same approach. The pattern is the same every time: describe the workflow, connect the systems, let the AI agent handle the coordination, keep a human on the judgment calls.

What this looks like today

The building blocks are straightforward enough. The Model Context Protocol (MCP) is an open standard that lets you connect Claude to external tools and data sources. Your databases, your APIs, your file systems, your deployment pipelines, your internal tools. Skills are packaged instructions that teach Claude how to work within a specific context, written in human language rather than code. And Claude Code (Anthropic's open-source command-line agent) is the runtime that ties it all together.

Put these pieces together and something interesting happens. You can take a business process that previously required specialized scripts, custom integrations, and someone who knows the right sequence of steps, and instead describe it as a set of requirements. "Every month, pull the team's expenses from the card system, match them to receipts, flag anything over the approval threshold, and generate the summary report for finance." Or: "Pull this quarter's numbers from our three dashboards, combine them into the board deck template, and flag any metrics that are trending more than 10% off target." The AI agent reads those instructions, uses MCP connections to interact with each system, and does the work, stopping where you've told it a human should weigh in.

This isn't hypothetical. We've been running exactly these kinds of flows in our own work, distilling business processes into skills and MCP configurations, and the results have been genuinely surprising. Complex multi-step workflows that used to require someone with specific system knowledge can now be triggered with a single request and run with human-in-the-loop checkpoints at the points that matter. The AI agent handles the tedious coordination between systems. The human handles the judgment calls.

Why human language as the interface matters

The thing that makes this different from previous automation approaches is the interface. Traditional automation requires you to express workflows in code, scripts, or rigid workflow builders. Each system has its own API, its own syntax, its own quirks. The person building the automation needs to understand all of those technical details.

When the interface is human language (structured requirements, described in your own words) the barrier to creating and modifying automation drops dramatically. A team lead who understands the business process can describe it. They don't need to know Python, or Zapier's trigger syntax, or how to write a Terraform module. They need to be able to clearly articulate what should happen, in what order, and where a human should step in.

This isn't just a nicer wrapper on the same thing. It changes who can create automation, how quickly it can be modified, and how far it can reach. Processes that were never worth the engineering effort to automate with traditional tools become viable when the "development" cost is writing a clear set of instructions.

We've seen this pattern before

If this sounds disruptive in a way that might make people nervous, it's worth looking at what happened when Infrastructure as Code (IaC) arrived.

Before tools like Terraform, CloudFormation, and Ansible, infrastructure was managed manually. Engineers logged into servers, clicked through consoles, and ran commands by hand. When IaC showed up, there was real anxiety. If you can define infrastructure in code and apply it automatically, what happens to the people who used to do that manually?

What actually happened was that the role evolved. The manual work went away, but the need for people who understand infrastructure didn't. It shifted toward design, architecture, policy, and oversight. Someone still needs to decide what the infrastructure should look like, review changes before they're applied, handle the edge cases that automation can't, and make sure the whole system stays secure and reliable. IaC didn't eliminate infrastructure jobs. It changed what those jobs look like and made the people doing them more productive.

The parallel to what's happening with AI-driven automation is pretty direct. The manual coordination work (copying data between systems, running through checklists, following documented procedures step by step) is exactly what AI agents are good at. The judgment work (deciding which approach to take, reviewing outputs for correctness, handling exceptions, understanding context that isn't captured in any system) is where humans remain essential.

Where the human stays in the loop

The practical reality of running these automated workflows is that you quickly learn where the human checkpoints need to be. Not everything should be fully automated, and the places where you want a person reviewing are usually predictable:

• Anything involving money, contracts, or commitments to external parties
• Decisions that require judgment about tone, relationships, or context the AI agent can't see
• Actions that are hard to reverse if something goes wrong
• Edge cases that fall outside the documented process
• Anything touching security, access control, or sensitive data

The skill and MCP framework makes it straightforward to build these checkpoints into the workflow. The AI agent runs until it hits a point you've marked as requiring approval, presents what it's done and what it wants to do next, and waits for a go-ahead. It's not unlike a junior team member who's been given clear instructions but knows to check in before doing anything consequential.

Beyond software development

The thing to pay attention to is that none of this is limited to software development or traditional IT automation. The same pattern works for finance operations, HR workflows, client onboarding, vendor management, compliance processes, marketing operations, really anything that can be described as a series of steps involving multiple systems.

Most organizations have dozens of these processes that are currently done by people following documented (or undocumented) procedures, switching between systems, and doing a lot of manual data entry and coordination. The bottleneck was never that these processes were too complex to automate. It's that the cost of building traditional automation (writing integrations, maintaining scripts, dealing with API changes) was too high relative to the value.

When you can describe the process in plain language, connect to the relevant systems through MCP, and have an AI agent execute it with appropriate human oversight, that cost equation changes. Processes that were never worth automating before suddenly are.

What this means practically

If you're in a technical role, this is worth experimenting with now rather than waiting. Tools like Claude Code with MCP and skills are open source and usable today (OpenCode, an open-source Claude Code alternative, is another option worth looking at). Start with a workflow you know well, one where you're the person doing the manual coordination, and try describing it as a skill. See how far the AI agent gets, and note where it needs human input.

If you're in a leadership role, the thing to start thinking about is which of your team's processes are really coordination work (moving information between systems, following procedures, generating standard outputs) versus judgment work (making decisions, handling exceptions, managing relationships). The coordination work is what AI agents will handle increasingly well. The judgment work is where your people's expertise matters most, and where you'll probably want them spending more of their time.

The transition won't be overnight, and it won't be clean. But the direction is clear, and the IaC precedent is encouraging. The manual work changes. The roles evolve. And the people who understand both the business process and the capabilities of the tools become more valuable, not less.

The biggest risk right now isn't moving too fast. It's waiting too long to start. Daniel Miessler put it well recently: the barrier between having an idea and having a working application has effectively collapsed. People who had ideas but lacked the technical skills to build them are just building their own tools now. That's not a prediction about the future. It's something that's already happening, and the gap between people who are experimenting with these tools and people who are still reading about them is widening every week. Pick a workflow you know well, describe it clearly, point an AI agent at it, and see what happens. The learning compounds quickly, and the best time to start was probably a few months ago.