My working thesis is that agents will take over some clearly defined contractor tasks before they take over whole employee roles. I mean work with a specific input, a visible output, and a person who can decide whether the result is acceptable. A founder's request to prepare a prospect qualification workflow is one example. Responsibility for revenue operations across a company is a much larger commitment.
That is a product thesis, not a forecast of employment. I do not have a dataset that establishes which jobs will disappear or when. I also would not assume that work is suitable for an agent because a contractor performs it today. A skilled contractor can bring judgment, context, and relationships that matter more than the deliverable named in a statement of work.
The useful question for a founder is smaller: which piece of work can I describe, authorize, inspect, and accept without delegating the surrounding business decision? Answering that question gives you a practical place to try an agent. It also gives you a way to discover when you still need a person with expertise you do not have.
Start with the work you can inspect
Consider an illustrative task for a small B2B software company. The founder wants a reusable process for finding relevant companies, collecting prospects, and recording why each prospect appears to fit the intended buyer profile. The task ends with a draft workflow and a sample that the founder can inspect. No claim about meetings or revenue is part of the brief.
There are several distinct decisions inside that request. Someone must define the buyer. Someone must select a suitable data source. Someone must decide which fields support qualification. Someone must connect the steps, handle incomplete records, and make the result available for review. The work becomes easier to delegate when those decisions are named and assigned.
An agent could help turn a supplied buyer definition into a workflow draft. It could propose fields, assemble supported steps, and explain what each step produces. The founder would still need to judge whether the buyer definition makes commercial sense. A neatly structured output would provide little value if the company has chosen the wrong audience.
This is the distinction I care about in RevOps: a task can have a technical completion condition while the commercial assumption behind it remains uncertain. An agent returning a successful run does not settle that assumption. Treating the two as separate questions makes the work more inspectable and the conversation more honest.
A brief is part of the system
Before delegating the example, I would write down the intended audience, the source to use, the allowed inputs, and the expected output. I would state what qualifies as an unclear case. I would also name the person who can approve a provider expense or a change to a published workflow.
A vague instruction such as “find good leads” leaves too many decisions implicit. Good for which offer? Which company types should be excluded? Is a missing employee count a reason to reject a record or a reason to request review? Should an apparent agency be excluded even if it also sells software? These questions influence the result before any tool is called.
The brief should give the agent enough information to expose those choices. For example, the requested output could include a fit label, a short reason, and a field that marks uncertainty. The labels are proposed judgments. A human can examine whether the stated reason follows from the available information and the supplied criteria.
That makes a brief useful even when you eventually hire someone for the task. Writing down the assumptions can reveal that you need advice on the buyer definition before you need execution. It can also show that the task has a clear enough boundary to attempt with an agent and then review together.
Why a task boundary matters more than a job title
A bounded assignment gives the reviewer a stopping point. The workflow exists. The fields are visible. A limited run has either completed or failed. The person who commissioned the work can decide what happens next. Those properties are useful for agent work because they make disagreement concrete.
An employee role can contain many such assignments, but it can also include deciding which assignments matter, noticing a problem that was never specified, and negotiating changes with other people. I would not infer that an agent can assume those responsibilities from its ability to complete one of the component tasks.
The same caution applies to contractors. A contractor hired to set up a workflow may be the person who notices that the proposed process conflicts with how the sales team actually works. They may challenge the brief, improve the handoff, or identify an assumption the founder cannot yet evaluate. Those contributions belong in the comparison.
My thesis concerns the repeatable execution inside that work. If the founder can supply the important context and evaluate the result, an agent may become a useful way to carry out the assignment. If the founder cannot recognize a bad result, the need for expert review remains. Moving execution to software does not supply missing judgment by itself.
Compare the whole cost of acceptance
I would evaluate an agent against the cost of reaching an accepted result. That includes writing the brief, arranging access, reviewing the draft, checking a sample, correcting mistakes, and maintaining the workflow after the first run. The software bill is only one part of that calculation.
A contractor quote can look expensive beside the cost of a model call. That comparison becomes less useful when the quote includes discovery, implementation, review, and responsibility for fixing an error. Conversely, a narrow task that needs repeated small changes may be a good place to use an agent the founder already works with.
The test should preserve those costs rather than assume them away. Record how much attention the reviewer spends. Record what had to be corrected. Record whether the person reviewing the work could explain why it was safe to continue. A fast draft that takes a long time to verify may still be a poor choice for that task.
There is no universal threshold in this argument. The acceptable tradeoff depends on the task, the reviewer, the consequences of an error, and the value of reuse. A one-off research question and a workflow that will run repeatedly deserve different levels of preparation. Both deserve a clear account of what the agent actually completed.
Reusable work needs a durable home
A conversation can explain a workflow, but the workflow also needs a saved definition and a record of its executions. Otherwise the next change depends on recovering intent from an earlier exchange. I want a founder to be able to inspect what was configured and what happened when it ran.
That is the role of recipes in Coil. Recipes describe ordered steps with inputs and saved outputs. Runs are the durable executions of those recipes. This gives the founder and the agent a shared object to work on while the conversation provides a way to express changes and ask questions.
For the illustrative prospecting task, the agent might draft a sourcing step followed by an AI qualification step. Coil supports OpenRouter transforms that can save qualification fields and reasons. The result can include records marked as fit, excluded, or needing review. Those labels alone do not delete records or create conditional branches.
The distinction matters when evaluating the work. You should be able to ask whether a label was saved, whether a workflow ran, and whether any later action was actually authorized. Each answer needs its own evidence. A narrative that compresses all three into “the agent handled it” makes the work harder to assess.
Give consequential decisions a named owner
I believe a useful delegation system makes authority explicit. The person who asks for a draft does not necessarily intend to approve every expense or every subsequent use of its output. The workflow should preserve those separate decisions as the task moves from an idea to execution.
In Coil, agents using API keys have member permissions. They can draft workflows and run permitted published work. Human admins manage credentials and publish recipes. Provider-backed runs also have their own spend confirmation boundary. Those are concrete limits on the assignment an agent can carry out.
The same principle applies after qualification. Deciding that a record appears relevant does not approve contacting that person. Sending has its own setup and consequences. Coil works with SmartLead for sending; I do not treat an internal qualification label as a substitute for the review required before an outbound campaign.
A contractor can also work within these limits. The point of the model is to make a task portable between a human and an agent while keeping its authority understandable. If the business decision is important, its owner should remain visible even when much of the preparation can be delegated.
Test a small assignment before changing a role
A sensible first trial is a task with a limited scope and a result the founder can assess. For the prospecting example, agree on the fields, the classification criteria, and a modest sample. Keep the initial workflow as a draft until the reviewer understands its behavior. Use illustrative data while discussing the design, and label it clearly.
When a real run is authorized, inspect both the technical result and the usefulness of the output. Did it use the intended source? Did uncertain records remain visible? Do the reasons support the labels? Did the run stop where expected? Those checks reveal more about the assignment than an impressive transcript of the agent's work.
Include a failure in the evaluation. A missing field, an unavailable provider, or an incomplete result should produce a visible limitation. Decide in advance which problems the agent may correct and which require a return to the founder. A trial that only examines a successful example leaves the most consequential questions unanswered.
After the trial, change one part of the brief and repeat the review. Reuse is part of the value proposition. A workflow that can be understood and revised may support continuing work. A workflow that only its original author can explain has transferred less capability to the business than its first successful run suggests.
Keep expertise in the comparison
The strongest objection to my thesis is that defining a small task can hide the expertise that made it possible. Someone still has to decide what matters, recognize errors, and interpret ambiguous evidence. I agree with that objection. It is a reason to make the trial precise and to keep expert involvement where it is needed.
An agent may change what a founder asks a contractor to do. The founder could arrive with a draft and ask for diagnosis, design review, or a difficult integration. That would shift the assignment without removing the value of the contractor. It could also reveal that the founder needs ongoing operational ownership rather than another isolated deliverable.
For now, I would start with a piece of work, an acceptance test, and a named reviewer. The agent-driven lead generation guide provides the wider workflow context. The question to bring to that guide is specific: which part can your agent execute while you retain enough understanding to judge the result? That is a testable next step for a founder, even while the larger employment question remains open.