Breaking Jobs into Agent Tasks: Defining Scope, Limits, and Escalation in Code

When a team says "we want an AI employee," the first thing to do is not pick a model—it's to break a job down into tasks that can be specified, constrained, and checked. This article uses an example role of a sales operations analyst to show how to write down this task specification in code.

Why break down tasks first rather than pick a model

At the outset, author Tej Pandya makes the point clear: between the vague requirement of an "AI employee" and a system you can actually ship, there's a layer of task specification. Model selection is the last step, not the first.

This view aligns with Anthropic's agent design guidance. That guidance clearly distinguishes workflows (fixed code paths) from agents (where the model decides the steps), and notes that agents bring higher costs and compounded error risk, so it recommends testing them in a sandbox with guardrails first. Based on this, the article offers a conservative principle: every task starts as a workflow, and only migrates to agent mode when the steps genuinely cannot be fixed.

The logic is straightforward: a workflow's execution path is predictable and auditable, whereas every choice an agent makes can introduce deviation. Only by breaking tasks down finely enough can "handing it to AI" become controllable.

The core fields of a task specification

The article defines a TaskSpec using a Python dataclass, containing several key fields: task name, input, list of allowed tools, output form, human owner, and escalation conditions (escalate_when). There's also an easily overlooked but crucial mode field that marks whether the task is a workflow or an agent.

Take the example clean_lead_list task: the input is CRM leads, the only allowed tools are crm.read and crm.update_field, the output is a list of changes with reasons, the owner is the operations lead, and any case of "merging two records" must escalate to a human.

Another task, draft_followup, is even more conservative: it only allows reading the CRM and drafting emails, the output is explicitly marked "draft only, never send," and any mention of pricing or refunds triggers immediate escalation.

The essential difference between workflows and agents lies in where control resides. In workflow mode, every operation is determined by a code path the developer arranged in advance, and the model only executes specific subtasks at fixed nodes (such as classification, extraction, or text generation), making overall behavior fully predictable and reproducible. Agent mode hands the decision of "what to do next" to the model, which chooses tools, decomposes subgoals, and loops on its own based on the current context until it judges the task complete. This flexibility comes at two costs: first, every model decision can deviate from expectations, and errors compound and amplify across multiple steps; second, token consumption and latency grow linearly or even exponentially with the number of steps. So the more robust engineering approach is "orchestrate whenever you can, don't delegate control"—first solidify the deterministic parts of the process into a workflow, and only hand over to an agent the steps whose branches genuinely cannot be enumerated in advance, and even then always with a tool allowlist, a step limit, and a human escalation exit.

Put limits in code, not in prompts

The most powerful point in the article is this: the list of allowed tools and the stop-loss words should live in code, not in prompts. "Prompts can be persuaded; checks in code cannot."

The logic of the run function is simple: before each step executes, first check whether the tool that step wants to call is in the allowed list; then check whether the step text hits an escalation keyword; if either is triggered, immediately escalate to the human owner. Only steps that pass the checks actually call tools, and their inputs and outputs are written to an audit log.

What this design solves

Large language models have no natural immunity to prompt injection and privilege-escalation requests. Placing boundaries outside the model means that even if the model "wants" to call a tool it shouldn't, the code layer will intercept it. This defensive design doesn't require trusting the model's behavior—only trusting the execution of the code.

Paired with this is the audit log: every tool call and its result is recorded. This provides the data foundation for later spot checks and stops "what the AI did" from being a black box.

Prompt injection refers to an attacker hiding malicious instructions in content the model will read—such as CRM notes, email bodies, or web page text—inducing the model to ignore its original instructions and perform operations the attacker wants. Because large language models cannot reliably distinguish "system instructions" from "user data," a simple "don't do X" in a prompt is easily bypassed by carefully crafted text. The key to defense is to push the security boundary outside the model: do allowlist validation at the tool-call layer, parameter checks and permission control at the execution layer, and sensitive-operation interception at the output layer. This way, even if the model is persuaded, the actual action is still blocked by code. The run function in this article embodies exactly this idea—before each step executes, it validates whether the tool is in the allowed list and whether the text hits an escalation keyword; the model's output is only a "proposal," and whether it actually executes is decided by deterministic code.

