Give the Agent a Job

A goal needs edges

Module 1 asked who decides what happens next? This module asks the follow-up question:

How much direction is enough?

If the model is allowed to choose the route, what still needs to be decided by the human?

In Module 1, a goal was the outcome the user wants, without necessarily specifying every step required to reach it. That flexibility is exactly what gives agent behavior room to emerge.

But flexibility is not the same as usefulness. “Research this topic” is not automatically a good agent job. The model still needs enough information to know what outcome matters, how to recognize completion, what it should not do, and when continuing would become guessing or unnecessary work. The goal defines the destination. The rest of the job defines the edges.

Three more words to learn

These three are this course’s vocabulary, not anyone’s protocol. The underlying ideas are well supported in the engineering guidance from Anthropic and OpenAI, but those sources reach for different words, and sometimes narrower ones. The Sources section sets our terms beside theirs so you can move between them.

One assignment, three ways

The same fictional assignment runs through the rest of this module, so that the only thing changing is the instruction style.

Too vague

Research the new AI research platform and tell me what I should know.

What is missing? Decide before you open this.

Too scripted

1. Open the vendor homepage.
    2. Open the features page.
    3. Open the pricing page.
    4. Search the documentation for "research."
    5. Search the documentation for "citations."
    6. Write three bullet points from each page.
    7. Put the bullets into a one-page memo.

What changed?

Give the goal room, but give it edges

A third version keeps the destination and the limits in human hands, and leaves the route open.

Prepare a one-page background briefing for a faculty member who is
    considering whether to explore a new AI research platform.

    Explain what the platform appears to do, identify two important
    limitations or unanswered questions, and support the briefing with at
    least three primary sources.

    Do not create an account, upload Stanford materials, contact the
    company, or change anything outside the research session.

    If primary sources do not support an important point, identify the gap
    instead of filling it in.

It is only a few sentences longer than Version A, and considerably shorter than Version B.

What did the human decide?

The same job, broken into its parts:

Goal

Prepare a useful background briefing.

Success condition

A one-page briefing that explains what the platform appears to do, identifies two limitations or unanswered questions, and uses at least three primary sources.

Boundaries

Do not create an account, upload Stanford materials, contact the company, or make external changes.

Stop condition

If primary sources do not support an important point, report the gap rather than inventing the answer.

Four decisions, all of them the human’s, and none of them about which page to read first.

What did the human leave open?

This half matters just as much, and it is easy to miss. The job did not specify:

• which primary source to inspect first;
• which search terms to use;
• whether another source is needed after the first;
• which limitation will ultimately matter most; or
• the exact sequence of research steps.

Those are potential decision points for the agent.

That is the direct connection back to Module 1. Version B left almost none of these open, which is why it read as a workflow. Version C leaves all five open while still telling the system what “done” means — and that combination is what a bounded agent job looks like.

“Do a good job” is not a success condition

A success condition should be observable enough that a human can inspect whether it was met. If you cannot tell by looking at the result, neither can the system.

This does not mean every task needs numeric quotas. “Two questions” and “three sources” happen to suit a briefing; they would be silly attached to something else, and a condition like “covers each of the four topics we discussed” is just as observable without counting anything. The aim is to make “done” less ambiguous, not to count everything.

Boundaries protect the shape of the job

A boundary describes something the system should not do merely because it might help achieve the goal. That last part is the whole idea. Creating an account really would produce a better briefing. It is still out of bounds.

Boundaries tend to look like:

• do not upload private material;
• do not contact another person;
• do not create an account;
• do not modify a file; or
• do not use sources outside a defined set.

A useful goal does not automatically authorize every action that might help achieve it.

Sometimes the right next step is to stop

This is one of the most important ideas in the module, and one of the least intuitive.

An agent should not be encouraged to keep looking for something merely because the original goal has not been achieved yet. A system that treats “the goal is incomplete” as “keep going” will eventually fill a gap by guessing, because guessing looks more like progress than stopping does.

Useful stop conditions might include:

• required information cannot be found;
• sources conflict in a way the task cannot resolve;
• the next step would require access not provided;
• the next action falls outside the agreed boundary; or
• the system needs a human decision.

Stopping can be successful behavior.

Version C has exactly one stop condition, and it is doing real work: if primary sources do not support an important point, identify the gap instead of filling it in. Without it, the instruction to use three primary sources quietly becomes pressure to find three, whether or not three exist.

The two conditions are easy to confuse, so it is worth setting them side by side:

One describes arriving. The other describes deciding not to.

Build the job, not the route

Your turn. Here is a request in the state most requests actually arrive in:

Help me understand whether a new technology would be useful for my class.

Before reading on, write down three things — on paper, in a note, or just in your head:

More instructions are not always better

There are two opposite ways to overdo this, and both are common.

You can constrain an agent so tightly that you effectively prescribe the whole workflow — Version B, arrived at one well-meant clarification at a time. You can also add so many requirements that the job becomes difficult for anyone to understand, including you, three weeks later, when you are trying to work out why the result looks strange.

The goal is not to write the longest prompt possible. Make the important decisions explicit, and leave the appropriate decisions open.

Which decisions are “important” is a judgment call, and it changes with the stakes. That judgment is most of the skill this course is trying to build.

Who still decides what happens next?

Module 1’s question, answered for the bounded job:

Agent design is partly about deciding which decisions belong on each side of that line.

What to notice

A good agent job is neither an empty wish nor a script.

• Too vague — the system must invent important requirements.
• Too scripted — the human has already chosen the route.
• Bounded — the human defines the outcome and limits while leaving meaningful route choices open.

The three versions in this module distribute the same decisions differently; none is a better draft of the others.

Before you continue

You are ready for Module 3 if you can:

• turn a vague goal into an observable success condition;
• name a meaningful boundary;
• identify a reason the agent should stop before completing the goal;
• explain why a natural-language boundary is not automatically a technical guarantee; and
• leave some route decisions open rather than prescribing an entire workflow.