I use two roles to think about a founder working with an agent on go-to-market tasks. The operator sets the objective, chooses the limits, and accepts the result. The driver carries out the permitted steps and reports what happened. In this model, the founder usually acts as the operator and their agent acts as the driver.
These are responsibilities that can change during an assignment. A founder may take over a step that requires human approval. An agent may identify an ambiguity and return the decision to the founder. The model works when each participant can see where execution should continue and where a new decision is required.
My reason for using it is practical. When a request arrives through a conversation, it is easy to compress intention, permission, execution, and success into one sentence. “Build an outbound workflow” can describe several different assignments. A shared definition of the roles helps the founder say which one they mean and helps the agent report which one it completed.
The operator supplies the commercial judgment
Imagine a founder who wants to find B2B software companies in Sweden and qualify relevant prospects. This is an illustrative task, not a customer case. The founder knows the offer and has a view of the intended buyer. The agent can help translate that view into a workflow, but the commercial assumptions still need an owner.
The operator should define which companies belong in the audience and explain important exclusions. If agencies are outside the target, that needs to be stated. If a company sells both software and services, the founder should decide how to treat it or explicitly ask for uncertain cases to be returned for review.
The operator also decides how much work to authorize. A draft, a small sample, and a recurring campaign are different commitments. Each can involve different costs and different consequences. A useful instruction states the immediate assignment and the point at which the agent should stop and ask for another decision.
This does not require the founder to know every API field before starting. The agent can discover supported capabilities and propose a plan. The founder does need to judge the important choices in that plan. Delegating the mechanics can make that review easier to focus, provided the choices remain visible.
The driver turns intent into supported actions
The driver's job is to map the request onto actions the tool can perform. It should inspect the available capabilities, identify missing inputs, draft the workflow, and report unsupported requests. It should not treat a plausible description of a feature as proof that the feature exists.
For the Sweden example, Coil's Sales Navigator sourcing uses an Apify integration. Geography belongs in the supplied Sales Navigator search URL. The agent should preserve that relationship when it explains the plan. Describing a standalone country filter would give the founder a misleading picture of the configured workflow.
Next, the agent can propose a qualification step with a clear output. A fit label and a reason can make the result easier to inspect. The prompt should explain how to handle missing information and ambiguous company types. The founder can then review the criteria before deciding whether the draft is ready to become runnable.
In Coil, recipes are ordered steps with inputs and saved outputs. They are not a visual branching engine. An agent that describes a proposed flow needs to stay within that model. It can still help the founder make useful changes by choosing supported steps and explaining how the output of one step is used by another.
Keep the conversation attached to saved state
A chat is a useful place to give direction. The durable workflow should live in the product so that another person or another session can inspect it. The founder should be able to compare the agent's explanation with the actual recipe and the record of a run.
This is why authenticated API and JSON CLI access matter to the model. They give an agent a structured way to work with the same organization-scoped state that a human can inspect. The agent's response can refer to a saved object rather than ask the founder to trust a description of invisible work.
A saved draft also gives the conversation a concrete subject. “Change the qualification criteria” can mean a change to a particular draft. The agent can explain that change and identify the decision that remains. The founder can inspect it before a human admin publishes a recipe for execution.
The surrounding interface still matters. The dashboard is a useful review surface for the same state. A founder might prefer a conversation for making a change and a table for checking the resulting records. The model should support that choice without requiring separate copies of the workflow for humans and agents.
Distinguish proposals from completed work
A driver should report the strongest state it can prove. A plan is a proposal. A saved draft is prepared work. Publication makes a reviewed definition available for permitted execution. A run request establishes an attempt. A successful run establishes that the workflow completed according to its execution rules.
Those distinctions help the operator choose the next action. If the agent has only prepared a draft, the founder can review it. If a run is still active, the founder can decide whether to wait. If a provider has failed, the founder can inspect the problem and choose an authorized recovery step.
The report should be short enough to use. It can say what changed, which object contains the change, what has completed, and what decision remains. It does not need a transcript of every intermediate action. It does need to avoid suggesting that a consequential step occurred when the available evidence only proves preparation.
For the prospecting example, a successful run still leaves a business review. The founder must decide whether the prospects and reasons are useful for the intended offer. A technical success condition and a commercial judgment answer different questions. The agent can help present the evidence for both while leaving acceptance with the operator.
Permission is part of the task description
The operator and driver model needs concrete authority limits. A prompt asking an agent to build a workflow should not silently grant permission to replace credentials, publish a new definition, or approve provider spend. Each action needs the authority that applies to it.
Coil gives agents using API keys member permissions. Human admins manage credentials and publish recipes. An agent can draft a workflow and carry out permitted published work. This means the conversation must sometimes lead to a human action in the web app before the assignment can continue.
That handoff is useful information. The agent should explain which action is required and give the exact supported route when the product provides one. The founder can then make the decision in the correct context. The agent should not imply that a human approval occurred because it suggested the next step.
Provider spend is another boundary. The operator should understand the specific run and its limits before confirming it. If the requested input or definition changes, the founder may need to review the new commitment. A prior willingness to experiment is not a useful substitute for understanding what the next execution will do.
Make uncertainty visible in the output
An agent-driven workflow should give the operator a way to inspect uncertainty. In the illustrative qualification task, some company descriptions will support the requested classification more clearly than others. The useful response is to preserve that distinction in the output and in the review process.
Coil supports OpenRouter transforms that can save qualification fields and reasons to lead custom fields. A recipe can use labels such as fit, excluded, or needs review. These fields make a judgment available for inspection. They do not establish that the underlying information is complete or that the judgment is correct.
They also do not automatically delete a lead or prevent a later delivery. If the founder wants a particular handling rule after qualification, that rule must be supported and configured through the appropriate workflow. A label's name should not be treated as evidence that another action happened.
The operator should inspect a sample that includes uncertain cases as well as apparent fits. Ask whether the reason follows from the supplied criteria and the available record. If a reason contains an unsupported assumption, revise the prompt or the process. That is a concrete improvement the founder and agent can make together.
A recovery needs its own decision
The driver's work includes explaining what happened when execution did not complete. A failure may be temporary, but the decision to retry still needs context. The operator should know what was attempted, what state was saved, and what the product permits next.
For a provider-backed workflow, starting a fresh run can have different effects from following a supported recovery action on the existing run. The agent should inspect the current state and the available recovery path before choosing. It should not repeatedly create new attempts simply because the original conversation asked for a result.
This is one reason durable run state is valuable. It gives the operator and driver a common record for discussing an incomplete assignment. The report can identify the failure and the next available action without pretending that the task either succeeded completely or disappeared without a trace.
The same discipline applies to uncertainty about completion. If the agent cannot verify the final result, it should say what remains unverified. The operator can then decide whether to inspect the run, wait, or authorize another action. A confident sentence is less useful than a clear account of the remaining question.
Keep sending and learning in their proper tools
A qualification workflow is one part of outbound work. Preparing records does not itself send a message or establish how recipients responded. An operator needs to know which product owns each later step so that evidence from one stage is not used to support a claim about another.
Coil works with SmartLead for sending and campaign performance. A saved recipe result inside Coil should not be described as a delivered campaign. The founder needs to review the relevant sending setup and the evidence available from that service before treating outreach as completed.
The same limit applies to claims about learning. A record marked as fit is a classification based on supplied criteria. It is not evidence that a buyer is interested in the offer. Responses and commercial outcomes require their own observation. The founder outreach guide gives a broader frame for those stages.
Keeping those boundaries clear makes the agent more useful to the operator. It can assemble and explain the available evidence without pretending that every part of the business lives in one product. The founder can then revise the audience, workflow, or offer based on the evidence that actually exists.
Begin with one decision cycle
For a first trial, I would use one draft, one review, and one explicitly authorized limited run. Ask the agent to discover the supported path and prepare the draft. Inspect the definition and its assumptions. Complete any required human actions. Then review the resulting state and output together.
This is a proposal for evaluating the working relationship, not a claim about how quickly it will pay off. Watch where the founder must intervene and whether the intervention improves the next attempt. Notice whether the agent can identify its own limits and whether the saved workflow makes review easier.
The Coil methodology and recipe overview provide places to examine that model in more detail. The central question is whether you can give your agent direction and retain a clear view of the decisions, permissions, and results. When that is true, you have a practical basis for delegating the next task.