Audit logs in such systems are not just records but the infrastructure for building trust. A qualified audit record should contain at least: timestamp, task identifier, step number, the name and parameters of the tool to be called, the model's raw output, the code layer's allow-or-block decision, and the actual execution result. With these fields, the owner can conduct two kinds of review: first, after-the-fact spot checks to see whether the model completed the right thing within the boundaries; second, retrospective attribution, locating when an error occurs whether it was a model judgment error, a tool interface problem, or a rule design flaw. Audit logs also support "gradual delegation of authority"—only when a task performs stably across enough samples without triggering unexpected escalations should you consider widening the tool scope or reducing the frequency of human review. Without logs, expanding automation can only rely on gut feeling, and that is precisely where most AI projects start to go off the rails.

The principle of least privilege originates in the information security field and means that any executing entity should only receive the minimum permissions necessary to complete its current task. In agent design, this principle manifests as tool allowlists: clean_lead_list can only read the CRM and update fields, and draft_followup can only read the CRM and draft emails and never send. The direct benefit of narrowing permissions is shrinking the blast radius—even if the model is subject to injection attacks or hallucinates, the damage it can cause is limited to a few low-risk operations. Paired with this is a "human-in-the-loop" escalation mechanism: when a task touches high-impact operations (merging records, mentioning pricing or refunds), the system does not handle it itself but packages the context and hands it to a human for a decision. Only by combining least privilege with human-in-the-loop can automation gradually expand within controllable bounds, rather than handing high-risk permissions all at once to a model whose behavior is not fully predictable.

Every task must have an owner

The article makes owner a required field, with a blunt rule: a task without an owner is not allowed to go live. The owner samples the audit logs for review every week and has the authority to shut down the task at any time.

This design echoes an observation from Microsoft's Work Trend Index (the article cites the 2025 edition of that report): the report describes agents as "digital colleagues" that take on tasks under human guidance, and calls the people who manage these agents "agent bosses." The article argues that this "agent boss" role corresponds exactly to the owner field in the task specification.

One detail: the author draws a clear boundary—the agent here is just a set of constrained tasks and is not an employee in any legal sense, nor can this specification replace a job. This restraint is rare in today's context where "AI employee" narratives abound.

Three principles for moving forward in small steps

The article offers three practical principles for keeping claims conservative: before the owner trusts a task, only draft and never send; record the input and output of every tool call; and let stop-loss rules come from real incidents rather than subjective guesswork.

The third is especially critical. Many teams list risk points from imagination when designing guardrails, but the real risks often appear where you least expect them. Deriving rules from real incidents means this set of limits will tighten gradually as the system runs, rather than being perfect from the start.

From task specification to a review loop

The article's conclusion points to a continuous cycle: sample from audit logs, tighten the rules, then expand the task scope. This is a gradual delegation-of-authority approach, not handing the entire job to AI all at once.

This method is highly transferable. Whether a team wants to automate sales operations, customer service triage, or data cleaning, the core steps are the same: first list tasks rather than jobs, define the allowed tools and escalation conditions for each task, implement the limits at the code layer, designate a human owner, and then gradually expand the trust boundary through log review.

The real difficulty is not writing these few dataclasses, but whether the organization is willing to accept that "AI only does the part that is explicitly constrained." This requires translating vague job expectations into precise engineering specifications—and that is exactly the first step most current "AI employee" projects skip.

One-line Summary

Building an AI employee should start with breaking down tasks before choosing a model, writing tool allowlists and escalation rules into code rather than prompts.

Paragraph Summary

The article argues that the first step in building an "AI employee" is not choosing a model but breaking a job down into task specifications that can be specified, constrained, and checked. The author uses a Python dataclass to define TaskSpec, containing task name, input, allowed tools, output form, human owner, and escalation conditions, and uses a mode field to distinguish workflows from agents, with the principle that every task starts as a workflow and only converts to agent mode when the steps cannot be fixed. The core argument is that tool allowlists and escalation trigger words must be implemented at the code layer rather than in prompts, because prompts can be persuaded while code checks cannot; at the same time, every task must have a named human owner who supervises through weekly audit-log sampling and has the authority to shut the task down. The article also offers three conservative practical principles: draft only and never execute first, record every tool call, and let stop-loss rules come from real incidents. The result is a gradual delegation-of-authority loop: sample from audit logs, tighten the rules, then expand the task scope.