A task is not the objective
“Write five articles” is a task. It says what should happen, but it does not tell the system whether those articles are useful, whether an existing page should be improved instead, or when to stop publishing.
For our first agent workflows, we want to start one level earlier. What are we trying to improve? What evidence do we have? What is the smallest useful action available now?
That is what give agents goals, not tasks means to us. It is a design principle, not permission for an agent to do whatever it wants.
Make the goal specific enough to challenge
A goal like “grow the company” leaves almost every decision open. We would rather start with a defined section of a website, an intended audience, and a practical result.
For example: make a particular guide more useful for readers who are deciding how to approve an agent’s website changes. That is still a goal, but it gives a reviewer something to evaluate.
The brief should also describe what does not count as success. Publishing more words is not automatically an improvement. Completing more agent actions is not necessarily progress.
Keep the boundary with the goal
Our proposed job specification carries five things together:
- The goal and its intended audience.
- The evidence the agent may use.
- The files, systems, and actions it may access.
- The output and checks required for review.
- The conditions that should make it stop.
The boundary is not a note added after the interesting part. It is part of the job. An agent should not turn a content task into a redesign, a pricing change, or a new software purchase.
Let the evidence choose the next action
Suppose a useful page has an outdated example. A task-oriented workflow might still publish the next item on a content calendar. A goal-oriented workflow should be able to recommend fixing the example first.
The system also needs to be able to do nothing. Missing data, unclear permissions, or an uncertain factual claim should be reasons to ask for help rather than reasons to generate confident-looking output.
The loop we are building
The proposed loop is simple: observe, plan, act, measure. Each stage should leave an artifact that another agent or a person can inspect.
Observation produces evidence. Planning produces a bounded brief. Action produces a draft or diff. Measurement produces an outcome review, including what remains uncertain.
Our first test environment will be our own website. That gives us a place to see where this design holds up and where it fails, before treating it as a finished product.
Explore the operating model or read the first experiment plan.