Specify the task
Once the agent has the right information environment, the next step is to tell it what you want done. A good task description is clear about the objective and important requirements, without trying to micromanage every technical step.
From context to task
After you've provided the relevant context, you can specify the task you want the agent to perform. This usually includes two things:
| Part of the task | What it means | Example |
|---|---|---|
| Objective | What you want the agent to accomplish. | “Build a dashboard that helps managers compare store performance.” |
| Requirements | Company-specific rules, constraints, preferences, or information the agent should follow. | “Use our existing sales data, keep the current branding, and don't expose customer-level information.” |
You don't need to know exactly how the task should be implemented. Your job is to make the goal and important constraints clear enough for the agent to propose a sensible approach.
Use planning as part of task specification
For a non-trivial task, it's often useful to stay in plan mode while you refine the request. Instead of giving one giant prompt and immediately asking the agent to build, you can work through the task in several iterations.
Example: refining a task in plan mode
I want to add a feature to our sales dashboard that helps
regional managers identify stores that may need attention.
Before building anything, explore the current project and
propose a plan. Tell me what information you would use and
what the user would see.The agent might respond with a proposed approach, after which you could refine it:
That's close, but don't rank stores only by sales decline.
Also consider customer complaints and missed sales targets.
Revise the plan, but don't implement yet.This back-and-forth is useful because the first version of your task may not capture everything that matters. You may realize that the goal needs to change, that a business rule is missing, or that the agent needs additional context.
How specific should you be?
More detail is not always better. A good task description gives the agent enough information to understand the goal and important constraints, without overwhelming it with unnecessary instructions.
Add a new comparison section to the dashboard. Put it below the
existing charts. Show this month and last month side by side for
every store. Use a bar chart, sort stores from largest decline to
largest increase, label every bar with the percentage change, use
red for declines and green for increases, add a dropdown for region,
and include a summary box at the top showing the average change.Some of those details may be useful, but others may unnecessarily constrain the solution. If your real goal is simply to help managers spot declining stores, you can focus on the outcome instead:
Add a view that helps managers compare each store's sales this
month with last month. Make large declines easy to identify.The second prompt still gives the agent a clear goal, but leaves room for it to propose an appropriate design. You can then review the plan and add constraints that actually matter.
But don't be too vague
Giving the agent freedom doesn't mean giving it no direction. If a request is too vague, the agent may misunderstand the goal or use a much more complicated solution than the problem requires.
Example: using a big hammer on a small nail
Suppose you ask:
Make it easier for users to find customers.The agent might interpret this as a major feature and build an advanced search system with multiple filters, fuzzy matching, saved searches, and a new database index.
But perhaps all you wanted was:
Add a search box above the customer table that filters the
existing rows by customer name or email address.The agent wasn't incapable — the task was underspecified, so it had to make assumptions about the size of the solution.
A useful rule is:
Be specific about the outcome and constraints; be flexible about the implementation.
How should you break down a complicated task?
A large task can often be divided into smaller pieces, but there's no universal rule for where to split it. A useful way to think about the problem is to ask:
Where do I want a human checkpoint?
A checkpoint is a place where you want to inspect the result, make a decision, or provide additional information before the agent continues.
Example: building a customer analytics dashboard
You could ask the agent to do everything in one task:
Clean the customer data, analyze it, decide which metrics
matter, build a dashboard, and write recommendations.But this combines several important decisions. You may want checkpoints between them:
Step 1: Inspect and clean the data.
↓
Human checkpoint: Do the cleaning decisions make sense?
Step 2: Analyze the data and propose useful metrics.
↓
Human checkpoint: Are these the metrics managers care about?
Step 3: Plan the dashboard.
↓
Human checkpoint: Does the proposed design answer the business question?
Step 4: Build and test the dashboard.In other situations, you may trust the agent to complete several steps together. The right level of decomposition depends less on how many technical steps are involved and more on where human judgment is valuable.
| Use a checkpoint when… | Example |
|---|---|
| The agent is making an important business assumption. | Deciding which customers count as “high value.” |
| There are several reasonable directions. | Choosing between a dashboard, report, or alert system. |
| A mistake would affect everything that follows. | Cleaning or merging data before analysis. |
| You need to evaluate an intermediate result. | Reviewing proposed KPIs before the dashboard is built. |