Unit 02.01: Goals narrow enough to be finished
An agent with an unfinishable goal does not fail. It elaborates, indefinitely, because nothing in its instructions describes being done.
Can you name the output that means finished?
That is the test. "Improve customer satisfaction" has no end state; "decide if this refund is inside the 7-day window" has exactly one.
The code sorts five goals by whether they can be finished.
GOALS = [
("Improve customer satisfaction", False, "no end state -- never finished"),
("Handle all support tickets", False, "unbounded scope"),
("Decide if ACC-1187's June refund is inside the 7-day window", True,
"one decision, checkable"),
("Be helpful and accurate", False, "not a goal, a disposition"),
("List the charges on one account for one month", True, "bounded and testable"),
]
print(f"{'goal':60} finishable?")
for goal, finishable, why in GOALS:
print(f"{goal:60} {'yes' if finishable else 'NO'} -- {why}")
print("\nTest: can you name the output that means this goal is done?")
# An unfinishable goal produces an agent that keeps elaborating, because nothing
# in its instructions tells it when to stop. That is a cost problem before it is
# a quality problem.
"Be helpful and accurate" is the one worth dwelling on, because it sounds like a goal and is a disposition. An agent given it has no way to know whether it has been helpful enough, so it keeps going - which shows up first as a token bill rather than as a quality problem.
The two finishable goals share a shape: one decision or one bounded list, over named inputs. That shape is what makes both the agent and the reviewer able to stop.
The mistake this prevents
The mistake is writing the goal as the business objective. The business wants satisfied customers; the agent needs to decide one refund. Keep the objective in the design document and give the agent the decision.
Takeaway
A goal must name an output that means it is finished. Unfinishable goals produce agents that elaborate until something else stops them.
